For Knowledge Center Content Manager's Background Task component there is only one physical centralized queue but BackgroundTask configuration can create different virtual sub-queues. Thinks of this queue for example. A,B,C,A,B,C. A BackgroundTask service is configured with a role parameter, by which each service retrieves the type of items it can execute. This is done by configuring the role's matrix. For example BT1 is configured for role 1, that references A and B items while BT2 has role2 that references C items. Note that the matrix configuration is not exclusive and doesn't enforce any rules. With the above configuration, I've created two virtual queues, one Q1 for items A,B and one Q2 for items C. By specifying the role for the BackgroundTask service, I control what is executed on each server. For example, if items of type C require a special licensed component on the server, then I could have only one server with this licensed component in the cluster that is configured to pick up items of type C. The rest of the cluster can work with all items except type C.
With the above link, a different publish item is injected into the queue based on its output format type. For example EXPORTFORPUBLICATIONPDF and EXPORTFORPUBLICATIONZIP. There are more mentioned in the topic. This allows me to configure the background task with two roles R_EXPORTFORPUBLICATIONPDF and R_EXPORTFORPUBLICATIONZIP of which each references the respected handler EXPORTFORPUBLICATIONPDF and EXPORTFORPUBLICATIONZIP. If my PDF rendering requires a special license, then by a similar configuration with the A,B,C paradigm, I achieve minimum deployment cost for the PDF tool's license .
I apologize for the unmarked text but in this ideas section there isn't any rich text editing. Please notice that the role's matrix is not intended only for this purpose but also to control throttling and guarantee the stability of the system. Also, all above examples are abstract and need to be adjusted accordingly to your intentions.
Translate
