Introduction and 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 an 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.
Methods of Communicating with SAP
Jitterbit can communicate with your SAP R/3 system using any of these methods:
- Remote Function Calls (RFCs)
- Intermediary Documents (IDocs)
- Business Application Programming Interface (BAPIs)
- Web Services
SAP communicates between its various modules by making use of Function Modules. Function Modules are programs/functions defined within an 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 these 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 these 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 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.
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.
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.
SAP ports all begin with 31, 32, or 33 followed by the two digit system number. The default is 3300. The SAP gateway generally begins with 33 followed by the gateway number. If the gateway is 17, the gateway port is 3317. The Jitterbit SAP Event Listener also requires the gateway port to be added to the services file.
The SAP gateway generally begins with 33 followed by the gateway number. If the gateway is 17, the gateway port is 3317. The Jitterbit SAP Event Listener also requires the gateway port to be added to the services file.
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 Harmony Design Studio in an SAP Connector Endpoint.
Configuring Outbound Communications from SAP
Outbound communications from SAP require the separate Jitterbit SAP Event Listener module. See SAP Event Listener Configuration for details on accessing the installation file and additional system requirements.
To establish communication between SAP and the Jitterbit SAP Event Listener, 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 an RFC Destination
Jitterbit registers at the SAP Gateway system using an RFC Destination. The external application then runs in a server mode, waiting for messages from the SAP system. The parameters required while creating an 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 an 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.
WARNING: DO NOT use the Test Connection button on this screen until all the steps in SAP Event Listener Configuration are completed. The Event Details must be entered and saved in the SAP Event Listener and the SAP Event Listener service must be restarted prior to testing the RFC Destination . Testing the RFC Destination in SAP prior to saving the Event Details in the Event Listener will result in an error due to a missing profile name. Once the steps outlined in SAP Event Listener Configuration are completed, return to this screen and click the Test Connection button to verify connectivity between Jitterbit and the SAP Gateway.
Figure A: RFC Destinations
Figure B: Jitterbit RFC Destination
Creating a Transactional RFC (tRFC) Port
This is the logical port, used by an RFC destination for exchanging information with Jitterbit. In order for Jitterbit to be able to communicate with the SAP Server, create a port on the SAP system and link it to the RFC Destination just created. You can create different types of ports. Some of the common types are – Transactional RFC, File, CPI-C, ABAP-PI, XML File, and XML HTTP. Jitterbit uses the Transactional RFC port.
NOTE: The Transactional RFC (tRFC) port is used for both tRFC and qRFC function calls.
Steps for Creating a tRFC 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 displays 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
Figure E: Outbound Parameters
Figure F: Inbound Parameters
Last updated: Sep 23, 2020