Skip to Content

Update 25 Aug 2017: Added one more section at the end with a call to action, as well as links to other conversations on the same topic

 

Enterprise Services, anybody?

Back in the golden days of Service Oriented Architecture (SOA), SAP introduced ABAP proxy as an integration technology for ABAP-based systems. At that point, it was the latest and greatest by SAP to replace older approaches like BAPI/RFC and IDoc, and inline with SOA’s outside-in development approach.

With this came a whole host of SAP standard Enterprise Services (which were once listed in the now defunct ES Workplace).

In order to enable this new approach to integration, the following key components were introduced that cover the various stages of integration:-

  • Design time – Enterprise Services Repository for definition of service interfaces
  • Configuration time – XI adapter (and later on SOAP adapter with XI 3.0 protocol) to handle communication with an ABAP system’s integration engine
  • Runtime – Local integration engine on the backend ABAP system

Since the good old BAPIs and IDocs were no longer enhanced anymore, it made good sense to jump on the Proxy bandwagon. After all, it was relatively straightforward to implement an ABAP proxy with all the ABAP classes automatically generated for the developer.

 

The brave new world of HCI… err… Cloud Integration

These days, it is cloud everywhere, and for integration in the SAP space, that means SAP Cloud Platform Integration.

In the spirit of backwards-compatibility, one would have expected SAP to at least support n-1 of its latest technology. In this case, I would have expected an XI adapter…

or even a SOAP adapter with XI 3.0 protocol.

 

Sad to say, these are glaringly missing from the available list of adapters to be configured.

 

An interesting observation from the presentation packs for the past two years’ HCI/Cloud Integration Info Day shows that the XI adapter was available previously but not anymore. Even though it was for the SAP FSN platform, wouldn’t that mean that there is such a functionality????

Info Day 2016
Info Day 2017

 

And note, older technologies like IDoc (even RFC is reportedly on the roadmap) are available, which begs the question – why not the XI adapter?

 

Where do we go from here?

I recently heard a quote that “Integration architecture is not done in a vacuum“. This quote now seems particularly pertinent even though it might seem like this is just a small missing part (look at all the other adapters we have!)

If we look holistically at the end-to-end integration architecture, this missing part has a bigger impact on the solution. There are of course suggestions like this, but that to me is too simplistic.

For companies that have invested heavily into ABAP proxies as part of their SAP integration architecture, the alternatives do not look too promising. Some of them are:-

1. Switch to SOAP (either SOAP 1.x or SAP RM message protocol)

At face level, this would seem to be the path of least resistance. However, as we go deeper into the details, there are challenges in this approach especially from a BAU support perspective:-

  • To enable this, endpoints/bindings have to be maintained in SOAMANAGER for each interface. This is not a trivial task for companies which might have hundreds of such interfaces. Furthermore, it is not transportable and need to be configured in each system separately. Another potential issue is when non-production systems are periodically refreshed from a copy of the production system. Such configurations need to be manually updated accurately so that non-production systems do not mistakenly transmit data to the production system.
  • When switching to SOAP, the backend processing is now executed on the Web Service Runtime compared to the local integration engine. IMHO, the tools for administration and monitoring are not as robust and powerful compared to its SXMB_ cousins.

 

2. Return to IDoc (gasp!)

As mentioned earlier, it is surprising that SAP supports a far older technology and not its newer cousin. However, returning to IDocs (which have not had much enhancements for years) would require a revamp of all the interfaces. Not a pretty sight!

 

3. Develop own XI adapter

In the absence of a more favorable alternative, should we then develop our own XI adapter? This might be something worth considering since it is much easier to develop an adapter based on Apache Camel.

However, an additional point needs to be considered especially if the existing on-premise PI/PRO system is to be decommissioned in favor of Cloud Integration. An SLD is required during runtime processing in the local integration engine, so if PI’s SLD is no longer available, the potential replacement might be Solution Manager’s SLD.

 

Conclusion

