Integrate Mule ESB with SAP

As one of the most widely used enterprise resource planning solutions on the market, SAP plays a central role in the most critical business processes for many companies. In order to fully automate and optimize these business processes, companies need to integrate SAP with other applications within their organization. This article discusses SAP integration with other applications like Salesforce, e-POS, e-Commerce SharePoint etc. including uses and benefits, challenges, and new approaches.

Mule ESB - The Best Way to Integrate SAP

An alternative approach to point-to-point quick fixes and expensive SOA stacks is integrate SAP using an (Enterprise Service Bus). ESBs provide a modern and lightweight, standalone solution for integrating SAP with other applications, including SaaS solutions like Salesforce, ePOS, e-Commerce, SharePoint etc. Mule ESB is the only enterprise service bus to be certified by SAP for SAP integration. Mule’s SAP Enterprise Connector provides bidirectional communication and works with existing SAP technologies such as:

• Intermediate Documents (IDocs)
• Business Application Programming Interfaces (BAPIs)
• SAP Java Connector (JCo)

Coforge had proposed and designed the Service Oriented Architecture (SOA) for developing interface services that would enable different functionalities as reusable services. Coforge integrated SAP with other applications using a low cost Enterprise Service Bus (ESB) to address all the business drivers.Read more through our Case Studies

Mule ESB SAP Connector

Mule ESB supports SAP integration through an SAP-certified Java connector. With the Mule Enterprise Gateway for SAP, integration between applications with SAP ECC is faster and easier. Mule SAP JCo Connector is a transport developed to provide bi-directional connectivity between SAP and other applications or tools. Using SAP JCo connector we can easily invoke BAPIs (Business Application Programming Interface) and iDocs (Intermediate Document Interface) in SAP. The SAP JCo connector is built using SAP Java Connector libraries provided by SAP. The connector leverages the SAP Java Connector (JCo) libraries, which enable Mule applications to:

• Send and receive iDocs over tRFC and qRFC
• Transform all SAP objects (JCoFunction & IDocs) both to and from XML
• Execute Business Application Programming Interface (BAPI) functions using all of the following types of Remote Function Calls (RFC) like sRFC (synchronous RFC), tRFC (transactional RFC) and qRFC (queued RFC)
• Act as a JCo Server to be called as a BAPI over the following protocols like sRFC, tRFC, qRFC

The SAP connector establishes connection to SAP system using JCO libraries (provided by SAP). The Connector supports the option to configure SAP connection details, connection pooling and max limit of active connections. If the connector is used for outbound data from SAP, then ESB registers the current Mule ESB instance as JCO destination/Gateway Server.

Integration for SAP BAPI functions

A simple BAPI performs a single operation, such as retrieving a list of Product master data. The adapter supports simple BAPI calls by representing each with a single business object schema. Simple BAPIs can be used for outbound or inbound processing. You can specify synchronous RFC processing or asynchronous transactional RFC (tRFC) processing when you configure a module for a simple BAPI. In addition, for outbound processing, you can specify asynchronous queued RFC (qRFC) processing, in which BAPIs are delivered to a predefined queue on the SAP server.

• In synchronous RFC processing, the SAP server and the adapter must be available during processing.
• In outbound processing, the message flow sends a request, then waits for a response from the SAP server.
• In inbound processing, the SAP server sends a request through the adapter to an endpoint and waits for a response from the adapter.
• In asynchronous tRFC outbound processing, the adapter associates a transaction ID with the function call to the SAP server. The adapter does not wait for a response from the SAP server. If the delivery is unsuccessful, the message flow can use the SAP transaction ID (TID) to make the request again. The TID is a field in your message.
• In asynchronous tRFC inbound processing, the adapter does not have to be available when the SAP server runs the function call. The function call is placed on a list of functions to be invoked, and the call is attempted until it is successful. To send function calls from a user-defined outbound queue on the SAP server, you also specify asynchronous tRFC inbound processing.
• In asynchronous qRFC outbound processing, the process is similar to asynchronous tRFC outbound processing. A TID is associated with the function call, and the adapter does not wait for a response from the SAP server. In addition, the BAPIs are delivered to a predefined queue on the SAP server. By sending BAPIs to the predefined queue, you can ensure the order in which they are delivered.
  
  

