Configuring Queue Assignment for Inbound Processing 

Use

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:

●      The process definition contains one correlation only.

●      All inbound interfaces are part of this correlation in the process.

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.

●      The content of the correlation container does not change during the lifetime of a process instance.

A correlation cannot therefore be activated more than once by using different values.

●      The correlation is so selective that the act of determining the queue name from the correlation values results in the load being balanced as required.

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.

Configuring Queue Assignment - Basic Procedure

You can configure inbound processing for each process type and client.

...

       1.      Call transaction SWF_INB_CONF.

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.

       2.      Navigate to the process type whose settings you want to change.

       3.      To display the settings for the process type, select the process type and press ENTER.

       4.      Switch to change mode and select the required setting for the Queue Assignment.

For details of the individual settings, see below.

       5.      Save your settings.

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.

Configure Load Balancing

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:

■       Changes to the process definition mean that the conditions for load balancing are no longer met

■       The binding between the message and the correlation was changed

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.

...

       1.      Before you activate the process, switch the queue assignment to one queue in transaction SWF_INB_CONF (One Queue or One Configurable Queue).

       2.      Wait until the status display shows that the reconfiguration is complete.

       3.      Configure and activate the process in the Integration Directory.

       4.      Configure queue assignment in accordance with the new process semantics.

Configure Queues

...

       1.      If you want to execute the queue for a particular process type on a particular application server belonging to the Integration Server, define the corresponding destination.

This configuration option is available if you have selected one of the following settings:

○       One Configurable Queue

○       Multiple Queues (Random)

○       Multiple Queues (Content-Specific)

 

                            a.      Choose Tools → System Administration → Administration → Network → RFC Destinations (transaction SM59).

Choose Create.

                            b.      Define the name for the RFC connection.

Make a note of this name, because you will need it later on during configuration.

                            c.      In the Connection Type field, select type 3.  

                            d.      Make the required entries on the Technical Settings tab page and the Logon/Security tab page.

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.

 

       2.      Call transaction SMQR to define the required configuration:

                            a.      Select the required qRFC queue and choose Registration.

                            b.      To have the queue run on a particular server, specify the corresponding RFC destination in the USERDEST field.

Enter the destination that you defined in transaction SM59.

                            c.      To define the number of retry attempts in the event of temporary errors, enter a number in the NRETRY field.