How the BAPI Module works

The BAPI Module implements the init(), terminate(), pollForEvents(), and doVerbFor() methods. However, the pollForEvents() method is not used because the BAPI Module supports request operations only.

Initialization and Termination

The init() method opens an RFC connection with the SAP R/3 application through the SAP Gateway. If the connector fails to initialize, it terminates using the terminate() method. The connector terminates by disconnecting the connection to the SAP Gateway.

Business object processing

A single implementation of the doVerbFor() method in the vision connector framework's business object handler initiates all business object requests. The vision business object handler processes all of the business objects passed between the BAPI Module and the integration broker. In the BAPI Module, a BAPI-specific business object handler supports only one BAPI; therefore, for each supported BAPI in the SAP R/3 application, you must have an associated BAPI-specific business object handler.

The vision business object handler uses the verb application-specific information of a business object to invoke the appropriate BAPI-specific business object handler. The BAPI parameter names and formats are hard-coded in the BAPI-specific business object handler so that the business object handler can make an RFC call to the appropriate BAPI.

Figure 22 illustrates business object processing for the BAPI Module.

Figure 22. Business object processing for the BAPI Module


Once invoked by the vision business object handler, the BAPI-specific business object handler executes in the following manner:

  1. Receives the WebSphere business object for SAP from the vision business object handler.
  2. Populates the BAPI parameters with business object data.
  3. Executes a BAPI call using RFC and passes the BAPI parameters to the SAP R/3 application. The business object handler waits for the business object data to be returned.
  4. Receives the business object data (BAPI parameters).
  5. Converts the BAPI parameters back to WebSphere business object data.
  6. Passes the business object to the Vision business object handler and ultimately to the integration broker.

Note:
If a BAPI Module has a Return Structure or Return Table, the connector checks for the message types A (abort) and E (error) to determine if the service call request processed successfully. A message type A or E indicates that the service call request failed to process. If a BAPI does not have a Return Structure or Return Table, you must implement your own error handling. The error message or messages, within the structure or table, are returned in the return status descriptor.

Supporting BAPIs

The business object generation utility, SAPODA, generates business object definitions that support BAPIs. SAPODA interprets the interface of a BAPI, maps its parameters to the business object attributes, and adds the application-specific information for each attribute.

Also, for each WebSphere business object definition, you must generate an associated BAPI-specific business object handler using SAPODA. For more information on Developing business objects and BAPI-specific business object handlers, see "Developing business objects for the BAPI Module".

Note:
Some BAPIs do not have single field parameters that correspond to simple attributes in the WebSphere business object. The connector requires every top-level business object to have a simple attribute that serves as the key attribute. Therefore, when generating a business object and business object handler from a BAPI without a single field parameter, SAPODA creates a key attribute named Dummy_key in the top-level business object, marks it as the key attribute, and adds dummy_key as the application-specific information of this attribute. Dummy_key provides the connector with a key attribute so that it can process the business object. However, the connector ignores the value of the Dummy_key attribute when modifying application data.

Copyright IBM Corp. 2003, 2004