You use the delivery mode to influence step 3 of inbound processing: delivery of the message to existing process instances or starting a new process instance.
More information about the fundamentals of inbound processing: Inbound Processing
You can choose between the following settings for the delivery mode:
● Classic setting: Inbound processing with buffering (default)
● Inbound processing without buffering
Unless precluded by the prerequisites described below, we recommend that you select inbound processing without buffering.
In this setting, a message is assigned to an existing process instance provided it has a matching active correlation. This is independent of whether a corresponding receive step is active or not. If no active receive step is currently available to receive this message, the message is buffered in a separate, process-instance-specific queue. As soon as the corresponding receive step is reached, the system delivers the first message in the queue that it received that satisfies the relevant correlation.
If you select this setting, it is possible that a message fails to be delivered from the buffer because the corresponding process instance does not reach the receive step. You can see whether this is the case in the CCMS Alert Monitor under Unprocessed XML Messages.
More information: CCMS Alert Monitor
If you select this setting, the qRFC entry returns an error when a message is to be delivered for which no receive step is active. The message remains in the qRFC queue and message processing for this process type is stopped.
In the setting inbound processing without buffering, the situation described above leads to an error in the qRFC queue, which is therefore easier to recognize and deal with.
Certain prerequisites must be satisfied in order for inbound processing without buffering to be used. If a correlation is active at the time of delivery of a message, a corresponding active receive step must be available. It may be necessary for you to modify the process definition.
● The processing sequence in the process definition and the sequence in which the messages for the process instance are delivered must be identical. This sequence must be guaranteed by the quality of service when the message is sent.
● The processing following a receive step must be executed synchronously until the next receive step. This is not guaranteed in either case.
○ A wait step is a means to include a delay in the process. The next message cannot be received until the specified wait time has passed because the corresponding receive step is not created until after the wait step.
More information: Wait Step
○ A receive step for the next message is built into a deadline monitoring branch. It cannot therefore be received until after the deadline for deadline monitoring has passed.
More information: Deadline Monitoring
If these prerequisites are not satisfied, check whether you can modify the process definition as shown in the following example:
The process must process Message_1 before Message_2. However, the sender sequence cannot be modified. In this case, insert the receive steps for Message_1 and Message_2 in two parallel branches of a fork and specify that both branches must be executed for the fork to be completed.
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 option in the Delivery Mode field.
This transaction checks again whether the queue is locked and whether any entries have an error status.
The setting Without Buffering (Obsolete) describes a processing strategy that was introduced by the strategy Without Buffering. For reasons of compatibility, this strategy is temporarily not available and must not be used.