Mobility is the latest buzzword in the Enterprise Applications space. As each day passes, we see organizations enabling the business application on their back end enterprise systems onto mobile devices. With HTML5, rich UI capabilities have also become the focus of many web applications that are being built across customer implementations. Yes, it is only natural that employees, vendors and customers of a business start demanding more of the data for their day today activities be made available on portable devices.

From a web services framework, we have seen a slow transition take us through SOAP messages to RESTful services. Now REST is considered lightweight web services (how lighter can they get eh?) and for those who are finding the terminology new, I will recommend reading this : Learn REST: A Tutorial

As one thought of taking a rest from REST, we were introduced to OData. Wondering what OData is? Read this.

PS: Crash course on OData? Then click here.

Eventually this transition meant that there was a huge amount of data within the backend enterprise systems that were waiting to be unlocked for the use of Mobile and Web applications. This is where integration enters the scene.

Today, SAP customers have two options to enable integration and expose the business logic as simple RESTful or OData services. SAP Process Integration and SAP Netweaver Gateway would look to facilitate these integration needs.

What is SAP Netweaver Gateway?

Project Gateway as it was known earlier, SAP NW G/W is:

a. The point of access into SAP Business Suite data and functionality

b. Uses a non-proprietary interface based on the Open Data Protocol (OData)

c. Service(s) can be consumed by any channel that can process XML received over an HTTP(s) connection

I am sure the first question that comes to the mind of many readers is going to be, “Why two toolsets? Isn’t this duplication of the Integration layer?”

Since this has been a topic debated for long, I will provide references for the readers to understand and arrive at their own judgement regarding this;

a. NetWeaver Gateway and PI – There’s a place for both!

b. Gateway or Process Integration – which is the Right Tool for the Job?

What is the truth?

The truth is that majority of our customers run their businesses on heterogeneous environments. This in very simple terms means that the backend business logic is locked within SAP and Non-SAP applications.

aug2013_1.JPG

PS: The above reference to a MEAP is in the context of mobile applications. Many a time, the layer can also act as a reverse proxy.

Now in PI, at present there is no REST capability available as part of the standard installation. Almost every customer is dependent upon the REST adapter from Advantco which translates to additional costs for licences. NW Gateway is also procured via additional licences.

What usually one ends up with?

If you would have read the articles that I had referred earlier, you will understand that both the REST adapter and Gateway eventually find (are forced to?) a place for themselves. Gateway’s capability primarily lies in unlocking data on a SAP backend. It cannot, I repeat, it cannot integrate with non SAP backend and create services for you. Now on the other hand, a solution on PI would have the advantage of integrating with any backend since its characteristics of being an ESB. But a key difference that one will find between PI and Gateway is that Gateway exposes OData services while PI REST adapter does simple RESTful services with no OData capability.

This poses an architectural problem. So as of now, for a SAP customer to develop a mobile or web application on a heterogeneous landscape, it becomes inevitable that they;

1. Buy extra licences – Higher TCO

2. Find themselves using a combination of multiple standards i.e Simple REST and OData (so much for standardization)

3. Lose a holistic view of integration – Multiple layers of integration

What could be done?

Gateway only approach:

We could argue that a SAP customer usually has most of his business processes running on his SAP backend. Hence a majority of the service enablement will be for data on the SAP application. With this assumption, the remaining Non SAP data needed to be service enabled, could be fed into SAP, stored in custom tables (or wherever) and then again via Gateway expose them as OData.

Here the assumption that we make is that 70-80% of the backend data that is needed for the mobile and web application resides in a SAP backend. Yet, we need to factor in costs of having the non SAP data made accessible via Gateway i.e building additional interfaces (Non SAP to SAP), customization in SAP, data maintenance etc.

PI Only approach:

In this case, a big drawback would be that OData support is not available. The IDE plugins and other accelerators that come with Gateway will also be lost. But the advantage would be that integration would be seamless and consistent in a heterogeneous environment.

SAP does something:

Now this is an aspirational option where SAP consolidates the product and defines a single strategy. With heavy investments already on Gateway, enhancements could be made to support non SAP backends. This will clearly dictate a one tool approach. I am also aware that SAP is working on a standard REST adapter that would be an alternative to the 3rd party REST adapter now available. But until it settles, the waters are still muddy and I believe a combination of Gateway and PI will be what most customers will end up with.

Update [09-April-2014] – Integration gateway seems to be one of the first steps in enabling OData of non-SAP backend.

Afternote:

