Skip to Content

Content Enrichment Pattern using PI

Patterns based Integration using PI:

Patterns are solutions to recurring design problems. Patterns based Application development is common and matured. Integration is no different and developing integration solutions or interfaces based on patterns ensures a standardized approach and such integration solutions are easy to communicate, design, develop and provide continuous support.

Just like Design patterns in Application development, integration patterns are technology/product agnostic.  They can be implemented using PI and definitely not restricted to the set of ccBPM patterns that SAP provides as standard content. Integration Patterns like Content Enrichment, Content Filter, Canonical Data Model, Content Based Routing, Message Splitter, Dynamic Routing etc do not use ccBPM.

The focus of this blog is just not to demonstrate how content enrichment pattern can be implemented using PI, but to articulate  that we need to recognize the patterns while developing the interfaces and promote using them with PI so that we realize the benefits of patterns based integration.

Content Enrichment Pattern:

The sender system would not have all the data that is required by the receiver system to process it successfully. In these cases, we can augment the message sent by the sender system during mapping with the additional data that is required for a successful processing on the receiver system. In most cases, this additional data might be available in other systems/databases/services on which we can perform a lookup, retrieve the additional data and complete the mapping so as to produce a target message with all the data required for successful processing on the receiver system.

Use case:

In our specific scenario, the sender system is SAP ECC and the receiver system is an external third party portal which exposes a web service and consumes an xml request. However, before posting the actual business data, the external portal requires that we get a session id from it, which, again, can be obtained using another web service hosted by the portal and by just simply passing the userid/password.

Patterns based Design:

The sender system ECC sends a proxy message to PI.  As soon as PI receives this message, in the mapping, we perform a SOAP lookup to get the session id (a user defined function that uses a receiver SOAP channel from Integration Directory), map this session id in the GUID field of the target message and then post the actual Business data to the external web service on the portal along with the required session id.



While lookups are quite common, there is nothing special to it just that we are following a standardized approach for a common design problem  – sender system would not always have all the data that is required by the receiver system to process it successfully.

 The Takeaway Point:

As soon as we start thinking in terms of patterns and utilizing them in PI, for a good number of design problems we may find that indeed we have a solution in Patterns and it is not necessary that it should have been implemented in PI, maybe we will the first one to implement it in PI. Such integration solutions or Interfaces are easy to communicate, design, develop and provide continuous support

And with time, the library of patterns or the pattern catalog that we can implement in PI also will increase.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.