This week, we study yet another variation of Message pattern known as Event Message.
When do I use this pattern?
Event Message pattern applies when the sender system needs to notify a change in its objects. Sender system has two options:
- send the object data in the payload for the event message, for example, an ECC system sends product update using MATMAS05 IDoc. This is also known as Push Model because the required information is pushed with the event.
- send only the event information and the receiver systems are responsible for fetching the required information. The example I am using is Custom Platform Event Channels of Salesforce that can be subscribed to using Advantco’s Salesforce Adapter. This is also known as Pull Model because the subscriber has to pull the information that it needs.
Event Message in CPI
Sending Product Update from ECC
When a product is updated in ECC, ECC can send MATMAS05 IDoc containing the product information.
Unlike previous blogs, this flow starts with an IDoc Adapter. I only changed the Address to ‘/ProductUpdates’ from the default configuration. Once CPI receives the event message (here an IDoc), CPI logs it for monitoring.
The IDoc Sender adapter is responsible for exposing the integration flow to ECC.
The Log is a Groovy Script step that simply logs the payload.
Triggering the IDoc from ECC system requires a lot of configurations, so I refer you to Bhavesh‘s blog on triggering IDoc from SAP ERP to CPI Using Basic Authentication.
Once the IDoc is triggered, the payload is logged in CPI. Here’s sample payload:
<MATMAS05> <IDOC BEGIN="1"> <EDI_DC40 SEGMENT="1"> <TABNAM>EDI_DC40</TABNAM> <MANDT>100</MANDT> <DOCNUM>0000000000009022</DOCNUM> <DOCREL>751</DOCREL> <STATUS>30</STATUS> <DIRECT>1</DIRECT> <OUTMOD>2</OUTMOD> <IDOCTYP>MATMAS05</IDOCTYP> <MESTYP>MATMAS</MESTYP> <STDMES>MATMAS</STDMES> <SNDPOR>SAPECC</SNDPOR> <SNDPRT>LS</SNDPRT> <SNDPRN>ECCCLNT100</SNDPRN> <RCVPOR>CPIPORT</RCVPOR> <RCVPRT>LS</RCVPRT> <RCVPRN>CPI</RCVPRN> <CREDAT>20200105</CREDAT> <CRETIM>140115</CRETIM> </EDI_DC40> <E1MARAM SEGMENT="1"> <E1MARA1 SEGMENT="1"/> <E1MAKTM SEGMENT="1"> <MAKTX>EIPINCPI</MAKTX> </E1MAKTM> <E1MARCM SEGMENT="1"> <E1MARC1 SEGMENT="1"/> <E1MARDM SEGMENT="1"/> <E1MFHMM SEGMENT="1"/> <E1MPGDM SEGMENT="1"/> <E1MPOPM SEGMENT="1"/> <E1MPRWM SEGMENT="1"/> <E1MVEGM SEGMENT="1"/> <E1MVEUM SEGMENT="1"/> <E1MKALM SEGMENT="1"/> </E1MARCM> <E1MARMM SEGMENT="1"> <E1MEANM SEGMENT="1"/> </E1MARMM> <E1MBEWM SEGMENT="1"/> <E1MLGNM SEGMENT="1"> <E1MLGTM SEGMENT="1"/> </E1MLGNM> <E1MVKEM SEGMENT="1"/> <E1MLANM SEGMENT="1"/> <E1MTXHM SEGMENT="1"> <E1MTXLM SEGMENT="1"/> </E1MTXHM> <E1CUCFG SEGMENT="1"> <E1CUINS SEGMENT="1"/> <E1CUVAL SEGMENT="1"/> <E1CUCOM SEGMENT="1"/> </E1CUCFG> </E1MARAM> <E1UPSLINK SEGMENT="1"/> </IDOC> </MATMAS05>
Subscribing to Salesforce’s Custom Platform Event Channel
Salesforce enables developers to publish custom events to channels. These channels can be subscribed to using Advantco’s Salesforce Adapter. In these events, you can publish as much information as you like. When the event is about an updated object, it makes sense to only add primary key fields of that object. In Salesforce, “Id” field is the primary key. In this example, when a product is modified, Salesforce creates an event containing Id of the product. CPI captures the event and gets the product information about the updated product and logs it to monitoring.
Unfortunately, I couldn’t come up with a scenario that is available to try with CPI alone. Let me know in comments if you know any scenario where Pull Model of Event Message Pattern is applicable.
Advantco’s Salesforce Sender Adapter
Advantco’s Salesforce Sender Adapter listens to channel /event/Product2__e. The event sends the Id of the modified product.
Prepare Query Message
In Advantco’s Salesforce receiver adapter, when a SELECT query needs to be performed, you need to specify the operation as ‘QUERY’ and have empty tags of required fields. This XSLT Mapping step prepares the query message as required. The Id is taken from the event message to identify changed product uniquely. Name and ProductCode tags are sent empty to select those fields.
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <UpdateMultipleObjectsOperationsSchema> <Product2> <Operation>QUERY</Operation> <ObjectType>Product2</ObjectType> <Condition></Condition> <TransactionLevel>REQUIRED</TransactionLevel> <sObjects> <sObject> <Id><xsl:value-of select="//Id"></xsl:value-of></Id> <Name></Name> <ProductCode></ProductCode> </sObject> </sObjects> </Product2> </UpdateMultipleObjectsOperationsSchema> </xsl:template> </xsl:stylesheet>
The Log is a Groovy Script step that simply logs the payload.
Sample output in this example can be as follows:
<sRecords> <Product2> <Id>a1V1n000003MdetEAC</Id> <Name>Chai</Name> <ProductCode>CHAI</ProductCode> </Product2> </sRecords>
In this example, the Get Product step uses the Command Message pattern to get information about the updated product and when Salesforce responds with the requested information, the Document Message pattern applies.
Truth be told, I think the Pull Model of the Event Message pattern doesn’t have many applications where the middleware is involved. I would design the flow to have Push Model on the sender side and have the Command Message pattern or the Document Message pattern or combination the two on the receiver side. The advantage of the Pull Model is that it reduces the upfront payload and lets subscribers choose what they need. This advantage is nullified when the middleware is introduced because sending the required information about the changed object is now middleware’s responsibility. When middleware is listening to the events, not sending the information about the object that caused the event means one extra call.
Let me know what you think in comments. Do you think the Pull Model of Event Message pattern has applications when the middleware is involved? Or is there an architectural rationale which skews preference to Pull Model?
Event Message pattern is a variation of Message pattern that focuses on informing the receiving system of an event and the contents of a payload are less important than the timing. The sender system has the option to send information about the object with the event or not. If information about the object is sent, it is known as the Push Model, otherwise, it is called Pull Model because the subscriber pulls required information.
- Event Message Pattern in Enterprise Integration Patterns
- Bhavesh‘s blog on triggering IDoc from SAP ERP to CPI Using Basic Authentication
- Subscribing to a Custom Platform Event Channel in Salesforce
- CPI Components
Hope this helps,