Hi everyone, first time poster here...
I have an integration scenario I was hoping others could share their insight on. I come from an application development/enterprise architecture background completely outside of SAP. I've only started working with SAP fairly recently, so I wanted to give that perspective as background before I lay out my use case.
We've built a fairly standardized SOA where mostly SOAP based web services are used for integration among our non-SAP applications. An ESB mediates communication (both sync and async) among those services. Beyond async application to application integration, we also do a decent amount of syncronous integration where web and mobile applications get some of their data from disparate systems via one ore more SOAP based services. We have some REST too, but that's not relevant at this point.
My team is now tasked with building a new mobile application that gets SAP data from various SAP systems (ECC, SRM, etc.). Our current infrastructure has ECC 6, SRM 5, and PI 7.1. Using Netweaver Gateway/REST is not an option right now. We have no desire to use SUP.
Given that we can't use Netweaver Gateway, and our desire is to continue with an SOA approach with SOAP based web services, one option I'm considering is exposing the services as synchronous web services using PI. The web and mobile applications will then call the services via PI, which in turn will get the required data from the ECC and/or SRM system. Using PI has the added benefit of managing the sign-on issues that arise from our ECC and SRM systems maintaining separate account information.
All that said, what are the issues with the architecture I've proposed? One of our members referenced this post as evidence that PI should not be used in this way (http://scn.sap.com/thread/1708405 and http://www.architectsap.com/blog/sap/sap-netweaver-pi-7-1-usage-scenarios-when-not-to-use-sap-pi/). I strongly disagree with the points made in that post. In my experience with other ESBs (Webmethods I/S for example), this is exactly the purpose of an ESB, and it's a common usage scenario. I've never seen middleware that was explicitly NOT recommended to be used in synchronous patterns. I just don't accept that a simple synchronous request to PI places "tremendous resource demands" on PI. I'd also argue that while it might be slightly more performant to make point to point connections between external applications and SAP web services exposed on their backend systems (ECC, SRM, etc.), this tightly couples the integration, something that is desirable to avoid in the name of flexibility, scalability, management, governance, monitoring, etc. In other words, I'm generally willing to give up a little performance to gain in flexibility.
I understand that SAP's preference going forward is to move what they call A2X type integration from PI to Netweaver Gateway, but given that isn't an option right now, and given that our team is already skilled/well versed in SOAP based services, are there any valid reasons not to implement this architecture using PI?
I'd love to hear how others, especially those who operate in a heterogeneous environment where SAP is but one system of many, address integrating their web and mobile applications with SAP services.
Thanks in advance!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.