Share this

Consuming IDOCs from SAP using BizTalk Server – Part 3

In the previous two post I discussed about the overview of SAP , how do we generate schema and configure ports in BizTalk to consume the IDOC. In this post I will discuss about the RFCs / BAPIs overview and setting need to be done on BizTalk server to consume them.

RFCs

RFC stands for Remote Function call and is the standard SAP interface when exchanging data across SAP systems or between non-SAP systems and SAP systems. RFC is a SAP protocol to handle communications, and is used to call functions in an SAP system by a caller external to SAP or to call programs external to SAP from an SAP system. It is the process of calling a function module which is residing in a different machine from the caller program. RFCs can be used to call a different program in the same machine as well, but usually it is used when 'calling' and 'called' function modules/ programs are running on separate machines. Functions can only be called via RFC, if they are tagged as RFC functions in the SAP development workbench.

BAPIs

BAPI stands for Business Application Programming Interfaces and are basically a RFC-enabled function module. It is a library of functions that are released to the public as an interface into an existing SAP system from an external system. So a BAPI function is a function module that can be called remotely using the RFC technology. A function module is a logical grouping of domain specific functions that belong together. For instance, we may have a Human Resources (HR) function module that will contain all available HR operations.  

RFCs/BAPI vs. IDOCs

BAPIs, RFCs and IDOCs are often confused. A question comes up regularly is when to use what?
  • BAPI is a business object.
  • An RFC is functional code.
  • IDOCs OR intermediate documents are standard data structures for electronic data interchange (EDI) between application programs.
IDOCs are used for asynchronous transactions: each IDOC generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. IDOC types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDOC type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands. Synchronous scenarios are better suited to leveraging RFCs/BAPIs due to their immediate request/response mechanisms. For example, take the situation where SAP is the system of record for customers within your organization, but you have chosen to use Dynamics CRM for a specific application. We do not want to manually key in customer information in both systems if we don't have to. So we can build an interface that will query SAP to retrieve the master data for an existing customer in our organization. In this situation, we would not want to use an IDOC, if we are expecting an immediate response, as BizTalk would send the IDOC in and then have to wait for a response from SAP asynchronously. When SAP does send the response back to BizTalk, we may have to correlate this response with the request that was sent into SAP so that BizTalk can provide a correct response to the calling application.  

Setting BizTalk server to use RFCs/BAPIs

Configure the saprfc.ini file
The first thing is to create a System Variable called RFC_INI.  We then need to provide a path and a filename.  For example I have used C:\SAPINI\saprfc.ini. Next we need to add the contents to our saprfc.ini file. The values that I needed to provide include: Now that we have our SAPRFC.ini file and if you have also created SAP Receive location then we can run a connected client test using SM59. Launch the SM59 transaction and then expand the TCP/IP Connections node. Scroll through the list to find your RFC Destination Click on the Connection Test button to execute the test. Connection test will fail if something is wrong in SAPRFC.ini file or receive location for receiving the IDOCs is not running. Once you have a proper SAPRFC.ini file and receive location for receiving the IDOCs is running, the test connection should pass. With connectivity issues out of the way, you can browse for your desired schemas using the BizTalk Consume Adapter Service Wizard and then add them to our BizTalk solution. Please refer the part1 and part2 for schema generation and port configuration in BizTalk. Resource: Microsoft BizTalk 2010: Line of Business Systems Integration http://www.integrationusergroup.com/hybrid-integration-with-sap/
Related links:
http://onlyabap.blogspot.com/2007/08/what-is-difference-between-bapiidoc-and.html http://kentweare.blogspot.com/2012/03/sap-calling-rfc-hosted-in-biztalk.html

Loved this? Spread the word


Gautam

Follow me here

About the Author

My name is Gyanendra Kumar Gautam. I am Solution Consultant, who basically works to hook the stuff together using Microsoft technologies like Azure PaaS, Azure Serverless Services, Microsoft BizTalk Server, and Azure DevOps Services.

You may also like

REST support in BizTalk Server

What is REST? Representational State Transfer (ReST) is a software architecture style consisting of guidelines and best practices for creating scalable web services. ReST has gained widespread acceptance across the Web as a simpler alternative to SOAP and WSDL-based Web services. REST makes use of existing and widely adopted technologies, specifically HTTP, and does not

Read More

Security Features in BizTalk Server

BizTalk Server enables companies to automate business processes, through the use of adapters which are tailored to communicate with different software systems used in an enterprise. In a common scenario, BizTalk enables companies to integrate and manage automated business processes by exchanging business documents such as purchase orders and invoices between disparate applications, within or

Read More

Never miss a good story!

 Subscribe to my blog to keep up with the latest news!