Skip to Content
Technical Articles
Author's profile photo Bhalchandra Wadekar

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?

Integration Recipe

The code is available as Integration Recipe on SAP’s official repository: EIP-MessageConstruction-EventMessage

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

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

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Daniel Graversen
      Daniel Graversen

      Hi

      Cool blog.

      An idea could be the to listen for the OSGI events as in the blog

      https://blogs.sap.com/2019/11/16/if-x-do-y-how-to-listen-to-internal-sap-cpi-events/

      It will probably require some different handling.

      Author's profile photo Bhalchandra Wadekar
      Bhalchandra Wadekar
      Blog Post Author

      Thanks Daniel Graversen.

      The Pull Model steps could be:

      1. Integration Flow Id is sent in event when the said Integration Flow is deployed
      2. Fetch the other information such as who deployed it, exact time of deployment, and so on using OData APIs
      3. Log the fetched information

      Kind regards,

      Bala