SAP is a tremendous application which can transform the way an organization does business. It is highly configurable and can support many processes and their variations out of the box. However, it still cannot do everything. SAP integration with other systems is often needed. This is so because SAP forms the core of the enterprise and has data which other applications would need to work.
Also, apart from organization’s core master and transaction data it also has various checks and business rules defined. There is no point re-building the same in other application. Instead integrating third party applications with SAP keeps the functionality in a single place so that if the rules are updated, it will reflect in the entire landscape.
In this article, we will focus on how to achieve SAP system integration and have information can flow between the various applications within the IT landscape of the company. We will also look at SAP integration methods and associated best practices.
Understanding which SAP version you need to integrate with
Many a times, people get confused due to so many SAP terminologies and versions. So, before we start, it may be good to know which SAP version we are talking about. Though the below list is not complete, usually, you would end up with either of the below version.
SAP Business One – This is SAP’s ERP offering for small and mid-segment market. It is a .NET based application which caters to Operation and Financial needs of the company. It has built-in functionality for reporting and compliance. Usually SAP Business One runs on MS SQL database.
SAP Business One on HANA – The new installation of SAP Business One run on HANA. This helps speed up the application.
SAP ECC – Most of the companies running on SAP are running on SAP ECC. It is the offering for a large enterprise. Companies with large volume, complex business processes and operating in multiple geographies go for SAP ECC. It is built on ABAP stack.
SAP All in One – These are same as SAP ECC but are configured to work for a specific industry vertical (for example a manufacturing or a pharma company). Since they are pre-configured, it helps the company save implementation cost.
SAP ECC on HANA – Similar to SAP Business One on HANA, ECC on HANA simply means an ECC installation which is running on HANA database.
SAP S/4 HANA – This is the latest release of SAP ERP and it can run only on HANA database. With this release, SAP has simplified their core database architecture. This together with in-memory processing enables business to do complex business computation within minutes.
Apart from the versions listed above, SAP also has industry solutions for various industry verticals. For example, industry solution retail (IS-Retail) caters to various needs of a typical retail company including merchandising , assortments and listing.
SAP integration methods
It is important to understand that SAP has predefined ways in which it can exchange information. One or more of these may be suitable for your needs. However, careful assessment must be done on which of the method would work the best. You may be able to get relevant help from SAP integration best practices section of this article as well.
SAP Business One integration option – For integrating SAP Business One, DI services are required which expose the Business One objects. In case SAP Business one installation is on HANA, then HANA service layer is needed. Having this layer makes the underlying objects in SAP B1 accessible for integration.
All the options listed below are for other SAP versions (SAP ECC / S/4 HANA).
File exchange – If you are dealing with older applications (example mainframes) in the landscape, most likely you would be limited in integration options. File exchange and processing becomes the only possible way to integration. In this method, a file is generated the source system and kept in a specific directory. A middleware (example SAP Process Integration or SAP PI) then picks up the file and processes it if required and posts it to the destination folder where the destination application can pick it up and process the same. SAP can support generation of file as well as processing of an inbound file.
SAP integration via IDOCs – IDOCs or intermediary documents are another way to exchange information to and from SAP. If you are more aware of web technologies, consider IDOCs as XML. It consists of neatly defined data segments with parent and child nodes. There are specific steps to configure inbound and outbound IDOCs and we will cover it in subsequent article.
SAP integration via RFCs – If you are looking at a real time SAP system integration scenario, RFC is probably the best way to go. In this case, certain functions are enabled for remote call. One such function could be for example sales order creation. Third party applications can integrate with SAP using these RFCs for a real time communication and business process validation (example price computation, minimum order check etc.).
SAP integration with other systems – additional information
Having understood the ways SAP can connect and interact with your application, this little more information which can help, especially if your application is PHP, JAVA or .NET based. The RFCs in SAP can also be exposed as webservices (given the client has something called a Netweaver stack or SAP PI) which you can consume using a SOAP call.
Moreover, for Java and .NET applications, SAP provides libraries called JCO and NCO respectively. These help you to authenticate and call any RFC within the application. These libraries are available to SAP customers from their customer portal.
SAP Integration best practices
Great! So now that we are much more informed our SAP integration, let us look at things to keep in mind while connecting SAP with your desired platform. If you keep the following points in mind, you will end up having a robust solution.
a. Understanding which connection protocol
Each integration approach has some benefits and limitations. File exchange work best where the other application doesn’t support any other sophisticated communication protocol. With additional security measures, it is also useful for exchanges with government and banking systems. Usually file exchanges can be done as a background job in non-business hours so that it doesn’t affect end users working live on the application.
IDOCs are useful when we need to communicate with a business partner who accepts / sends information as per industry standards (example EDIFACT / ANSI). They could be used for transaction processing (example Orders, Invoice etc) as well as exchange of master data.
RFCs are useful when immediate response from SAP is required. This could be related validations or creation of transactions within the application. Though real-time, this can add up to system load if many parallel RFCs calls are lined up in the application.
b. Knowing which IDOCS / RFCs to call
SAP has many predefined IDOCs and RFCs which can be used out of the box. If you are not aware of them, it is best to engage an SAP Integration expert to help out. It is usually not recommended to create custom objects without understanding SAP’s default solution and making sure that custom development actually add value.
c. Indirect user policy
If you are connecting SAP with third party application, your end customer may be liable to pay SAP for in-direct use. It would be good to advise the customer to check their commercial agreements and check with their SAP partner to validate how they are going to be charged.
d. SAP RFCs need Commit
If your architecture consists of using RFCs for connecting the applications, you may want to check whether additional database commit function is required. This is required, since many standard BAPIs need to be explicitly committed to database before you can see the actual transaction.
About us and what we do
We are passionate about seamlessly connecting SAP with other applications in your landscape. Our consultants are not only expert in SAP integration, but can also enable you to write an SAP adapter for your application and help your application talk to a SAP system.