Introduction
Integration is today often a very technical job by transferring data form a sender system to a target application. The integration job is by sure part of a business process, but integration developers often only handle a small part of it. I propose to extend integration use cases to a broader scope and to bring integration- and extension DevOps teams closer together.
From a technical perspective Marcel proposed a very interesting approach in his blog: SAP Integration Suite: Resilient APIs using API Management, Event Mesh, and Cloud Integration
Other interesting sources to build up a modern integration architecture are:
- SAP Integration Solution Advisory Methodology: Template version 4.0 available now
- Modern Integration for SAP S/4HANA and RISE for the challenges of today & in the future
- Exploring SAP’s Integration Strategy: Free eBook Available Now
I would like to explain my idea with a concrete use case, that I recently implemented and is today operating in production. Beside the target architecture I’ll try to describe some differences to the integration approach, that was often implemented before.
Use Case
The use case is to create a channel agnostic order interface as entry point for sales orders from different channels, countries, systems or applications. It should be very easy for the clients to adopt the interface to support flexible and dynamic business models.
Implementation
Implementation Overview
The solution is flexible and can address multiple and different sender application like new sales channel or messages from different countries or subcompanies. The touchpoint for all clients is the SAP API Management, that handles the authentication, documentation of the API for developers, a technical format check of the payload and some more. The CAP services a persistence layer with the HANA Cloud, a Fiori UI with an End2End monitoring and an ODATA API to create sales orders or to update the processing status of the orders. The Cloud Integration is called by the CAP service and send the sales order to an ABAP Proxy in AIF after a format conversion with Groovy. In SAP S/4 HANA, the AIF convers the integration logic and brings a monitoring and alerting for the business to guarantee the efficient and correct processing of the orders.
Backend Implementation
Backend Implementation
A part of every interface is business logic: sometimes it could be covered by SAP standard functionality, but you often need some custom logic and of course you need a monitoring to control the processing of your orders. The logic was sometimes added to the middleware (SAP PO), but mostly added with coding in the SAP ECC or ERP. That oft created a lot effort when adding new sending systems when a new logic must be added and of course all other running integrations must still be running successful. With our new approach the specific logic is orchestrated in the AIF and very simple to change and extend without potential interruptions for other scenarios. A second and very powerful capability of AIF is a business user monitoring with a lot of convenient options to do it in a very efficient way.
(External) Client Onboarding
(External) Client Onboarding
For onboarding new sending systems, traditionally there where some meetings, mails, exchanging documents etc. were needed. Also the tests took some time for setting up environment including test data and often also technical and network infrastructure. All these jobs are being done with a self-service onboarding, where you only need to give access to the developer to the SAP API Business Hub, where he can find everything form documentation, creating authentication data and test his solution. With using the API gateway, you can use modern security mechanism to make it easier and saver to integrate your SAP backend with other systems.
Documentation and Developer Experience
Documentation and Developer Experience
Monitoring
Monitoring
Monitoring should be a a simple and intuitive task, also for business user and people, who don't use SAP all the data like power users. With the integration of the future, there are easy to use Fiori Apps with the SAP AIF, but there we can't combine the complete view for the use case. Therefore I suggest to create a very simple - solution specific solution - for our use within the CAP Service. There we collect the logs and status starting from the API but including the logs from the SAP backend. This app could be uses by everyone in your organization, also without VPN access. Beside tracing concrete sales orders, you can easily generate some reports and export them to Excel.
Resilience & Business Continuity
Resilience and Business Continuity
SAP backend systems will have some downtimes form time to times to implement upgrades or security patches. That should not effect your APIs or integration solutions. With the new way, we will store every sales order in SAP HANA Cloud and Cloud Integration, or the SAP CAP service will resend messages in case or errors or when a downtime of a system is over.
Flexibility
Flexibility
In case of changes in the backend your sending applications should net have a need to change their implementation. These changes could happen due to a upgrade of your SAP system or with a change in your process. Otherwise, if you want to improve your process, which includes a change in the API or integration logic, you should be in the position to do it fast and save without breaking other partner. That can't be done perfectly with a SAP clean core implementation, where you can add logic interface specific in AIF or in the CAP service.
Upgrade Stability
Upgrade Stability
Conclusion
What do you think? Will this approach be valuable for you? Do you think that the effort for implementing will be too high? Will it be possible to do integration in five years with the same tools and way of implementation like today?
I'm looking forward to your ideas, experiences and thoughts!
Stay up to date and follow the topic page, post and answer questions, and read other blog posts.
- SAP Managed Tags:
6 Comments
