How the RFC Server Module works

The RFC Server Module implements the init(), terminate(), pollForEvents(), and process() methods.

This section describes:

Initialization and termination

The init() method creates a main thread that spawns a configurable number of listener threads which open a handle to 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.

During the initialization process, the RFC Server Module registers with the SAP Gateway using a specified Program ID. This Program ID must be set using the RfcProgramID connector configuration property and set up as a TCP/IP port in the SAP application. For more information on setting up a TCP/IP port, see "Registering the RFC Server Module with the SAP gateway".

Business object processing

All processing of WebSphere business objects for the RFC Server Module is initiated by an RFC-enabled function in an SAP application. In the RFC Server Module, an RFC Server-specific business object handler supports only one RFC-enabled function; therefore, for each supported function in the SAP application, you must have an associated RFC Server-specific business object handler. In addition, you must have an associated business object for each RFC Server-specific business object handler.

Figure 26 illustrates business object processing for the RFC Server Module.

Figure 26. Business object processing


Business object processing for the RFC Server Module executes in the following manner:

  1. A listener thread picks up a subscribed event from the SAP Gateway and matches the name of the corresponding RFC-enabled function with an RFC Server-specific business object handler.
  2. The listener thread instantiates the appropriate RFC Server-specific business object handler based on data from the RFC event on the SAP Gateway, and then creates an instance of the corresponding business object.
  3. The RFC Server-specific business object handler retrieves the RFC interface data from the SAP Gateway and populates the WebSphere business object for SAP.
  4. The RFC Server-specific business object handler passes the business object to the integration broker. In the RFC Server Module, since SAP makes the synchronization calls, when a WebSphere message broker is the integration broker, the RFC Server Module uses SynchronousRequestQueue and SynchronousResponseQueue to communicate with the WebSphere message broker.
  5. The business object handler receives the returned business object from the integration broker, converts it back to the RFC interface, and then returns it to the SAP Gateway.

The RFC Server Module uses the SAP Gateway to maintain the processing order of events and to maintain the status of events. Since the listener threads make synchronous calls, an event must return to the SAP Gateway before it can be considered successfully processed.

Note:
If an RFC-enabled module has a Return Structure or Return Table, the connector checks for the message types A (abort) and E (error) to determine if the event processed successfully. A message type A or E indicates that the event failed to process. If an RFC-enabled function module 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 RFC-enabled functions

The development environment IBM WebSphere Business Integration Adapter for mySAP.comincludes a utility, SAPODA, that generates business object definitions based on an RFC-enabled function. SAPODA interprets the interface of an RFC-enabled function, maps its interface parameters to the business object attributes, and adds the application-specific information for each attribute.

For each business object definition, you must generate an associated RFC Server-specific business object handler, which invokes the corresponding business object. For more information on developing business objects and RFC Server-specific business object handlers, see "Developing business objects for the RFC Server Module".

Note:
Some RFC-enabled functions 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 RFC-enabled function 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.

Triggering an event

To trigger an event for the RFC Server Module the RFC destination must be specified for the remote function call. The remote function call can be executed in two ways: programmatically and using transaction SE37. Programmatically, the variation of the CALL FUNCTION command that specifies a destination must be used. The value to specify for the destination is the one that is created to register the RFC Server Module. See section "Registering the RFC Server Module with the SAP gateway" for more information. Using transaction SE37, the RFC target system must match the RFC destination. See section "Registering the RFC Server Module with the SAP gateway" for more information on creating and registering a RFC destination for the RFC Server Module.

Copyright IBM Corp. 2003, 2004