This blog post, as part of this blog series, refers to the recently introduced Conditional Start feature in SAP NetWeaver BPM available with SAP NetWeaver 7.3 EHP 1 SP 06 and higher.
This blog post refers to the recently introduced Conditional Start feature in SAP NetWeaver BPM available with SAP NetWeaver 7.3 EHP 1 SP 06 and higher. As mentioned in the previous blogs of this blog series the aggregator pattern is one of the most common use cases of conditional start processes. This article will show three variants of this pattern and discuss their peculiarities. In general, a process implementing the aggregator pattern collects messages till a certain situation is reached. How this situation is reached is different between the variants.
Aggregation Pattern with Counter
The scenario introduced in the previous blog entries (depicted again below) is an example of this variant. The messages are collected till a certain number of messages are received and consumed. For detailed information on this variant refer to Conditional Start: Introduction (1/7).
Peculiarities and Pitfalls
It cannot be guaranteed that the messages are consumed in the same order as they are received. Especially if the messages are received in very quick succession, it is likely that they are not processed in the same order. For example, if our process gets four messages seperated by fractions of a second for Pencil_A, Pencil_B, Pencil_C and Pencil_D in this order, there is still a chance that one process only consumes the three messages for Pencil_D, Pencil_C and Pencil_B while the message for Pencil_A will be consumed by the next process instance.
In this scenario, processing the messages in the same order as they have been sent, can be achieved if the timespan between the single messages is long enough. If so, the process can successfully receive and process the message before the next message is sent. If a save delay between the single messages is unwanted but in order processing is still required, this can be achieved by providing the necessary logic within the process. In this case, the process should collect all messages (Pencil_D, Pencil_C, Pencil_B and Pencil_A) until all required messages are received (Pencil_C, Pencil_B and Pencil_A) and then resend those messages, which should not have been received (Pencil_D).
In the above example, the process would receive and consume the messages for Pencil_D, Pencil_C, Pencil_B and Pencil_A and store all necessary data. After the Pencil_A message was received, the process has to identify that all required messages are received and stop the collection of messages. Then the unwanted message for Pencil_D has to be resent using an automated activity, before proceeding with process steps for the wanted pencils. The following image shows how this process can look like.
Aggregation Pattern with Timer
In this variant, the collection of messages will be stopped when a certain point in time is reached or after a certain timespan has passed.
Suppose a scenario where the pencils should be collected till the first day of the month is reached. After this, the batch should be sent to the packaging department as a whole. The process representing this scenario collects messages till the intermediate timer event is triggered, which will cause the collection loop to exit.
Peculiarities and Pitfalls
Also here, processing the messages in order is not guaranteed. In addition, it is necessary to pay close attention to the fact that the messages are not received in real time by the process.
This means that a message, which is sent very close to the trigger time of the intermediate timer event might only be received by the system but not by the process. This message will then not be consumed by the process even though the system will show a reception timestamp for the message, which is prior to the triggering of the timer event.
If it is necessary to collect all messages that have been received by the system till a certain point in time, this can be achieved by selecting the trigger time for the intermediate timer event a little longer than wanted. This might result in the collection of messages that were only received after the actual wanted collection time. These messages can however be avoided if the payload contains a timestamp and the correlation condition is set to not correlate those messages or compensated by resending them with an automated activity.
Aggregation Pattern with End Message
In this variant the collection of messages is stopped by the reception of a dedicated end message.
Suppose a scenario where pencils should be collected till the packaging department signals that it wants to pull the next batch. Then all collected pencils are sent to packaging.The process representing this scenario contains an event-based choice, which will either consume the message for the next pencil or stop the collection by consumption of the stop message.
Peculiarities and Pitfalls
As in the other variants, in order processing and real time processing are not guaranteed.
This means that it can happen that a message, which was supposed to be correlated, has only been received by the system but not consumed by the process when the stop message is processed.
For example, if the system gets messages for Pencil_A, Pencil_B, Pencil_C and Stop in that order, there is still a chance that the process consumes only the stop message while the messages for the pencils will be consumed by the next instance.
To avoid unwanted behavior it should be assured that the time between the correlation and stop messages is long enough and the system has the necessary performance and configuration to process the correlation messages in this time.
- SAP Managed Tags:
2 Comments
