About Queue Mapping

Queue mapping allows you to control which tasks and actions are processed by which queue. When setting up the queue mapping, two things you should consider are 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.

Setting the priority on queue mappings allows you to control when requests are processed within an individual queue. It does not apply across all queues. Thus, a critical priority request on one queue may be processed at the same time as a normal request on another queue. However, it will be processed before all lower priority requests on its 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 can be 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 will evaluate the mappings in the following way. It looks for a match first for all categories (actor, data area, business class, and action), and then successively for less specific matches, with preference given first for the first category (actor), then the second category (data area), and so on. This results in the following order to matching tries:


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

Consider the following scenario. Assume you have the following 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

In the above scenario, the requests will match the queue mappings as follows:


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 will always be 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.

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

BatchTask.Run: This is 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: This is 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 can be set for actor, data area, and process (flow definition) values. Mappings can be assigned to the ipaDefaultWorkUnitDispatchQueue queue as well as to queues you create. If a work unit does not match any queue mapping, it will be 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 (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 would be handled at a high priority.