About queue mapping

Use queue mapping to control which tasks and actions are processed by each queue. When setting up the queue mapping, the things you should consider include the types of actions that get mapped to each queue and the priorities you set on the triggers that match each queue mapping. By controlling which actions go to which queues, you can, for example, send actions that typically use few resources but occur frequently to a queue with a higher number of maximum actions or worker threads allowed. You can then send resource-intensive actions to a separate queue that has perhaps only one worker thread, thus preventing multiple large jobs from tying up the system resources.

Set the priority on queue mappings to control requests processing within an individual queue. This action does not apply across all queues. As a result, a critical priority request on one queue is processed simultaneously with a normal request on another, but it is processed before all lower priority requests within its own queue.

You set up queue mapping on queues other than the default queue. The default queue is used whenever the system cannot find a match.

Standard Async Queue Mapping

For many async actions, queue mapping is done by actor, data area, business class, and action. You can set up levels of mapping, specifying one or more of these. When the system needs to map a task or action to a queue for processing, it evaluates the mappings first by checking for matches across all categories including actor, data area, business class, and action. A successive search is done by the system for less specific combinations prioritizing categories in these order:
  • Actor
  • Data area
  • Business class
  • Action

This table shows the order in which matching attempts are made:

Matching Try Actor Data Area Class Action
1 Match Match Match Match
2 Match Match Match
3 Match Match
4 Match Match Match
5 Match Match
6 Match
7 Match Match Match
8 Match Match
9 Match
10 Match Match
11 Match

This table shows a sample scenario with queue mappings and requests:

Queue Mappings Requests
Mapping Queue Actor Data Area Class Action Request Actor Data Area Class Action
1 Q1 John GEN X Y 1 John GEN X Y
2 Q2 GEN X Y 2 Jane GEN X Y
3 Q3

Jane

 3 Paul GEN X Y
4 Q1 GEN X 4 Paul GEN X Z
5 Paul K U T

This table shows how the requests match the queue mappings in the previously described scenario:

Request Mapping Match Queue Matching Try Comments
1 1 Q1 1 All fields match.
2 3 Q3 6 Even though there is a mapping that matches on the data area, class, and action, there is another mapping (3) that matches on the higher category of actor. The mapping says, in effect, that all requests by Jane go to the Q3 queue.
3 2 Q2 7 No mappings exist for the actor Paul, but mapping 2 matches for the other three categories.
4 4 Q1 8 No mappings exist for the actor Paul and the Z action, but a mapping (4) exists for the GEN data area and the X action.
5 none Default Queue When there no match, the requests is mapped to the Default Queue.

Queue Mapping with Generic Mapping Fields

With a few types of async actions, it is also possible to use one or two additional mapping fields. The reason for additional mapping fields is that some types of actions requests are based upon generic business classes and actions. For example, if you create a job to run an action for a business class, the business class and action used for mapping are always BatchTask and Run, respectively, not the business class and action specified for the job. Similarly, if you schedule a flow, the business class and action are always PfiTrigger and Schedule, respectively, not the flow or service that the trigger was based on. With the additional mapping fields, an async administrator can choose to map queues in these special cases such that the only criteria are not the generic business class and action.

Actions have been defined to use these mapping fields. Landmark applications can define additional actions that can use the mapping fields. Consult the user guide for your Landmark application.

  • BatchTask.Run: The Run action for a job of the task type. You can set Mapping Field 1 to the specific business class or business task, and Mapping Field 2 to the specific action.

  • BatchTask.RunStream: The Run Stream action for a job of the task type. You can set Mapping Field 1 to the specific business class or business task, and Mapping Field 2 to the specific action.

  • PfiTrigger.Schedule: This is for scheduled triggers. If the trigger is service-based, you can set Mapping Field 1 to the service name. Otherwise, you can set Mapping Field 1 to the flow name. Mapping Field 2 is not used.

IPA Queue Mapping

You can set up queue mappings that apply to work unit dispatching for Infor Process Automation. This queue mapping includes the ability to assign different priorities to the different mappings so that work units that need to be dispatched quickly are not prevented from being dispatched by a large number of less important work units. The queue mapping is set for actor, data area, and process or flow definition values. Mappings are assigned to the ipaDefaultWorkUnitDispatchQueue queue and to the queues you create. If a work unit does not match any queue mapping, then it is handled by the ipaDefaultWorkUnitDispatchQueue queue.

If there are conflicting priorities, then the actor mapping takes precedence, followed by the data area mapping, and finally the process or flow definition mapping. For example, if a high priority mapping existed for a specific actor and a low priority mapping existed for a specific process, then the work unit is handled at a high priority.