OutSystems is being used more and more by large enterprises to innovate the way software is being developed. This means that OutSystems needs to be integrated with the enterprise’s massive legacy systems, which almost always is SAP. OutSystems has a native connection using SAP’s .Net Connector, but can also work with other protocols like OData, SOAP and REST. How to choose the best way to integrate, in light of the many integration options there are?
The good news is that OutSystems and SAP mix quite well: integration from OutSystems to SAP is quick and simple, regardless of whether you use BAPIs through the SAP .NET Connector or OData services exposed through the SAP Gateway.
But while the technical integration is easily achieved by any OutSystems developer, building the actual applications requires quite some knowledge of SAP itself, which is a world of its own. In this article I will only focus on the technical quirkiness of SAP and what to bear in mind when integrating, focussing on RFC and OData.
Which type of integration?
SAP .NET Connector
The quickest way to start integrating with SAP is through the .NET connector. Once you establish a connection, you can instantly start using the 50.000+ remote enabled functions, called RFCs or BAPIs. Below is a screenshot how you can connect, much like setting up a connection through SAP Login pad.
Technically the .NET Connector is quite complete and mature. It offers options for the most common scenarios, like connecting to SAP through an application server or connecting to a message server (SAP lingo for load balancer). Or letting SAP decide how to handle your request or use a dedicated queue. Another important feature is that it allows the developer to limit the number of processes that will be used on the SAP server, so OutSystems cannot claim all available dialogue processes, which would effectively kill the SAP server. Also, the connection is lightning fast, returning data quicker than when requesting the data on an SAP screen. The .Net connector is also available in the on-premise and private cloud versions of S/4HANA.
There are some downsides to using BAPIs. One of the annoyances of working with SAP is that the platform has not been programmed consistently. A simple example: in one program pressing F6 means ‘Change’, while in another program pressing the same button suddenly means ‘Display’. The same goes for BAPIs: some have an inherit COMMIT WORK, while others need a separate call to BAPI_TRANSACTION_COMMIT to make the database updates persistent, for instance. Next to that, the RFC library is quite complete for some function areas, like Warehouse Management, but inexplicably does not have functions for many other common actions. And sometimes there is a BAPI available, but it does not cover your scenario fully. That means you always need to do a full functional analysis whether SAP has the right BAPIs available to cover the requirements. In practice this sometimes means that integrating with SAP becomes a trial and error game, with unexpected impediments popping up that jeopardise development timelines.
OData Services
SAP has chosen OData as its preferred way of interfacing with external platforms through the SAP Gateway. Many objects in SAP, like RFCs, object methods and CDS views can be exposed as OData services. The SAP Gateway handles traffic and ensures communication is decoupled from the application server, a sound architectural principle. OutSystems can handle the OData protocol well and offers a service for easy integration with OData services, called the Integration Builder. Below is a screenshot of the Integration Builder:
After importing the OData JSON, entities and actions can be selected, that will then be created in OutSystems. One of the strong features is that for entities not only the entity CRUD actions will be created in SAP, but also search actions.
Although SAP advises using OData and is investing in creating more services, the current library is quite limited and hard to navigate. For instance, at api.sap.com there are only 187 OData API available for download for S/4HANA. Effectively this means that you will need to build all your OData connections to OutSystems, if you choose that as your preferred way of connecting.
A serious downside is that, once you start building OData services, you will be dependent on your company’s SAP release calendar, which might cause a delay in go-live of several months. To avoid that, you need to get an agreement with the SAP delivery team that stand-alone developments of OData services for OutSystems projects can have a separate release track to production.
Conclusion
What type of integration to chose? .Net is quite simple to implement and has a vast library of services, but those SAP services have not been programmed consistently and need analysis. On the other hand, OData is architectural in line with SAP guidance, but offers limited functionality and developing new OData services can potentially delay your go-live significantly.
Personally I am of opinion that you can use both. Definitely use the .Net RFC connection for quick prototyping of PoCs and for validating your ideas. Then, if you have proven that the solution direction works, you still can make the choice to recreate the functionality in OData, if that is your company policy.
If you would you like to know more? Please reach out to me at r.vandekerkhof@novioq.com!
You must be logged in to post a comment.