Skip to Content
Author's profile photo Martin Steinberg

Integration Technology: Mediated vs. direct communication

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).

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Prateek Raj Srivastava
      Prateek Raj Srivastava
      Hello Martin,
      Its good to have views on this topic here.
      I agree to most of your points (Not all :)).
      I would like to elaborae on Synchronous communication which could be a way of data retrieval or a way to get some sort of acknowledgment of the sent message. In later case when its not a real time availability requirement, it would be better to have your Integration logic at a central location to avoid the cluttered landscape architecture. When number of such communication rises in a huge landscape, then good documentation alone wouldn't realy help the resolution time. In the former case too, if the response is time critical, then I agree to your point about P2P communication. But when its not matter or seconds, I would again recommend use of PI. Why to get yourself Entangled in communication web when you can enjoy the Untangled architecture. 🙂
      Author's profile photo Martin Steinberg
      Martin Steinberg
      Blog Post Author
      Hi Prateek,

      thanks for your reply.
      Of course if there's no demand to answer as fast as possible it's recommended to use the SAP PI in synchronous communication also, so I agree to your statement.
      The integration architecture is a decision of the company and many companies use different service busses in parallel (old Business Connector, Process Integration,
      WebMethods Fabric) - it's really not very easy to centralize all the integration logics. So in my opinion it's crutial for the first step to document as best
      as possible (UDDIv3 and SAP's ES Repository/Registry is a first approach).
      I also think that there'S no need to use PI if Composition Environment is used.

      What do you think?

      With kind regards.
      Martin