SAP Integration Using BAPI

SAP R/3 exposes a large number of BAPI method calls and RFCs that can be used for application integration. The BAPI Explorer included as part of the SAPgui Windows client allows a user to browse the Business Object Repository and locate appropriate business objects, the BAPI methods supported by the object, and details on the parameters and return values of a specific BAPI method. Since business objects represent the actual components used as part of the SAP system for communication between modules, this approach has the potential to provide broad support for application integration with SAP.

In our scenario, the application connector to the SAP system receives information from the Web middleware tier destined for the SAP system (see the following figure). Requests can be sent from the Web tier at any time. So the SAP application connector layer needs to provide a receive function that is running all the time. Consequently, the receive function of this application connector needs to be written as a Windows NT service that can be automatically started when the computer starts operation. Other components of the application connector layer can be integrated with this receive function service or can be separate applications that are started by the receive function when needed. This is a design decision to be made by system architects and application developers based on the particulars of a solution.

The communication between the Web middleware layer and the SAP application connector needs to provide loose coupling. Some form of messaging is a natural choice for this communication. Although it would be possible to develop a custom message service for use in this scenario, we chose to demonstrate how to integrate existing features and facilities.

The Microsoft Message Queue (MSMQ) service is included as part of Windows 2000 Server and provides a general-purpose asynchronous message service with guaranteed delivery. Applications would send messages to a queue defined in the MSMQ service on a local or remote server. These messages would be placed in the outgoing queue of the local server for delivery to the remote server. Other applications or processes can retrieve messages from these MSMQ queues at a later time. A message has no specific format to MSMQ and is considered a blob of bytes. So, a message can take any form that the developer chooses up to the size limit of a single message (4 megabytes). The only caveat is that both sender and receiver must understand the message format to be used in order to properly interpret the message. MSMQ messages can be encrypted simply by setting a property on a message. The MSMQ can also authentication of the message sender and receiver.

The application connector receive function can be developed as a Windows NT service that queries the appropriate MSMQ queue at some regular interval. If a message is found in the queue, the service can retrieve the MSMQ message from the Web middleware layer, parse the message appropriate for the parameters needed, and make the appropriate calls into the SAP system using BAPI methods and RFCs. These secondary functions could be packaged in a COM or COM++ DLL component or as an application that the service invokes with some specific parameters.

The Object Builder included with the SAP R/3 DCOM Connector can be used to create COM proxy objects for accessing BAPI methods and remote function calls in SAP. The Object Builder tool included with the SAP DCOM Connector can be used to browse the Business Object Repository and select BAPI methods and RFCs to be included in a COM object that will be created. Once the BAPI methods are selected, the Object Builder generates the necessary source code for the COM components and builds the COM proxy using Visual C++. In the scenario discussed in this chapter, it would make sense for simplicity to encapsulate all of the BAPI methods and RFC function module calls to be used into a single COM or COM+ component for accessing the SAP system. Since these calls will need to be handled as part of a distributed transaction, programming is likely to be easier with only a single DLL to deal with for the SAP integration code. This COM proxy should also contain appropriate code to establish a SAP logon session, since this session connection is required to issue BAPI method calls or RFCs. Bundling all of the SAP BAPI and RFC integration code in a single DLL should make it simpler to share a single SAP logon session than if a number of separate COM objects were generated using the SAP R/3 Object Builder.

When creating COM components using the Object Builder, three types of remote function calls to the SAP System are supported:

Synchronous RFC - the application makes the function call to the R/3 system and waits for the call to complete. Some RFC function modules contain implicit or explicit commits, while others require the user to call the CommitWork method. This is dependent on the BAPI or RFC method, so the documentation should be checked.
Transactional RFC - the same as a synchronous RFC but this type guarantees that each function issued is only executed once.
Queued RFC - similar to the transactional RFC, but guarantees the order in which function calls will be processed in the SAP system.

Essentially all three of these RFC types still result in a synchronous remote procedure call to the SAP system, but the RFC type determines how the method call will be handled and processed once received by SAP.

In our scenario, the call into the SAP system must be part of a distributed transaction coordinated with the removal of an MSMQ message from an MSMQ queue. The MSMQ message should only be removed from the message queue if the BAPI and RFC method calls to the SAP system completed successfully. Otherwise, the MSMQ message should be left in the queue, and the process attempted again (roll back the transaction).

There may be cases where the queued RFC is needed if BAPI and RFC method calls are required in a specific order, but in our scenario this does not appear necessary. As a result, synchronous RFC is probably a reasonable choice.

Using the SAP Business Object Repository and exposed BAPI methods and RFCs can provide the broadest support for application integration with SAP. The scenario assumes a loose coupling of the Web middleware layer with the components used to make the appropriate BAPI method calls to the SAP System. This loose coupling is handled using MSMQ messaging. Loose coupling allows the benefits Web site to function properly even if the SAP system is off-line or network outages occur.

Previous Next