What are your experiences on this topic? What is your organization’s strategy for mobile and rich UI based applications?

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Samuel Redondo

    Very interesting blog, thank you for this!

    From what I read if you buy the 3rd party PI REST adapter it will come with ODATA support. Which would mean that for your PI only approach there would not really be a drawback except for the additional license costs, right?

    From my experience companies are not keen in investing in several integration tools. I see that PI is usually the preferred option in an SAP environment due to its universal capabilities.

    Regarding mobile developments in the projects that I have had there is still a majority of SOAP integrations, but I can see some shifts in big software products such as HANA or also 3rd party products like Hybris which rely heavily on REST integration.

    All in all I think it will really be necessary for SAP to position PI/PO clearly as THE strategic middleware tool within SAP and enable it also for integration scenarios involving REST/ODATA.

    (0) 
    1. Shabarish Vijayakumar Post author

      The 3rd party adapter as of today does not support OData 🙂 Additionally, Gateway comes with many accelerators that helps speed up development when building applications.

      (0) 
      1. Samuel Redondo

        Hmm, according to the product page:

        https://www.advantco.com/product/REST

        • Endorses Open Data Protocol (OData), a Web protocol for querying and updating data using Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications

        Do you mean something additionally when mentioning missing OData support?

        Accelerators are a good point. I guess it is the specialty of GW to REST enable SAP content very quickly while you will still have the classic pipeline development approach on PI.

        (0) 
        1. Shabarish Vijayakumar Post author

          well yeah… it does say endorses. its a misnomer 🙂 we are using both the adapter and gateway for one of our projects.

          frankly, i would have loved to seen gateway like capabilities to be part of the integration suite rather than having different solutions encouraging P2P like integration. I must say I am not sure what is the strategy around enterprise integration when it comes to SAP.

          (0) 
          1. Sebastian Simon

            +1 reply to.

            Many ppl also forget, integration is a bidirectional topic. Publishing: fine, but you should be also able to invoke REST services at ease!

            P.s.: there’s 2 REST adapters by now: advantco and kaTe (that comes with an API console to publish RESTful services).

            Cheers

            (0) 
  2. Sebastian Simon

    Hi Shabarish

    Good summary of the topic, imho the dual existence of NW GW and PI has led to some confusion at SAP’s PI customers.

    Although many ppl in scn have tried to point out that both serve different purposes, the functional overlap is definitely there, especially if you come across adding non SAP systems.

    (Wasn’t unification of system access what we all learned about SOA? 😀 )

    It’s interesting to see the latest developments you blogged about from teched LV.

    My POV:

    The picture above exactly pins the pain point of unified access across SAP/Non SAP systems. Will be interesting to see how SAP works on the unified tool approach and how fast they work on it.

    From a bird’s eyes view of a company outside the SAP/SCN scope don’t forget a picture like above is an easy advert to not use any of the tools mentioned above at all. Think of doing it here and now!

    Many companies run their heavy rolling / SOA on existing other plattforms  (the Mule’s, TIBCO’s, SAG’s or IBMs) that will easily come around this limitation and have answers to questions that come on second “operational” row (rate limitation to avoid trashing your backends, caching & call billing).

    Not everybody is on the oData train for the mobile space which is neither good nor bad.

    (e.g. netflix dropped it a while ago and ebay silently seem to back off it too), or think of initiatives like Swagger/RAMl etc.

    Best regards

             Sebastian

    (0) 
  3. Christian Loos

    Hi Shabarish,

    Thanks for the excellent blog. You are raising some very valid questions.

    Let me try to clarify things:

    1. Process Orchestration (including PI, BPM and BRM) is the strategic on-premise middleware platform for SAP.
      We see more and more PI customers moving from dualstack PI to PO java-only, and we will continue to invest into making the solution even better.
    2. As explained in our roadmap sessions at TechEd, REST/ODATA connectivity for PI is planned for next year.
    3. We also plan to bring Gateway capabilities to the PO platform – very similar to the Gateway for Java in SMP3.0 (which you have described in your “Birds Eye” blog).
      This would allow application logic which is implemented in Java on PO (e.g. EJBs, JPA) to be exposed as ODATA.


    Regards,

    Christian

    (0) 
    1. Shabarish Vijayakumar Post author

      Thanks. That is very exciting news. I sure do hope SAP consolidates onto a single platform when it comes to integration.

      There have been many pundits arguing that NW Gateway has its own place. I can see the point but yet many organization envision that as another additonal middleware layer to maintain. Thus with multiple hooks into the backend via multiple platforms, it becomes difficult to manage and manitain visibility of the landscape. The skills also vary in each of these cases.

      Hopefully if PO becomes comprehensive, i guess many of the concerns would get addressed.

      (0) 
  4. Saumil Jyotishi

    Nice blog really!

    A few observations though. Gateway licencing is now much simpler since last December.

    If you have licence to access application A in back end, you automatically have licence to expose it via Gateway. So now no additional costs are involved!

    The interesting topic to discuss is if PI becomes comprehensive in this context as well, how to think while making a decision about OData exposure in your landscape.

    There are high chances that customers will end up having NW Gateway in their landscape as well because of many possible reasons:

    a) It is now shipped with NW 7.4 out of the box

    b) Already more than 8K productive installations and thus can be called a very successful product

    c) Almost all Fiori apps are based on OData exposed by Gateway

    d) Easy migration of ABAP developers to Gateway developers.Good design time and has become a stable framework since past 2 years

    I now think that eventually more and more and more customers will end up with both products and will have to make them do what they do best as part of their integration landscape.

    (0) 

Leave a Reply