According to SAP and independent estimates nearly 80% of the world’s electronic business transactions touch an SAP system at some point. This is a factor in virtually every digital transformation initiative in the business world today. If a company seeks to open a new digital route to market, at some point the company will need to integrate and connect transactions with its systems of record.

At the same time that new initiatives need to account for interactions with SAP’s software, the deployed ERP systems themselves are in various stages of evolution. The longtime flagship of SAP’s technology has been the R3 system, still widely deployed. However, in 2010 SAP debuted its HANA technology, an in-memory, columnar relational database management system (RDBMS), and followed this up in 2014 with S/4HANA, a rewrite of the ERP technology to run over HANA. In addition, as has been done by many business software vendors, SAP offers S/4HANA in a hosted (cloud) version. 

Not surprisingly, SAP has tried to minimize the difficulty of upgrading, by preserving the interfaces into and out of SAP S/4HANA that were available in SAP ECC/SAP ERP/SAP Business Suite. Still, SAP S/4HANA is a rewrite, and the expertise of administration, configuration, development, and monitoring between the systems is different. 

Not surprisingly, migrations have been complicated in many cases, and of course, many organizations have not migrated simply because SAP ECC/SAP ERP/SAP Business Suite has continued to satisfy their ERP needs. SAP of course has a strong incentive to make migration as simple as possible, and has a strong incentive to move customers off of its legacy technology and onto the newest platform (as do virtually all software companies). 

 

Therefore, SAP ECC/SAP ERP/SAP Business Suite customers have a looming deadline (currently scheduled for 2027) for end-of-support. While five and a half years (at the time of this writing) seems like a long time to move to a newer SAP product (or possibly to a new ERP), IT executives know that these are complex systems intertwined with multiple fundamental business operations that take time to refactor. 

Clearly, the majority of the largest businesses in the world are at some stage of a substantial  migration. Anecdotal evidence suggests that many businesses are early in this migration. Recall again that businesses are in substantial upheaval already because of the business impacts of the COVID pandemic, the transition from three tier development to cloud native development, and the evolution to the hybrid cloud

Challenges for SAP migration

Today’s companies that rely on SAP’s ERP technology face several key challenges that did not exist twenty years ago:

  1. Migration from SAP ECC/SAP ERP/SAP Business Suite to SAP S/4HANA

  2. Increasing demand of interfaces from systems of record (e.g. ERP systems) to systems of innovation (websites, mobile apps, partner channels, SAAS)

  3. Culture and organizational changes related to software development for the hybrid cloud

These challenges put a strain on the use of integration technologies used by the companies, and the companies are finding that many of their legacy integration systems are not about to serve against these challenges.

Integration technology exists to facilitate the transfer of data synchronously or asynchronously between multiple applications. Developers have always had the option to write interfaces in their own code (“point to point integration”) but integration technology grew out of several inefficiencies related to point to point integration, including:

  1. Transforming, routing, and validating payloads between different formats is tedious and time consuming to configure in code.

  2. Wire and application protocols that vary between applications.

  3. Providing updates to administrators and other applications about the health of interfaces is complex.

  4. Enforcing security in a myriad of protocols demanded by today’s application is beyond the capabilities of most developers.

Integration technology over several years has been able to overcome these inefficiencies, generally by providing: 

  1. Productive, graphical canvasses for easily configuring complicated transformation, routing, and validation.

  2. Connectors that encapsulate complexity of communication in re-usable units

  3. Centralized monitoring.

  4. Preconfigured security profiles, generally configured from a simple, declarative interface.

While these achievements are substantial, many integration products that have been suitable for integrating SAP ECC/ERP/Business Suite with many systems inside and outside the enterprise will find it difficult to migrate to SAP S/4HANA, compounded by the cultural and organizational changes of microservices development. 

The predominant model for the last generation of integration technologies is the Enterprise Service Bus (ESB). The ESB is a server process, like a database server, that is operated, configured, and maintained by the central IT organization that often operates, configures, and monitors the ERP applications. The ESB is typically deployed inside the IT department, which usually means that changes to the IT systems usually occur in nine to twelve month waterfall life cycles. 

The systems of innovation that are competitive differentiators for a company are generally not owned, built, or maintained by the IT department. They are, rather, staffed by agile developers executing DevOps sprints in two week cycles. That means the agile developers can’t wait for a nine month waterfall execution. Furthermore, microservices developers typically deploy their containers using DevOps pipelines. ESBs can not “fit” into containers — ESBs are server processes that are updated with proprietary GUIs. 

