Integration with SAP is a hot topic, now that companies moving to S/4HANA are embracing a lean core strategy, meaning that they intend to build any extra functionality outside of SAP, if it does not logically belong to the core. In my previous article on OutSystems and SAP integration I focused on this already, but very much from a technical integration point of view. But what is the best pragmatic approach that will bring the most value to your organisation?
SAP allows you to execute code on its application server for reading, changing, creating and deleting data. This is a one-way street, meaning that an external system calls these functions on SAP. In the previous article I wrote about the differences between using OData or the RFC connector, with pros and cons of both from a purely architectural point of view.
But for IT specialists it is becoming more and more important to not just take decisions solely from a technical point of view, but also to take into account the needs of the business. One of the things business demands is to have much shorter delivery cycles of demand. The SAP delivery times of 6+ months are simply not acceptable any more in fast changing environments. That is where bi-modal development comes in, with different development and delivery paces for your core systems and your fast and agile low-code development street.
Agility and quick time-to-market is something the business craves for, but the IT organisation can not deliver on that promise, even when using a low-code platform, because of formal policies. In weeks we can build a game-changing product in OutSystems, that the business is wildly enthusiastic about, and is begging to go live as soon as possible. But go-live is suddenly postponed for months and months, because the product was built using the SAP RFC connector. The company SAP architect does not allow RFC connections in production, so new OData connections need to be created from scratch, resulting in a huge delay that is pretty hard to explain to the business.
Normally we always adhere to the policies of the companies we work for, but in this case I do feel the need to speak up and challenge this. What value is the architect delivering to the company by causing this delay? Is he preventing a serious risk to the company? Are there downsides to the RFC connector that will jeopardise the stability of the core systems? None of these things, the architect says no because it is a guideline within the company.
To be perfectly clear: the RFC connector is a piece of software that has been in existence for decades and is at the heart of SAP platforms, including S/4HANA. SAP uses this connector itself for communication between SAP systems and non-SAP systems. Actually, it is quite telling that RFC technology play a key role in the connection between the SAP Gateway server and the SAP application server, when calling an OData service.
Some of the features of the RFC connector:
- It is highly secure
- It is blazingly fast
- There are 50.000+ remote enabled functions available that can be used out-of-the-box
- You can call functions using named users
- Sessions can be stateless or stateful
- The number of threads used on the SAP application server can be throttled
- Use of qRFC and tRFC is possible
This list is far from complete, and goes to show that the technology is robust and complete. It is so reliable that SAP itself uses it continuously. So why do almost all companies push dogmatically for OData without an open discussion? The main reason I can come up with is that SAP advises using OData as the way forward and that the RFC connector might be discontinued in future. I get that that is really important, but at this moment the RFC connector is still supported in all SAP releases, with the notable exception of the SAP cloud version – and moving to the SAP managed cloud is an effort that will be a huge project for all enterprise clients of SAP and is not a path enterprises are likely to take in the coming years.
So why not allow use of RFC connections? It will speed up go-live of business critical applications significantly and deliver value early. Why build the OData connections now, with all associated cost and effort, when you can also do that once you would actually need to – when SAP discontinues support, for instance, which is highly unlikely to happen the coming decade?
Besides the added cost and delay there is another implication: once the OutSystems application connects to the custom built OData service, you lose the speed with which you can extend the application. When using the RFC connector, you can keep adding readily available SAP functions in coming sprints, based upon customer feedback. When you have shifted to OData, all changes involve SAP development and you lose all agility. It defeats the purpose of bi-model development and will frustrate the business, that needs to wait again for months for the promised functionality, while the OutSystems team sits idly.
Even if the company would persist that OData is the way to go, then I suggest to allow using RFC during project mode and register this as technical debt that needs to be solved before the development is handed over to the support team. That way the project can deliver value quickly every sprint, without waiting for the OData service to have gone live; and at the end of the project, once the application is fully tested and stable, then the RFC calls are replaced by OData services – OutSystems supports both protocols, so it is an easy change. That way you will bring value to the business fast, while the end product will adhere to your internal standards – the best of both worlds!
If you would you like to know more? Please reach out to me at r.vandekerkhof@novioq.com or visit us at www.novioq.com.
Roy van de Kerkhof
P.S. In my next article I will focus on making this a two-way street, where SAP can also inform external systems of any changes, but you will have to have some patience for that one to be published.
You must be logged in to post a comment.