Consuming Your First Synchronous RESTful Service - Step-by-Step - Introduction

[Former Member]

Introduction

This is a mini series of 5 blogs describing how to build a basic SAP-to-REST synchronous interface scenario.

Motivation

I recently had to use PI to communicate with REST services. As my PI experience was almost nothing, I had to learn some basic PI principals quickly. After struggling with the many different (and often confusing) elements and objects, I managed to call a simple REST service and receive the response. I found many resources that talked about part of what I needed. However, it is a struggle to find everything at one place. So, I'm hoping writing this blog will help others kick-start their "life of PI" and will also help me recall what I did and why. Many thanks to my colleague jon.viter for this time and help.

System Versions

The SAP ECC system I used for this blog is a 7.31 system (SAP_ABA that is; support pack 2).

The SAP PI system I used for this blog is a 7.31 system as well (support pack 15).

Different system version could look or act slightly differently. Please accommodate those differences in your versions.

Scenario

This blog is a step-by-step guide for building a simple synchronous REST interface from an SAP ECC system. The key word here is "simple." There are many ways such an interface could be built. There could even be simpler ways that I am not aware of. Again, I can't claim to be an expert in PI and my goal here really is to show the basic steps to get it working. Once it is, then, additional enhancements or modifications for more complicated scenarios are easily done. I based my scenario on this very valuable document: PI REST Adapter - Consuming synchronous RESTful service. The SAP ECC system will send a zip code to the REST service and expects to get the resulting XML message back. Further parsing of the XML message could be done in the SAP ECC system. PI could also be used but that is not covered in this blog. The interface we are building can be simply represented by this diagram:

Prerequisites

Before starting to implement this scenario, you need an SAP ECC system and a PI system that can talk to each other. A simple way to test is to check whether the PI ESR is visible from the SAP ECC system. You can use transaction SPROXY or SE80. Either transaction should look similar to this screenshot. If you don't see the "Enterprise Services Browser" selection button in SE80, go to menu option: Utilities -> Settings. Then, in the "Workbench (General)" tab, make sure the "Enterprise Service Browser" checkbox is selected.

Another pre-requisite is that you are able and authorized to use the different Process Integration tools. Those are mainly in transaction SXMB_IFR in the PI system. This transaction will open a web page that looks like this.

The sending SAP ECC system must be defined in the PI system's System Landscape Directory as a business system. If not, you need to work with your PI administrator to add it there. Click the "System Landscape Directory" link and navigate to the "Business Systems" application where you should be able to see it there.

Also, you will need to have a Java run time environment installed on your system so that the Enterprise Service Builder and Integration Builder applications can be started from the web page above. Alternatively, you could use the NW Developer Studio. This blog uses the web start applications though.

Building Blocks

PI has many components and pieces that go together. On a high-level, you need to build objects in the Enterprise Service Builder of the Enterprise Services Repository (I will call them ESR objects) and in the Integration Builder of the Integration Directory (I will call them IB objects). The ESR objects are usually transportable while IB objects are system-specific so they will need to be created for each PI system (development, QA, production, etc.). In an ESR object, you say your sender system is "an" SAP system. In an IB object, you must specify which specific system is that; providing system details from the SLD.

Here is a diagram of the different ESR objects that we need to create:

• Data Type: This is the basic structure in which data will be formatted. It could be simple or complex structures. Data types could include fields of other data types (nested structures).
• Message Type: This is the container that will carry the data.
• Error Message Type (optional): This is the container to transport errors. The structure is auto-generated and can be enhanced by additional fields if desired.
• Service Interface: This a collection of request and response message types. An outbound service interface is the interface from the sender system to the PI system. An inbound service interface is the interface from the PI system to the receiver system. The direction is with regards to the sending system and NOT with regards to the PI system.
• Message Mapping: This object is how one message type is mapped to another. This involves mapping fields and writing transformation or formatting rules if necessary such as value mapping or date formatting.
• Operation Mapping: This object is used to map interfaces by assigning different message mappings to requests and responses.

Here is a diagram of the different IB objects that we need to create:

• Business System: This is the specific SAP system of the specific integration scenario we are building.
• Business Component: This is the third-party system of the specific integration scenario we are building.
• Communication Channel: This is an object that indicates how PI communicates with the business system or business component for a given service interface (whether outbound or inbound).
• Sender Agreement: This is an object to see whether a sender on a specific communication channel is actually eligible to participate in the scenario (eligible to send a message of a defined type).
• Receiver Determination: This is an object that checks who the sender is and what message is being sent and accordingly determines who should receive it.
• Interface Determination: This is an object that checks who the receiver is for a given message and accordingly determines what receiver interface to be used and what operation mapping to use.
• Receiver Agreement: This is an object that checks who the sender is and who the receiver is and what interface they used to determine what communication channel to forward the message to.

Let's get to work

Now, after the brief overview above, we can start working on building the different objects. There are four major steps. Follow each link for details on each step.

1. Prepare a software component version (SWCV) and a namespace
2. Build ESR objects
3. Build IB objets
4. Generate a proxy class in the SAP ECC system and build a simple ECC application to call the interfac...

See you shortly in the second part.