Integration for SAP IDocs documents

The IDoc adapter is part of the Integration Server. Essentially, the IDoc adapter comprises two parts, namely an adapter at the Integration Server inbound channel, and an adapter at the Integration Server outbound channel. The metadata for the IDoc types involved is shared. The adapter at the inbound channel is located before the Integration Server pipeline and calls this pipeline. The adapter at the outbound channel, however, is called by the pipeline, and can therefore be regarded as part of the pipeline. As part of ESB flow definition, a SAP inbound endpoint was used to receive iDocs from SAP. A new destination (Program ID) was created in SAP, the iDocs created in SAP were also published to the new destination. There are two processes in IDOC processing one is INBOUND PROCESS (IDOC coming to the system and its handling at various stages) and the other is OUTBOUND PROCESS (IDOC is send to other system. Outbound data from SAP, in case of Price/VAT data from SAP, ESB receives iDocs as JCO iDocDocumentList elements. Each iDocDocument contains iDoc metadata and Segments which internally had the Segment data (Price or VAT information). ESB can receive multiple iDocs at any time.  Inbound data to SAP, in case of Sales/Return Order from other application to SAP, Mule ESB converted payload to iDoc XML format using XML-to-iDoc transformer and posted the request to SAP.

Support for Clustering, HA, Reliability and Throttling

Mule ESB Enterprise can be clustered to support High Availability. The SAP adaptors are cluster aware. The TID handler should be configured to use database in case of Clustered ESB nodes to ensure that ESB does not process same transaction twice. Reliability and Throttling was enabled by using Active MQ message broker using Mule ESB which provided an out of the box connector. Throttling was controlled through configurations such that Mule ESB processes load to downstream system like POS, based on a response acknowledgement.

Batch process and Tuning

It is possible for Mule ESB to handle higher volume of data from SAP to support batch process. ESB received data from SAP and output to destination interfaces were throttled using Active MQ. ESB also provides options to tune the number of threads for processing.

High level architecture to Integrate SAP using Mule Enterprises ESB

Benefits to the customer

When SAP is properly integrated with other applications, companies are able to streamline and fully automate their business processes. Companies further benefit from SAP integration in the following ways:

• Increased Business Alignment: The ability to create an integrated agile software infrastructure for changing business needs
• Better Business Efficiency: The ability to streamline, automate, and enable a better tracking and visibility to business processes
• Improved Business Visibility: Ability to integrate systems and to aggregate data for a consistent and accurate view of business as a whole
• Significant cost savings by using low cost Mule ESB Enterprise
• Support for functional and non-functional requirements
• Ability to generate reports in SAP based on regions and evaluate the sale across the world
• Improved customer interactions by automating direct communications
• Elimination of the need for dual data entry, saving time and money
• Fewer data redundancies and errors caused by manual data entry
• Enhanced agility to act on new information quickly

SAP Integration Challenges

Although integration has been around for well over a decade, the specific challenge of integrating SAP with other system emerged much more recently. Moreover, traditional approaches to integration have been costly and complex. Direct, point-to-point integration, for instance, has been utilized in some cases as a quick, ad hoc solution to SAP integration challenges. However, such an approach creates tight dependencies between the two systems, resulting in a brittle environment and a progressively more complex architecture as new integration are added over time.

Author: Mr. Sanjeet Pandey is a Masters of Computer Application (MCA) graduate having 4+ years of experience as a Technical Specialist with Coforge. He has varied experience in ESB’s like Mule, JCaps.  Sanjeet loves dreaming up new ideas, movies & music, photography & travelling and Developing web projects. To know more about Sanjeet log on to www.sanjeetpandey.com

If you would like to find out more about how APIs could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com

Other useful links:

Integration with Facebook using Mule ESB

Integration with Twitter using Mule ESB

Integration with LinkedIn using Mule ESB