While the cloud is all great and nice and innovative these days, it is not a trivial task when assessing the feasibility of “moving to the cloud” while leveraging investments in existing solutions. It might be relatively easier for a newer organization to adopt this compared to an old-time SAP customer which has heavily invested in SAP’s previous “latest and greatest”.

My burning questions to SAP are: Is the XI adapter intentionally left out? If yes, why?

For those of you who have gone through the same journey, or contemplating it, I would love to hear your stories and thoughts about this as well. Feel free to comment below.

 

Call To Action

Since this blog was posted, there have been many responses, and the conversations have continued on LinkedIn as well:-

Post on my profile

Post on SAP Middleware group

 

If there is a need/demand for the XI adapter in your organization or your client’s, I suggest that you take the following steps:-

  1. Reply directly here to Gayathri’s comment (due to the limitation of the platform, she will only get notifications on replies to her comment and not anywhere else) indicating your support for such a functionality
  2. Email her or someone else from the Product Management team indicating the requirement and demand
To report this post you need to login first.

19 Comments

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

  1. pavan thiruveedula

    Hi

    Eng Swee Yeoh,

    Thanks for sharing the info. If SAP could provide us the XI 3.0 message protocol or XI 3.0 adapter, It would be easy for us to use proxy based interfaces in order to connect to SAP based applications.

     

    Thanks,

    Pavan T

     

    (0) 
  2. Jelena Perfiljeva

    Good blog. I was not in the loop on this and don’t have any emotional investment in XI adapter, to be honest. But out of curiosity googled some old SCN posts. Just a few years ago it’s all “don’t use RFC, use proxy”. Yet still RFC is very much alive. 🙂 Funny how things turned out.

    (1) 
    1. Eng Swee Yeoh Post author

      “don’t use RFC, use proxy” – Yup, I myself advocated it here. But it’s important to distinguish the usage from an application layer vs communication layer perspective. As a communication protocol, I agree that it is very much alive in many of SAP’s product (even the newer ones).

       

      It’s more than 10 years ago that we were told “forget Web Services (the plain SOAP ones), we at SAP should go for Enterprise Services and let’s do it the outside-in way“, and now it’s like “nah, forget what we told you then…ooo.. have you checked out our new cloud product we have over here

       

      P.S: glad you were able to find this post amongst your activity stream! 😉

      (1) 
      1. Jelena Perfiljeva

        One just needs to mention “Enterprise Services” at TechEd to elicit spontaneous laughter. 🙂

        Btw only found this blog because of the Mentor tag. I don’t even go into activity stream these days.

        (1) 
  3. Vadim Klimov

    Hi Eng Swee,

    Excellent reflection on demanded, yet missing functionality in Cloud Integration! It looks to me like history repeats itself: I recall early days of Java-only scenarios (when they were only introduced in dual stack installations as an alternative to classic scenarios), where absence of XI adapter or its complete equivalent (as well as some other features that were not yet migrated from ABAP to Java stack) forced some customers to refrain from migration from classic scenarios to Java-only or upgrading their PI installations to ultimate Java-only usage types. Time passed and those features were introduced – XI adapter functionality was embedded into SOAP adapter in form of XI message protocol support, and so on. Now SAP Cloud Integration experiences similar symptoms. It will be really nice if Cloud Integration would gradually close feature gaps in comparison to what we got used to in SAP on-premises integration solutions – currently for reasonably meaningful portion of requirements, it sets dependencies to external services or other HCP components and complicates the way how integration flow has to be designed and implemented, whereas PI/PO provides them as a part of the product / built-in functionalty (here I don’t only mean connectivity, but also some features that exist for a long time as a part of core services of Adapter Framework).

    To add on this, I shall note that the organization I currently work for, uses SAP integration products (on-premises already live and looking into business case for complementing it with Cloud Integration) in parallel with more recent purchase of other vendor’s integration product, which although being hybrid by its initial design, is currently mostly used in its cloud deployement flavour within this organization. And when making feature comparison for some PO built-in core services and looking for their out of the box counterparts in there, I see that product has some similarities in ideology compared to SAP Cloud Integration in sense of paying major attention to connectivity (lots of application specific and generic technical connectors) – with primary focus on stateless, and mapping/conversion functionalities, and leaving some demanded supplementary features to a space of scenario design and development with dependencies on other external services rather than platform capabilities.

    I can see certain rationale behind bringing non-propriatory and open standards based technologies into SAP Cloud Integration in the first place, given the entire cloud nature of the offering, but I definitely agree that availability of IDoc and RFC adapters and absence of XI protocol support leaves some questions unanswered.

    Given efforts that have been already invested in both application systems / their local Integration Engines and PI/PO to optimize XI communication, it sounds reasonable to introduce XI support in Cloud Integration. Development of custom adapter for this might become challanging and time-consuming, but very much-esteemed exercise. Although XI protocol is SOAP based, runtime for it provides quite a lot of extra features for tuning and extensive monitoring capabilities – re-implementation of them all on basis of Cloud Integration is massive piece of work for the one who will step into custom development in this field.

    Jelena, although pure RFC integration (here I don’t mean something built on top of RFC – such as IDoc over RFC/CPI-C, etc.) has certain disadvantages for integration teams (mostly from perspective of day to day monitoring and performance tuning when we need to tune not RFC layer as such, but specific scenarios – and probably advocates of open standards may stress on its propriatory nature when it comes to integration with diverse non-SAP systems), to me lots of newer technologies, the way how they got implemented and used – XI/proxy, Gateway/OData – are examples of wrappers and tools placed on top, certain features that we can’t get easily out of the box in pure RFC layer, but under the hood, most of them rely on RFC one way or another – not from perspective of communication protocol, but from perspective of how consumer/provider logic is implemented and executed. And given RFC is time proved technology, I personally don’t really see reasons for it to fall into oblivion in the world of cloud integration.

    Regards,
    Vadim

    (4) 
    1. Eng Swee Yeoh Post author

      Hi Vadim

       

      Thanks for your comment – it would have deserved a blog post of its own! 😉

      And thanks for the history lesson – yes, I forgot that this too was missed out in the earlier days of the move to Java-only installation.

      There are definitely many organizations out there that are taking a “wait and see” approach to see how things pan out before considering a jump onto the Cloud Integration platform.

       

      Regards

      Eng Swee

       

      (0) 
  4. Ilya Kuznetsov

    Hi Eng Swee,

    XI protocol at receiver side is quite simple as far you can see. More complex task is to create XI-compliant message.

    More uncommon task is to create one entry point, analog of /sap/xi/engine — just now CPI-PI is bunch of IFlow with no interfaces and common addressing scheme, so for me XI protocol is not the only problem.

    Just imagine what URL will you fill on SXMB_ADM (on abap side)? What URL to use as receiver for Java-proxy side?

    (2) 
    1. Eng Swee Yeoh Post author

      Hi Ilya

       

      Thank you for your excellent insight into this. I totally missed out on the single point of entry required on the Cloud Integration side. Having all the endpoints related to individual iFlows and no single point of entry like PI’s adapter framework is indeed a limitation. There are indeed more pieces to the puzzle than just the adapter with XI protocol.

       

      For single point of entry, I could imagine a short term solution being a single generic iFlow with some kind of lookup table that could dynamically route it to other endpoints/iFlow.

       

      But I think there is also a need to step back and ask a question at a higher level – if the Enterprise SOA architecture that was prevalent (and recommended) in the PI days are no longer supported/applicable, what then is the recommended end-to-end integration architecture in the new world of Cloud Integration?

       

      Regards

      Eng Swee

      (0) 
  5. Gayathri Narayana

    Hello Eng,

    Thank you for your feedback and reflection!. This is valuable to us at SAP. We have been steadily growing our connectivity options and have doubled recently with new connectivity options being added like JMS, AS2, JDBC, OData sender, RFC . There is also focus on Non-SAP integration like with Salesforce, Microsoft Dynamics CRM, Amazon Web Services, Sugar CRM and we have introduced many SAP partner adapters too. For integration with SAP systems we currently have IDOC and now also RFC; and you can refer this blog to know about all the new and secure connectivity options introduced.

    With respect to the need for XI adapter, this is not a requirement we have received with high demand as against some of the other communication protocols. Having said that, it would be very interesting for us to know the use cases where this would be invaluable.

    Best Regards,

    Gayathri

    (1) 
    1. Eng Swee Yeoh Post author

      Hi Gayathri

       

      Thank you for your response, as well as the direct message. I will respond to your PM regarding the specifics of the request, but on the larger part I will keep my response here since there is an interest from the wider community.

       

      I am surprised that this is not in demand compared to other protocols (how is that demand gauged and where are these requirements coming from?). I do not see it as merely a connectivity option. In fact, it is one of the key components enabling an integration architecture based on proxy interfaces. As such the absence of it has implications on the end-to-end design.

       

      Regarding use case, I managed to dig up a copy of the Enterprise SOA Development Handbook that was published by SAP in 2008. This basically outlines the whole architectural strategy underpinning ESOA, and of particular note, page 39 states “When creating new services, SAP recommends that you use the outside-in approach“. You can imagine how widespread this would be (unless customers don’t follow SAP’s recommendations – *gasps*!)

       

      As mentioned by Vadim above, there is also historical precedence when SAP had to eventually provide it to enable transition to single stack Java installations. That in itself would imply that there were demand for it.

       

      Also, in one of my previous roles (nearly a decade ago) with an implementation partner, it was an architectural decision to design all interfaces for proxy based communication (over IDoc or RFC) at every client project. As far as I know, this is still true at that partner, so you can imagine the client base having such a requirement.

       

      Hope to hear your thoughts on this.

       

      Best regards

      Eng Swee

      (0) 
      1. David Rodriguez Diez

        Hi everybody,

        I am reading the comments (which are almost as interesting as the blog itself) and I’m really surprised to see a SAP Product Manager to say there is no big demand for XI Protocol integration. As Eng Swee said in his reply, I have been suggesting the development of proxy based interfaces for several years according to SAP guidelines. I would love to see how many companies SAP surveyed and some info about companies sizes and status.  It is not the same to ask a company facing their first SAP S/4 implementation than a company with a 10 years old implementation.

        BR,

        David R.

        (1) 
        1. Eng Swee Yeoh Post author

          Hi David

           

          Thanks for your comment. I’m glad to hear that indeed there are many out there that are following SAP’s ESOA guideline in the past, and do indeed have a demand for it now.

          Due to all the other responses like yours, I’ve added a new section at the end of this blog – Call To Action. 

           

          Regards

          Eng Swee

          (0) 
    2. Jens Schwendemann

      I second Eng Swee here, as we are approaching our first real world integration carried out with SCPI. SOAMANAGER and the respective tooling is far from sxmb_ tools.

      (0) 
  6. Vijayashankar Konam

    Hello Eng and @gayathri.narayana,

    Great that you brought this up on a public forum, where SAP could actually look at. This was the first question that popped in my mind when I glanced at HCI for the first time. I did ask the same in one of the SAP HCI product sessions and got the answer that, they do not have any plans to build the XI adapter for HCI.

    The reasons that I inferred from SAP’s perspective were –

    1. SAP HCI is built on Camel and it is payload agnostic. But the XI adapter works on the XI protocol which is specific to SAP PI/Integration Server and the XI message format.
    2. In PI/PO pipeline steps the XI message is bounced every where and hence it might have made sense. But in HCI, it would only be required between the adapter (channel) and the iFlow entry or exist points.
    3. XI adapter on ECC requires SLD and HCI does not need it.

    However, for us, the developer/user community, the SOAMANAGER and SOAP communication directly from ECC is a pain and I never liked it. I recently started experimenting with sending the messages from ECC to HCI via HTTP destination similar to the way we post to PI AEX or IE. That is when it clicked to me that I could simply parse the message and extract the actual payload and get done with it. However, on the receiver side and for sync responses etc., I had to explore more. That is where I am right now.

    My use cases as requested by SAP above are,

    1. SXI_MONITOR is a lot better monitor than SRT_MONITOR.
    2. SOAMANAGER configuration is not transportable on ECC systems.
    3. Since, SOAMANAGER is based on web, the usual ABAP FIRE FIGHTER roles do not work and requires the developer be given some additional roles, which are not given in a production environment usually.
    4. No more SOAMANAGER config and simply maintaining the IS_URL parameter in SXMB_ADM of ECC, the message could either be routed to PI/PO or HCI.
    5. Instead of XI adapter, just an HTTP adapter on the ABAP stack of ECC solves all the problems  :-). We just need ways to point it to the correct iFlow and be able to send messages to it.  I know this is not as simple as it is said but just my 2 cents.

    I hope SAP gives me my XI adapter before I figure out my own way of bypassing the SOAMANAGER and SOAP runtime.

     

    Vijay Konam

    (2) 
    1. Eng Swee Yeoh Post author

      Hi Vijay

       

      Thank you for your own experience and thoughts on this. The pain points you described with using SOAMANAGER and the Web Service Runtime are exactly what we faced and trying to avoid – thanks for detailing them, as it complements the argument presented in this post.

       

      Even if you switch to using a HTTP destination, it could only point to a single iFlow, which is the challenge mentioned by Ilya above – no single point of entry. Imagine if you have hundreds of outbound proxies, you have to create that many HTTP destinations, create entries in SXMSIF and configure the subparameters of IS_URL – painful and tedious!

       

      I think the point of Camel being payload agnostic doesn’t really hold considering the fact that SAP-specific technologies like IDoc and RFC are supported. The reality is, most organizations that currently have PI/PRO are traditionally “SAP shops” and PI/PRO have the advantage of providing SAP-specific integration technologies. Also if Cloud Integration goes the way of providing agnostic connectivity, then IMHO it does not hold much advantage over Gartner Magic Quadrant leaders like Mulesoft.

       

      Anyway, would love to hear more from you especially if you have found a good way around this.

       

      Regards

      Eng Swee

      (0) 
      1. Vijayashankar Konam

        My idea was to develop a router iFlow on HCI using VMG :-). I did do something like that on PI for 10s of interfaces that we have from another middle-ware into ECC. So, I already nailed it there.

        VJ

        (1) 
  7. Jon Vaughan

    Our conclusion was that HCi or whatever it is called now was not suitable as a cloud only solution and could only work for us in a hybrid model with PO.

     

    Which is why we didn’t bother with it.

    (1) 
  8. Trevor Naidoo

    Eng Swee,

     

    What a fantastic blog post! It’s almost as though SAP is oblivious to long standard SAP customers that are heavily invested in ABAP proxies :-).

    We’re facing a similar conundrum at a huge SAP customer. We built this whole capability (including a support model) around SAP Enterprise Services and reusability of services that were already built – and now we’re stuck!

     

    Facing a few key decision points as an SAP customer at this stage – and the most likely option is discontinuing any further investment in any SAP middleware/s. But that also leaves us staring down the barrel of moving backwards towards BAPI’s and IDOCs (and potentially web services through SOAMANAGER – which I will never do because of very poor support options) because other middleware solutions seem to be limited to SAP JCO connectivity optins into SAP backend systems – because that’s all that SAP offers. It’s like a hostage situation which I would dearly love to get out of as an Integration person 🙂

     

    Regards, Trevor

     

    (1) 
    1. Eng Swee Yeoh Post author

      Hi Trevor

       

      Thank you for your comment here as well as on LinkedIn.

       

      It is comforting (in a weird way!) to know that we are not the only one facing this conundrum. Hopefully feedback and comments from the community members (such as yours) will help prove that there is such a demand among loyal SAP customers who have faithfully followed SAP’s recommended architecture in the past.

       

      Regarding your options, IMHO moving back to BAPI or IDoc would really feel like a step back to the last century! I would want to say go for OData (on Gateway) instead, but then that will only cover one direction… which leaves you still stuck on the outbound side architecturally… sigh..

       

      Regards

      Eng Swee

      (0) 

Leave a Reply