Communication between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system. The RFC connection is failing with Partner program fork failed, can you please let me know if i am missing anything in configuring this RFC connection. Thanks, Sanketh.
Introduction / Objective The intended audience for this document is Jitterbit platform customers that want to integrate with SAP R/3. This document describes Jitterbit’s capability and steps through how to configure SAP for communication with the Jitterbit platform. The Jitterbit platform can communicate with SAP in either a unidirectional or bidirectional manner. The Jitterbit platform can connect to different hosts (on a distributed SAP system) depending on the direction of communication. The user should configure the location of the SAP Application Server and the SAP Gateway server within Jitterbit through a SAP Endpoint. The SAP Application Server is used for all inbound transactions to SAP. The SAP Gateway server is used for all outbound communication from SAP.
This document does not cover specific Jitterbit configurations to connect with SAP. This will be covered in a separate document. Ways to Communicate with SAP Jitterbit can communicate with your SAP R/3 system using any of the following methods. Remote Function Calls (RFCs). Intermediary Documents (IDOCs).
Business Application Programming Interface (BAPIs). Web Services RFCs SAP communicates between its various modules by making use of Function Modules. Function Modules are programs/functions defined within a SAP system using the ABAP (Advanced Business Application Programming) language. Some of SAP’s function modules are remote callable. These can be used by an external application to invoke certain functionality within SAP.
These types of function modules that have the capability to be invoked externally are called RFCs (Remote Function Call). The Jitterbit SAP Event Listener supports both tRFC and qRFC protocols. Transactional RFCs, also known as tRFCs, have the following attributes:. The call is executed exactly once in the target system. The system checks if a TID (unique transaction identifier) has already been processed.
If it has, the function call is ignored. If the target system is not available when the call is made, the SAP Event Listener will continue to retry to process the transaction.
However, the Event Listener will continue to process other tRFC function calls. tRFC does not guarantee the order in which the function calls will be processed. Queued RFCs, are also known as qRFCs or qRFC with outbound queue, for which an outbound queue for qRFC was created in SAP R/3. QRFCs have the folowing attributes:. qRFC is used when function calls need to be processed in a specific order.
Each qRFC function call is placed in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed.
A function call is only transferred if it has no predecessors in the participating queue. After a qRFC function call is executed, the system attempts to start the next qRFC transaction in the sequence from the queue.
A queue name and a queue counter are required for each qRFC transaction for queue administration. Each qRFC call that is to be processed chronologically is assigned a queue name determined by the application. RFCs can further be classified as client RFCs and Server RFCs. An external program uses a client RFC to invoke functionality within SAP and exchanges data with SAP. A server RFC makes use of an external listener (servers – external programs) to transfer data from the SAP system. Server RFCs are invoked by the SAP system. IDOCs IDOCs are used by external applications to send data to the SAP system in a predefined positional file format.
There are various IDOC format types which are defined in the SAP system. They cater to different functionality in SAP.
The IDOCs that are published by SAP are called as standard IDOCs. SAP customers can also configure custom IDOC types in their instance of SAP. These types of IDOCs are called custom IDOCs. By convention the name of any custom object (IDOCs/BAPIs/RFCs) should begin with a Z or a Y. The IDOCs are simply a predefined message format. Specific Function modules are used to process IDOCs within the SAP system.
BAPIs As the SAP system evolved it was realized that the number of Function Modules and RFCs was becoming unmanageable. With the advent of Object programming languages, the RFCs morphed into BAPIs. BAPIs are just a wrapper around the RFCs, which presents the massive library of Function modules as Business Objects and their methods. BAPIs help in categorizing the Function Module functionality as business objects. In order for an external application to exchange data with the SAP system, certain configuration needs to be done on the SAP system. The next section details the necessary configuration.
Web Services You can communicate with the SAP system using web services as well. Typically these are done using the Enterprise Services in the ABAP Repositories. The TCODE is SE80. These are typically handled by an ABAP professional. This document will not discuss the details of how to define web services within SAP. Configuring Inbound Communication to SAP Sending data to SAP from Jitterbit requires no special configuration in SAP. You will simply need the SAP connection details – SAP Application server, SAP Client, SAP Username, SAP Password and Language.
You will configure these in the Jitterbit Studio in a SAP Endpoint. Configuring Outbound Communications from SAP To establish communication between SAP and Jitterbit, Jitterbit should be set up as a partner system in SAP. The process also involves creation of certain objects (e.g. RFC destination, ports, logical destinations,partner profiles etc.) on the SAP system. The steps required for setting up an external application as a partner system are:.
In some cases, you may need to specify the distribution model also. The RFC destination is a logical destination, bound to a port.
It also specifies other important parameters related to the destination like the GatewayHost, GatewayService, ProgramID. Creating a RFC Destination Jitterbit registers at the SAP Gateway system using a RFC Destination. The external application then runs in a server mode, waiting for messages from the SAP system. The parameters required while creating a RFC destination are:. RFC Destination name: A unique name identifier. Connection Type: Specifies the protocol used for communication.
Activation Type: Specifies the type of server. For receiving outbound communication this is selected as a Registered Server program. Steps for Creating a RFC Destination:. Log on to SAPGui. Enter TCODE SM59 in the TCODE input field and click the OK button.
It displays the screen as shown in Figure A. Select and expand the TCP/IP Connections node. Click on the Create Button on the toolbar, which displays the screen shown in Figure B. Enter the RFC Destination name and enter the Connection Type as T. Enter some description to document the RFC destination.
Click the OK button, which then displays the lower part of the configuration screen. Select the Activation Type as Registered Server Program. Specify a ProgramID, which will be used by the external server program when connecting to the SAP Gateway. Specify the Gateway Host and the Gateway Service fields. Press the Save button. NOTE: The RFC port is used for both tRFC and qRFC function calls.
Steps for Creating a Port:. Log on to SAPGui.
Enter TCODE WE21 in the TCODE input field and click the OK button. It displays the screen as shown in Figure C. Select and expand the Transactional RFC ports node. You can choose to either let the system auto-generate a port number for you or you can specify your own port number. The port number is a 10 character unique identifier.
Specify the version of IDOCs which will be exchanged via this port. Specify the RFC destination that you created in the last step.
Press the Save button. Figure C: Jitterbit Port.
Set Up a Partner Profile For Jitterbit to be able to receive information from the SAP system, create a partner profile on the SAP system that specifies the type of information that is exchanged with Jitterbit. This is used specifically for scenarios that involve IDOCs. The partner profile specifies the IDOC types that can be sent by Jitterbit to the SAP system (Inbound Parameters) and the IDOC types that are sent by the SAP system to Jitterbit. Steps for creating a Partner profile:.
Log on to the SAP System. Enter TCODE WE20 in the TCODE input field and click the OK button. It displays the screen as shown in Figure D. Select and expand the Partner type LS Logical System. Click on the New button.
Define the Partner Number and give some description for the Partner. Specify the Type as US Agent (specify the user which will be using the interface) and the Language (EN for English). Next, specify the IDOCs that will be sent to the partner system. Click on the Add button to add a row which brings up a screen as shown in Figure E. Enter the IDOC Message Type and the Receiver port. You can also specify the Pack Size and select queue processing if you want to collect IDOCs and send them in batches.
This is very scenario specific and normally you would select the Transfer IDOC immediately. Press the Save button and return to the previous screen. Similarly, specify the Inbound IDOC type.
On clicking the Add button, the screen is displayed as in Figure F. Specify the IDOC message type and specify the process code (the functional module) which would process the received IDOC. Add as many IDOCs to the Outbound parameters and the Inbound parameters as required. Click on the save button and exit out of the system.
Figure D: Partner Profiles.