Finally, part of the agility that agile developers seek comes from minimizing dependencies on external groups. To this end, agile developers prefer “self-service” integration; being able to subscribe to streams of data or APIs to invoke (assuming adequate security checks). The ESBs have no provision for self-service. 

The gaps in the ability of ESBs to serve microservices has led to the rise in what Red Hat calls “Agile Integration” technology. These solutions are characterized by 

  1. Productive canvases that lead to integration logic that can be deployed as microservices in a devops pipeline

  2. Strong registries and portals for self-service and governance

  3. Monitoring, management, and deployment by technologies that are already used by microservices developers and operations teams

Red Hat Integration is Red Hat’s implementation of these agile integration principles. Red Hat Integration includes comprehensive integration and messaging technologies to connect applications and data across hybrid infrastructures. 

 

It is an agile, distributed, containerized, and API-centric solution. It provides service composition and orchestration, application connectivity and data transformation, real-time message streaming, change data capture, and API management — all combined with a cloud-native platform and toolchain to support the full spectrum of modern application development. 

In addition to strong general support for all aspects of integration, Red Hat Integration has specific assets that make integrating various SAP applications much simpler and faster, as described in the following sections.

Effective SAP Integration

SAP has made integration and open source a priority since the advent of OData solutions like SAP NetWeaver Gateway and OpenAPIs for many of their products. In addition the Java Connector (JCo) has enabled partners and developers to create SAP Certified solutions to help keep the SAP digital core clean. 

Customers can now build their enterprise applications and logic dependent on SAP and non-SAP data in a modernized application development platform like Red Hat OpenShift. Furthermore, integration is possible using side-by-side extensibility without creating custom code in ABAP environments, thus decoupling business logic and data.

Components in Red Hat Fuse (part of Red Hat Integration) for SAP

camel-sap: JCo connectivity for bi-directional communication with SAP ABAP environments.

Supported patterns for the camel-sap component

The SAP component package provides the following RFC and IDoc endpoints:

sap-srfc-destination

Synchronous Remote Function Call Destination Camel component. This endpoint should be used in cases where Camel routes require synchronous delivery of requests to and responses from an SAP system with best effort.

sap-trfc-destination

Transactional Remote Function Call Destination Camel component. This endpoint should be used in cases where requests must be delivered to the receiving SAP system at most once. To accomplish this, the component generates a transaction ID, tid, which accompanies every request sent through the component in a route's exchange. 

The receiving SAP system records the tid accompanying a request before delivering the request. If the SAP system receives the request again with the same tid it will not deliver the request. Thus if a route encounters a communication error when sending a request through an endpoint of this component, it can retry sending the request within the same exchange knowing it will be delivered and executed only once.

sap-qrfc-destination

Queued Remote Function Call Destination Camel component. This component extends the capabilities of the Transactional Remote Function Call Destination camel component by adding in order delivery guarantees to the delivery of requests through its endpoints. This endpoint should be used in cases where a series of requests depend on each other and must be delivered to the receiving SAP system at most once and in order. 

sap-srfc-server

Synchronous Remote Function Call Server Camel component. This component and its endpoints should be used in cases where a Camel route is required to synchronously handle requests from and responses to an SAP system.

sap-trfc-server

JBoss Fuse SAP Transactional Remote Function Call Server Camel component. This endpoint should be used in cases where the sending SAP system requires at most once delivery of its requests to a Camel route. To accomplish this, the sending SAP system generates a transaction ID, tid, which accompanies every request it sends to the component's endpoints. 

The sending SAP system will first check with the component whether a given tid has been received by it before sending a series of requests associated with the tid. The component will check the list of received tids it maintains, record the sent tid if it is not in that list, and then respond to the sending SAP system, indicating whether or not the tid has already been recorded. The sending SAP system will only then send the series of requests, if the tid has not been previously recorded. This enables a sending SAP system to reliably send a series of requests once to a camel route.

sap-idoc-destination

IDoc Destination Camel component. This endpoint should be used in cases where a Camel route is required to send a list of Intermediate Documents (IDocs) to an SAP system.

sap-idoclist-destination

IDoc List Destination Camel component. This endpoint should be used in cases where a Camel route is required to send a list of Intermediate documents (IDocs) list to an SAP system.

sap-qidoc-destination

Queued IDoc Destination Camel component. This component and its endpoints should be used in cases where a Camel route is required to send a list of Intermediate documents (IDocs) to an SAP system in order.

sap-qidoclist-destination

Queued IDoc List Destination Camel component. This component and its endpoints should be used in cases where a camel route is required to send a list of Intermediate documents (IDocs) list to an SAP system in order.

