Skip to Content
Technical Articles

EIPinCPI – Event Message

Previous – Document Message | Index | Next – Request-Reply

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.

Integration Flow

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.

Steps

IDoc Sender

The IDoc Sender adapter is responsible for exposing the integration flow to ECC.

Log

The Log is a Groovy Script step that simply logs the payload.

Output

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.

Integration Flow

Steps

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>

Get Product

Get Product is a Request-Reply step that sends a Command Message to Salesforce to get product information.

Log

The Log is a Groovy Script step that simply logs the payload.

Output

Sample output in this example can be as follows:

<sRecords>
    <Product2>
        <Id>a1V1n000003MdetEAC</Id>
        <Name>Chai</Name>
        <ProductCode>CHAI</ProductCode>
    </Product2>
</sRecords>

Other Patterns

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.

IMHO

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?

Conclusion

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.

References/Further Readings

Hope this helps,
Bala

P.S.: Source code should soon be available as an Integration Recipe when my pull request is approved and merged. In the meantime, you can download the iFlow zip from my fork on GitHub.

Previous – Document Message | Index | Next – Request-Reply

2 Comments
You must be Logged on to comment or reply to a post.