Condition-based Collect Message Pattern with Intermediate Message Event in SAP BPM
Condition-based Collect Message Pattern with Intermediate Message Event in SAP BPM
Introduction: Message collect pattern provides a way to aggregate messages based on functional requirements or system performance. There exists different ways to achieve the aggregation pattern using the intermediate message event. Collection pattern could make use of time duration for message aggregation or time duration in combination with conditions. However, the business requirements could pose an integration challenge that requires thorough knowledge of SAP BPM implementation when using intermediate message even. This article shares some insight on how best to make use of intermediate message event with dynamic conditions in combination with a mapping object.
Note: Since it is only possible to define conditions on Intermediate Message Event by comparing two fields based on “equality (=)” the “non-equal part to collect messages that have not been duplicated was achieved by introducing the extra mapping steps to append new non-duplicated messages
Challenge: Business requirement is such that message duplication and clustering of messages towards C4C application needs to be achieved. The situation is such that; for every process instance started, there is an intermediate timer event (ITE) of 5mins which keeps the process instance running for this duration. During the 5mins duration, collect pattern with an intermediate message event (IME) has to be implemented to collect messages belonging to the same functional location. This will also check that messages collected are not also duplicated, in case duplicated messages are coming from the same functional within the 5mins duration.
Set-up and Configuration:
- Create a BPM process development component in NWDS with below example (detailed steps on this will not be provided, other blogs have addressed this already)
2. Configure Intermediate Message Event: Configure the intermediate message event with a condition, this condition is defined dynamically, by comparing the incoming value in a specific field and a locally stored field in the Data Object (DO) while the process instance is running. All messages that match the stored “Functional location value” are collected and appended to the Data Object which is a list of value. If the condition on the IME is not fulfilled, the process server starts a new process instance.
Condition: string-equal(incomingString,locallyStoredStringInDO)
3. Create a mapping: This mapping step helps to introduce an additional condition to prevent adding duplicated messages to the already collected messages while the process instance is still running for the 5 minutes time duration.
The condition is specified as below using the “non-equality” logic in combination with “If-then-else” statement.
This condition loops through the collected messages while the process instance is running and checks if every new message that arrives has not been collected already before adding new message to the collection.
Condition to loop through collected messages to prevent collecting duplicated messages
Mapping with append functionality to add additional messages
Note: The target field structure eg “Prioriteit” that will collect the message must be of cardinality: “0: unbounded” or “1: unbounded”
Conclusion: In this blog, I have highlighted now to achieve message aggregation pattern using multiple dynamic conditions. This was achieved by introducing the use of Intermediate Message Event (IME) in combination with a mapping to prevent de-duplication of aggregated messages.
If you have questions do reach out to me!
Written by: Abidemi Olatunbosun
Contributions: Kas Timsi and Ronan Mol
to be honest, I don't know what you are trying to deliver in your two blogs.
in your condition check, you compare the incoming msg with a DO field, not a hardcoded value. you think this is dynamic conditions??? that's it?
Hi Jun,
If you need clarity, on fixed versus dynamic conditions, maybe you could take a look at the link below
https://help.sap.com/saphelp_nw73ehp1/helpdata/en/a0/5aebbe5fd8444ab68fe4bfd9f9ad8b/frameset.htm
Here it is explained how you can define static conditions for correlation on IME.
However, this blog provides insight on how define conditions dynamically for a running process instance. Which means within the BPM, static conditions are not defined on the Intermediate message event and deployed with the BPM.
But when a process instance is started, an initial DO is filled with value which is used as the condition for that specific process instance, for the duration of the process instance, every new message that arrives contains a field with value, which is compared with a field in the initial DO. If these match, then the message is collected, if not the message is not collected. The mapping step is to do an additional check that a similar message was not collected already for the duration the instance is running.
If you have further questions/comments, you could raise this.
Regards,
Abidemi
it is very very..... basic/proper usage of IME to compare with DO field.
I cannot imagine your IME is comparing with hardcoded value. it is kind of nonsense.
come up with a name...dynamic condition.....???
I think your use of word in a public domain is very poor, if after providing even an SAP guide on the use of hard-coded values for condition, then I don’t think your comment should be replied further.