In any SAP System landscape, there is always a requirement to maintain runtime/processing order for interfaces. This would result in designing Async Interfaces, using the quality of service EOIO. The configuration for this is Standard Out of the Box in PI, and can be achieved with minimal effort. The challenge occurs when there is a requirement for a typical Asynchronous interface, to run in a serialized mode
The following blog, discusses such a business case, and possible technical options around it.
Business Case:
This related to a Work Management System, which Integrates with an SAP ISU box. SAP ISU box, send out jobs or service orders to the work management system. The Field Service personals , execute the jobs at the customer location and send out updates for the jobs back to SAP. These updates either include change, completion and job duplication details.
Technically, the work management system publishes status sync messages, which SAP PI subscribes to. This is via a Async. web service call. The volumes of these calls are high, with over 5000 jobs on any given day.
Technical Challenge:
The same technical Interface, bring in updates for completion and change statuses. In case of completion, every message is unique and does not have an inter-dependency. The updates are consumed in ECC and the service orders are updated.
In case of changes, the updates in ECC need to be processed in the order in which, they are processed at the work management system.
Since this interface, has an Async pattern, it results in a challenge to achieve the above integration.
Technical Solutions:
- Change the mode to Queue Based message processing:
A simple solution would be to change the pattern to queue based processing. The problem with this is that all status sync messages would be queued, irrespective of dependency requirements, resulting in the following issues:
a) Enhancement processing time, due to queuing of message
b) Possible queue blockages due to failure on any message of the queue.
- Content Based Queuing:
Another approach is develop content based queuing mechanism in PI. This would involve, building a custom adapter module, to generate queue names based on payload content. This might have the following problems:
a) Additional processing times, due to payload parsing in the adapter module. This can become a potential bottleneck in case of time sensitive interfaces
b) Adapter modules cannot typically be used with Sender SOAP Adapters. In the above case, the subscription was via web services.
- Using a classical TRFC/QFRC based approach in ECC:
The following are the details of this approach:
ECC provides mechanism to call function modules in TRFC. The following is the link to the details around this from SAP Help
http://help.sap.com/saphelp_nwpi71/helpdata/en/22/042578488911d189490000e829fbbd/content.htm
TRFC based integration provides a mechanism to call any function module IN BACKGROUND TASK AS A SEPERATE UNIT. A QRFC is an extension of TRFC and can easily be achieved by assigning a queue name before the TRFC call. Following is the documentation around this
http://help.sap.com/saphelp_nwpi71/helpdata/en/b0/eae2a889e711d2956500a0c94260a5/content.htm
The following can then be the approach for achieving serialization:
- Define custom queues in ECC ( SMQR)
The following needs to be done in the inbound proxy class:
- Have business rule checks implemented in ECC, to determine the need for serialization
2. Separate business logic in a RFC.
3. Once the need for serialization is determined, call the FM TRFC_SET_QUEUE_NAME to set the defined custom queue.
4. Call the business logic in TRFC as IN BACKGROUND TASK AS A SEPERATE UNIT with a local destination
The following are the benefits of this:
- No additional development to determine content based queues
- Business logic remains in ECC to determine serialization.
- Selective serialization possible based on filters in ECC
- The interface can run in Async mode in majority of the cases.
- Data base locks can be avoided if the queue processing segregates logical unit of work.
Bluesky
