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
Much of this content has been stolen from http://www.amazon.ca/Microsoft-BizTalk-2010-Business-Integration/dp/1849681902/ref=sr_1_4?ie=UTF8&qid=1453769997&sr=8-4&keywords=Biztalk+2010 pages 193 and 194
Yes @wearsy, your book helped me a lot in my last project and I created notes out of it and put it in my web log. I have also mention your book as the resource for the post. I hope you would also write about the upcoming new WCF- SAP adapter in BizTalk Server 2016.
Great article.. Any tips on how to test the IDOC schema against native IDOC… I am having trouble with it.. it keeps giving me stream error when trying to validate instance using VSrudio..
Can you please email me the error at gautambiztalkblog@gmail.com?