sap-idoclist-server

IDoc List Server Camel component. This endpoint should be used in cases where a sending SAP system requires delivery of Intermediate Document lists to a Camel route. This component uses the tRFC protocol to communicate with SAP. 

OData components

Red Hat Fuse has support for OData v2 and OData v4 endpoints via the following components:

camel-netweaver

With support for OData v2, this connector is for read-only OData connectivity to SAP systems. It is a lightweight implementation.

camel-olingo2

Also supporting OData v2 SAP endpoints, this connector uses the Olingo Java library for OData. It supports CRUD use cases and can be used for any OData v2 SAP endpoint such as SAP NetWeaver Gateway, and SuccessFactors.

camel-olingo4

This component, also built on Olingo, supports OData v4 endpoints. These endpoints can be from SAP NetWeaver Gateway, SAP S4/HANA or any OData v4 compliant endpoint.

SOAP/WSDL Integration with SAP

SAP also enables data integration for SOAP Web Services via WSDL endpoints. Red Hat Fuse has support for SOAP 1.1 and 1.2. There is additional support for mapping WSDL to REST Domain Specific Language (DSL) as well.

API Management

Red Hat 3scale is a full life-cycle API management platform that can manage SAP APIs created in Red Hat Fuse, SAP Business Hub or SAP Business One using the OpenAPI specification.

Use Cases

ABAP as as Service

Using the tools and components, you are able to create a CRUD REST API to connect to your BAPIs and RFCs in SAP ECC or SAP S4/HANA. Once created, you can manage your new SAP APIs in Red Hat 3scale API Management (part of Red Hat Integration) to allow for monitoring, metering, security, throttling, publishing in a developer portal.

Integration with SAP and non-SAP Systems

With Red Hat Fuse, developers can connect to SAP or non-SAP sources and create data process flows that can act upon data from one data source and perform operations on another. For example, imagine adding an employee in SuccessFactors and automatically creating a ticket in ServiceNow for new employee training or tasks for IT like setting up their computer or network connection. Red Hat Fuse integrates with other CRMs like Salesforce as well and can create combined APIs consuming data from SAP and other CRMs. Red Hat Fuse components allow for connectivity to any SAP data source and over 200 other data sources.

Serverless SAP

Serverless is a development pattern that allows coders to focus on code and not concern themselves with infrastructure. Red Hat enables serverless capabilities for SAP via Camel K and AMQ Streams eventing. You can stream events from SAP to serverless functions using our SAP certified solutions.

Centralize and Monetize APIs

Data is a commodity. It’s expensive to get and it can be expensive to make sense of. APIs provide a way to collect, combine and serve data to any number of consumers. Red Hat 3scale makes it easy to not only manage APIs from SAP and non-SAP sources, including publishing them for consumption in a customizable developer portal, but allows you to monetize access to your APIs whether they are consumed internally or externally. For example, you can enable partners to sign up and consume your APIs and either profit or recoup costs with integration with major payment gateways such as Braintree and Stripe. 

Conclusion

SAP recommends keeping the SAP Digital Core clean in order to reduce costs and time in upgrades and migrations. Red Hat Integration is a key component to enable you to extend SAP systems and adopt modern application development practices to allow you the agility to speed up your go to market strategy and encourage innovation. You can learn more from our Red Hat Solutions for SAP Datasheet


About the authors

David Codelli is a Product Marketing Manager at Red Hat Software. A 25-year veteran of business integration, Codelli worked on complex systems and applications in health care, financial services, aerospace, and manufacturing before assuming leadership roles in product management and marketing. He has worked with many leading edge companies including Sun Microsystems, Verizon, McKesson, and General Atomics. He has a deep understanding of information security and governance, enterprise integration, distributed systems, and cloud platforms. He holds a bachelor's degree in Information and Computer Science from Georgia Tech.

Read full bio

Ted Jones is the SAP Architect at Red Hat. He is responsible for creating new solutions across the Red Hat Portfolio for SAP and enabling customers and partners. During his more than 20-year career as a software engineer, his focus has been on data and application integration with SAP and other sources, structured and unstructured. Ted is passionate about technology and finding new, simplified ways to achieve customer goals. Ted Jones is the SAP Architect at Red Hat. He is responsible for creating new solutions across the Red Hat Portfolio for SAP and enabling customers and partners. During his more than 20-year career as a software engineer, his focus has been on data and application integration with SAP and other sources, structured and unstructured. Jones is passionate about technology and finding new, simplified ways to achieve customer goals.

Read full bio