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.
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:-
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:-
- 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
- Email her or someone else from the Product Management team indicating the requirement and demand