When and how to create an scenario in SAP PI without mapping objects.

[Former Member]

Sometimes during my work as SAP integration consultant I did the following question. Why create a mapping when you use the same source and target messages and you don’t need to make mapping conversions?

In some occasions our sceneries have the same messages in the target and source sides, these messages are mapped so that each node of a message is mapped to the same node of the equivalent message, and we don’t need any conversion. The source and target messages are identical.

In SAP PI the traditional way of making thinks sais that you need to create a target and source message, make a message mapping between both, create an inbound and outbound interfaces associated with the corresponding messages, create an interface mapping, etc. And I think, it’s really necessary to create mappings when it doesn’t add anything to the scenario?

So I tried to create a scenario without mappings.  In advance it sounds as not possible if I think in the normal approach of scenario construction. But in practice it’s possible and it offers better performance, because we are saving a step in the normal flow of execution.

(The mapping tool generates Java source code from the graphical mapping description, which is then compiled and packed in a JAR file that the Integration Engine executes at runtime. )

I’ve found  paragraph in help.sap that support this approach:

Mapping is an essential part of SAP Exchange Infrastructure. At design time mappings can be saved in the Integration Repository and then selected for a business process at configuration time (see:Defining Interface Determinations). The Integration Engine executes the mappings saved in the Integration Directory at runtime, following receiver identification. If no mapping is required for a connection then the IntegrationEngine skips the mapping step.

(http://help.sap.com/saphelp_nw04/helpdata/en/d9/cea942ad920c31e10000000a1550b0/frameset.htm)

The escenario that I made as example is the next:

In the traditional approach

In the test

The same interface acts as Inbound and outbound. I define it as inbound because the logic of this scenary. ( You need to define it as inbound or outbound depending on the ABAP proxy you need, in this scenario I need an Inbound ABAP proxy )

An external system launches a request, and it’s executed in SAP ECC, the ABAP Proxy calls an RFC who extracts certain information and return the response to the external system.

My scenary.

In the Integration Repository. I create two data types and to messages based on the DT, called MT_Request and MT_Response and only one interface with the attributes as inbound and synchronous.I don’t create any Mapping Objects.

In the Integration Directory. I create an scenario, with a business system (SAP System)  and a business service (external system) asociated.

Asociated to the business service I made a SOAP Sender Communication channel. I inform in it as asociated interface the unique interface that i’ve defined in the scenario. (This interface is defined as inbound but acts as inbound and outbound ) .

In the configuration objects:

Sender and receiver agreement are configured as a normal scenario.

In the Receiver Determination I leave the Interface Mapping box empty.

The same in the Interface Detemination

After configuring the scenario I generate the corresponding wsdl that I will use to call the interface as Web Service. I select Tools > Define Web Service, and I inform the unique interface defined in my scenario.

Now I’m going to create the ABAP proxy. I go to sproxy, select the interface, and Create proxy.

Now I use the wsdl to generate a proyect in SOAP UI, and I test the scenary.  In works fine!!

Now I want to analyce the advantages of this scenario in comparison with the traditional one.  From my point of view the advantages are:

• You don’t need create mapping objetct. You only need one data type, one message and one interface.  You don’t need replicate this objects (this scenary makes sense only when the target and source messages are identical, and you don’t need to make any conversión in SAP PI).
• And the most important, the performance of this scenary is better. It has sense because it’s been avoided mapping steps that aren’t necesary.

The performance improvement is better the larger the message is. For example for messages larger than 4 Mb the traditional scenario takes over 40% more time than the no mapping scenario.

I made this example in PI 7.0 and PI 7.3 (java only) and in both it works fine.

At the end I apologice for my homespun english. I hope this example may be userfull.

Cheers.

Fernando Vignolo.