When I started my quest with SAP PI7.1, the most attractive tag that I came across was of reusability, especially for the Service Interface. The question that haunted me was how to achieve this? Till now I was developing a Message Interface, in lower versions, and was able to use it only once due to the structure of the included message. But now SAP PI7.1 has enabled us to reuse the same Service Interface for "n" different structures. And what more, each service is independent of the others in terms of Operation Patterns, mode of execution (Asynchronous, Synchronous), and the included messages. However the services are bounded together by the same Category (Abstract, Inbound, Outbound) and Interface Pattern.
So what makes this possible? Do I need to upgrade to a specific SP to enable this functionality in SAP PI7.1?
The answer is availability of Operations menu in the Service Interface makes reusability possible and is available for even the basic SP level of SAP PI7.1.
Below is the list of pre-requisites that we need to make a note before proceeding further:
- Multiple Operations can be added, in a Service Interface, only for Interface Patterns other than Stateless (XI30-Compatible).
- Once the Service Interface is saved with a particular Operation name, no change in the Operation name will be allowed.
- If the Operations are to include both Asynchronous and Synchronous messages, then use of the term Async/ Sync should be avoided in the naming convention of the Service Interface.
- Name of each Operation should be unique, duplicate values are not allowed.
- Multiple Operations, in one SI, having the same set of messages (Request or Request & Response) are not allowed.
- ABAP proxy (inbound/ outbound) cannot be developed out of a Service Interface having Operations with different type of messages included. If an ABAP proxy is to be developed then all the messages included should be of one type i.e. either the included messages should be Message Type, External Message, IDOC or RFC Message. This behavior can be observed when a Service Interface is created and then subjected for a check (F7):
Let us proceed with the use of Operations for our below scenarios:
- FILE to FILE Asynchronous
- SOAP to SOAP Synchronous
For the above mentioned scenarios I have created a common Service Interface (one each for Outbound and Inbound message processing).
Outbound Asynchronous SI for FILE to FILE scenario:
Outbound Synchronous SI for SOAP to SOAP scenario:
Please note that the above development is of one single Service Interface and not different Service Interfaces. To include different messages for different message processing:
- Create an entry under the Operations section, in the Service Interface, for your message flow.
- Corresponding to each Operation, an individual section is created for selecting the Attributes and Messages as shown in the above two pictures.
- Maintaining the Description for each of the Operations is a good practice as it helps in easy identification of the process for which the Operation is maintained.
Inbound Asynchronous SI for FILE to FILE scenario:
Inbound Synchronous SI for SOAP to SOAP scenario:
Message selection for Message Mapping is done in the normal way. The only difference that we will find is while selecting the source/ target Service Interfaces in an Operation Mapping; below picture will depict the difference that I am talking about:
Now from the above displayed list carefully select the source/ target Service Interface of your interest to be included in the Operation Mapping. A simple mapping program is defined only for the FILE to FILE scenario. Below is the complete list of objects created in Enterprise Services Builder for the two scenarios mentioned above:
Save and activate all the ESR objects before proceeding to configuration in Integration Directory.
Below is the complete list of configuration objects created in Integration Directory for the mentioned scenarios. The objects are grouped under different Folders for better understanding of the flow and maintenance.
If the Sender System is the same then the Receiver Determination, Interface Determination, Sender Communication Channel can be reused. Out of the configuration objects, Interface Determination plays the important role of mapping the appropriate source Operation to the target Operation.
Interface Determination for SOAP to SOAP Synchronous scenario:
Interface Determination for FILE to FILE scenario:
When the Interface Pattern, of the source Service Interface, is Stateless (XI3.0-Compatible) the Interface Determination will look as shown in the below picture:
As shown in the above diagram and as the functionality provides, we do not have an entry for Operations. The Inbound Service Interfaces can be included using the Insert option. There is no change in the Standard/ Extended functionality provided by Receiver Determination of SAP PI7.1.
Condition, in an Interface Determination, can be defined based on XPATH or by using Context Object. Interface Pattern does not affect condition definition for an Interface Determination as it does in Receiver Determination.
SAP PI7.1 EHP1 has the feature of Operation Based Routing, can we not implement it in SAP PI7.1? We can implement a workaround here. Use the below diagram to determine the condition in a Receiver Determination:
Based on the value of EmpID, in the Operation defined for FILE to FILE scenario, we can route the message to the particular receiver. To know more about how to specify the condition check my weblog SAP PI7.1, Receiver Determination, XPATH and You!. Context Objects can be used to define a condition.
Once all the required objects are created in Integration Directory, save and activate the changes before proceeding to testing. To check how the flow looks in SXMB_MONI for the above two scenarios have a look at the below picture:
This is all folks! Thank you for taking out time to read the blog; I hope the contents prove useful to you in learning SAP PI7.1.
4 Comments
