This blog is about an example about using the latest integration technologies given by SAP Netweaver 7.1. Constructing new or even renewing consisting integrations scenarios within SAP Netweaver system landscapes can be done in different ways. I assume that a lot of SAP customers are confused about the possibilities offered by the SAP Netweaver platform. There is a integration broker called SAP Process Integration (ment to be the SOA backbone) but you can also communicate with the SAP ERP system directly (point to point). I don’t want to explain what SAP PI exactly is because there are lot of blogs and articles around in sdn – so one more is not necessary. But I found no information about the level above.

The following only looks at the roles “service provider” and “service consumer” – both roles can be represented by a SAP (ERP, Composition Environment) or a non-SAP system (Java/.NET Application, or anything you want). In this case all communication is done by SOAP via http (classic Web Services). So, should I use the SAP PI or can I directly speak with the SAP ERP-System. What do I have to consider?

I want to give a consise support for the decisions to be done during design time.

Usage of a messaging platform?

Pro

• within SAP Netweaver landscapes the SAP PI monitoring (SXI_MONITOR, Runtime Workbench) is the best tool for control the message flo (but it’s not perfect!)
• asynchronous scenarios can only be realized by using SAP PI (beside you have activated the WS-Reliable Messaging protocol in SAP backend, but I assume that the fewest have)
• higher security level
• higher scalability for asynchronous communication due to queue mechanism in SAP PI

Contra

• SAP PI has to be installed within the landscape
• SAP PI is an additional component which rises the count of dependencies
• synchronous scenarios can also be done without SAP PI (in SAP backend you need SOAMANAGER transaction [or even the older versions])
• performance impact in synchronous scenarios (even if advanced adapter engine is being used)
• higher effort for implementing (double interfaces to be designed)
• restricted XML support (e.g. xsd:choice)

Usage of direct communication?

Pro

• synchronous communication as fast as possible (ICF needs to be configured correctly)
• less implementation effort than involving SAP PI
• quite good monitoring possibility in SOAMANAGER (for both directions: SAP ERP = service provider and service consumer), you can see the same information than in SAP PI

Contra

• no asynchronous scenarios (beside WS-RM)
• if you already use PI and no P2P-communication (SOAMANAGER) you have to get involved for SOAMANAGER
• usage of a web dispatcher is recommmended (higher security level, loadbalancing)
• problems with some JAVA implementations with consuming web services without return value (void)(JAX-WS, JBoss WS)

Possible approach

Synchronous communication means that the service consumer needs the feedback as fast as possible (e.g. internet portal for customers). To reduce number
of dependencies and provide the best performance I prefer the direct communication in this case. But the interfaces have to be documented very well. Therefore
the usage of proxy technology is recommended, too (interface design in Enterprise Services Repository). It gives you a good overview about your designed
interfaces within the landscape. If you also use the Enterprise Services Registry you should strictly publish the service endpoints there to get a detailed
overview of the services within your landscape.

Our SAP ERP systems don’t have the WS-RM option activated because the administration has got to less time and the service consumer (mostly JAVA developers)
aren’t experienced using this standard. So we design asynchronous scenarios by usage of SAP PI – this means more effort on designing and writing the specification and
even more effort in implementing but with the advantage of a good scalable and robust integration implementation with not that strong dependency between service consumer
and service provider (e.g. if SAP ERP system is down, SAP PI stores all asynchronous incoming messages and distributes them to SAP ERP if it’s up again).