The ALE Module is written in Java and extends the vision connector framework. The module consists of:
The ALE Module uses the RFC Server connector component because the similarities for event processing both support RFC calls directly from the SAP application.
SAP delivers the RFC libraries in Java and C. The connector is delivered and run as a Java archive (JAR) file.
Figure 50 illustrates the architecture of the ALE Module.
Figure 50. ALE Module architecture
When processing events from SAP, the connector uses the components illustrated in Figure 50 in the following ways:
An event is the execution of an ABAP function that transfers data to the listener. The event data sent by SAP may represent one or more such heterogeneous executions.
Each event from SAP is considered a transaction. The connector uses a two-step process with a Transaction ID (TID) to handle each event, guaranteeing once-only delivery of data from SAP to the connector.
For more efficient processing performance, the connector breaks up a large IDoc into smaller parts, each of which is a JMS-MQ message that translates into a smaller business object. Each of these messages contains a MultiPartMessage property, that identifies it with the appropriate part of the larger message. For example, assuming the original larger IDoc is partitioned into 8 JMS-MQ messages, then the value of the MultiPartMessage property of each part is 1 of 8, 2 of 8, and so on for each message. To associate all the message parts with one another, the connector sets the CorrelationID header property of each message part other than the first message to the value of the JMSMessageID property of the first part. In turn, the CorrelationID property of the first part is always set to the value of that property in the first JMS-MQ message that corresponds to the original large IDoc. For details about JMS-MQ message properties, see Table 20.
When processing requests from the integration broker, the connector uses the components illustrated in Figure 50 in the following ways:
Listener threads handle all of the ALE-specific RFC calls between the ALE Module and the SAP application. When the connector starts up, the init() method of the RFC Server Module creates a main thread that spawns a configurable number of listener threads. Each listener thread opens a handle to the SAP Gateway.
The listener threads do the following:
A thread listens continuously in a synchronous manner for events from the ALE-specific functions that it supports.
SAP uses a transaction and its corresponding ID to frame an event, guaranteeing that each piece of data is delivered once and only once from SAP. SAP sends a Transaction ID (TID) with the event data. To manage the TIDs centrally for event and request processing, the connector stores each TID as a JMS-MQ message on an MQSeries queue. When processing events, it also stores the associated IDoc data as the message body. The connector stores the TID, TID status, and the IDoc's processing status in the message header.
Two ALE-specific business object handlers are provided, one for event processing and one for request processing.
A listener thread instantiates the event-processing business object handler, which does the following:
The vision connector framework instantiates the ALE request-processing business object handler, which checks for a value in the TransactionId attribute in the WebSphere business object for SAP. If this value exists, it continues with the following steps.
A WebSphere business object for SAP represents each IDoc as a parent wrapper business object that contains two child business objects: a control record business object and a data record business object. The control record business object contains the metadata required by the connector to process the business object. The data record business object contains the actual business object data to be processed by the SAP application, and the metadata required for the connector to convert it to an IDoc structure for the RFC call.
The connector includes a business object definition for the control record. The definition file, SAP_idoccontrol.xsd, is located in the \repository\SAP directory.
The TABNAM attribute in the control record business object indicates which SAP function module the parent wrapper business object calls:
In addition, the following attributes must have values for SAP to properly process the object in ALE. These values are based on your ALE configuration:
The DOCNUM attribute in both business objects establishes the relationship between the data record business object and the control record business object.
When processing service call requests, the ALE Module can handle multiple IDocs in a single business object. Before it can do so, however, you must add another multiple-IDoc wrapper business object around two or more parent wrapper business objects. This top-level multiple IDoc wrapper business object contains an attribute that represents an array of parent wrapper business objects. For more information, see Parent wrapper business object.
The adapter includes a business object generation tool, SAPODA. This tool uses an IDoc definition text file to generate business object definitions for the ALE Module. For more information on developing business objects for the ALE Module, see Developing business objects for the ALE Module and Generating business object definitions using SAPODA.