
By configuring the queue assignment you can influence step 1 of the inbound processing: You can specify if the messages for a process type are to be ordered into one qRFC queue or if they are to be divided across multiple qRFC queues.
More information about the fundamentals of inbound processing: Configuring Inbound Processing .
Load Balancing: You can use multiple qRFC queues to balance the load. Messages in different qRFC queues can then be processed in parallel. This enables you to improve message throughput. However, load balancing is not suitable for all processes. Whether load balancing can be used for a process or not depends on the semantics of the process. Despite load balancing, the messages must still be delivered to the process instance in the correct order.
Applying load balancing incorrectly in a process can lead to messages being processed incorrectly or even to data loss.
Configurable qRFC queue: If load balancing is not suitable for a particular process, you can nevertheless improve system performance by configuring the appropriate qRFC queue. For example, you can define which server the entries in the qRFC queue of a particular process type are to be processed on.
Settings for Load Balancing
In load balancing, you define the number of queues and specify whether the system is to distribute the messages randomly, or whether it should take the content into account.
Multiple Queues (Random)
If you select this setting, the system distributes the messages randomly among the available qRFC queues. Consequently, the messages are not sent to the process instance in the same sequence in which the Integration Server received them.
Prerequisites: Select this setting only if the process meets the following condition:
None of the messages sent to this process type are dependent on each other: The order in which the messages are processed is not important.
This condition is always met if the process does not have a correlation. A process such as this receives exactly one message with the receive step. This is the case in a simple split-scenario, for example: A process receives a message, which a transformation step then splits into multiple messages.
However, this setting is not suitable in an enhanced split scenario, as in the following example: A process receives a message, which a transformation step then splits into multiple messages. The process then sends these messages and waits for an answer in each case by using a correlation.
Do not use this setting to send messages to a process instance when using multiple queues. This setting must not be used even if the order the messages are processed in is not important because lock conflicts can occur that cancel out the advantages of parallel processing.
Multiple Queues (Content-Specific)
If you select this setting, the system takes the content of the messages into account when distributing the messages to the queues. The system determines the name of the queue from the message fields in the correlation container. Consequently, all messages that satisfy the same correlation are processed by the same queue, as illustrated in the following example.
In a collect scenario, a process instance collects all sales-order messages for a particular customer. The correlation is defined by using the customer number. Therefore, the system determines the name of the queue from the customer number in this case. This ensures that all messages for this customer are processed by the same queue. For this reason, the order in which the messages are sent to the process is identical to the order in which the Integration Server received them.
Prerequisites: Select this setting only if the process meets the following conditions:
For a synchronous interface, the related asynchronous interface of the request message must be part of the correlation. The request message corresponds to the container element of the receiver step that opens the sync/async bridge.
A correlation cannot therefore be activated more than once by using different values.
Load Balancing in the Process Definition
The possible settings that you can make for load balancing depend on the semantics of the process concerned. For this reason, the process developer can specify exactly which settings are possible when they define the process in the process editor. For this purpose, click anywhere in the editing area in the process editor. The properties area displays the properties of the process, including the options for queue assignment. The process developer can, for example, specify that the process is suitable for load balancing using multiple queues.
However, you as administrator can decide to select different options when configuring inbound processing for the relevant process. For example, if the performance of a particular process is not critical, you can define that it is to be processed without load balancing even though the developer specified load balancing as permissible in the semantics of the process.
Configurable qRFC Queue
If load balancing is not suitable for a particular process, all messages for this process type must be put in one qRFC queue. However, you can make this queue configurable and achieve performance improvements by configuring it appropriately.
One Queue per Process Type
In this setting, there is one qRFC queue for each process type, in which all messages for this process type are queued (XBQO$PE_WS…). All process-type-specific queues are based on the XI standard queue XBQO and therefore cannot be configured individually.
You can define settings such as maximum runtime and destination together only for all XBQO… queues. If you change the settings, this affects all queues with the prefix XBQO, not just the process-type-specific queues.
One Configurable Queue per Process Type
In this setting, there is one qRFC queue for each process type, in which all messages for this process type are queued (XBPE_<Task>_0). You can configure each queue individually. For example, you can specify a particular server for executing the qRFC queue of a particularly time-critical process type. This could be a high-performance server or a dedicated server for batch processing.
You can configure inbound processing for each process type and client.
...
The system displays all processes that are in the runtime cache, grouped by component. If you have not yet made any configuration settings for a process, the process appears in the tree display under Initial Configuration.
Check the status display for the process type for which you want to change the settings. You cannot make any changes while the status Reconfiguring (yellow) is displayed.
For details of the individual settings, see below.
Depending on the setting you select, a dialog window is displayed in which you must specify whether the process only receives messages where EO is defined as the quality of service. If the process also receives messages where EOIO is specified, you must enter the name of the queues that will receive these messages.
More information: Quality of Service
If you have created a new entry, a queue with the name XBPE_<task> is registered. <task> is the ID of the relevant Workflow pattern, for example, XBPE_WS99999888.
If the process developer has changed a process in the process editor in such a way that the change affects load balancing, you must first switch to processing with one queue. Otherwise data may be lost.
The following can affect load balancing:
If, for the process concerned, the setting One Queue is set in the process editor, but the configuration specifies load balancing across multiple queues, you cannot activate the process. You must first change the configuration to processing in one queue.
This configuration option is available if you have selected one of the following settings:
Choose Create.
Make a note of this name, because you will need it later on during configuration.
Use WF_BATCH as the logon user. This user is normally created during automatic customizing (SWF_XI_CUSTOMIZING). For the corresponding password to be available, you must define WF-BATCH manually.
Enter the destination that you defined in transaction SM59.