When processing application events, the ALE Module acts as a server to the SAP application. In this capacity, the ALE Module receives events that the SAP application "pushes", or sends, to the connector. When processing requests, the ALE Module receives business object requests from the integration broker and sends them to the SAP application.
This section documents the following processes:
The init() method opens an RFC connection to the SAP R/3 application through the SAP Gateway. If the connector fails to initialize, it terminates the connection using the terminate() method. The connector terminates by disconnecting from the SAP Gateway.
When processing application events or business object requests, the connector's initialization process does the following:
For more information, see Configuring the ALE Module.
Because the connector supports multi-threading, when the ALE Module processes requests from the integration broker, it does not use the module's init() method to create a connection handle. Instead, it uses the vision connector framework's connection pool of such handles.
The ALE Module's processing of WebSphere business objects for SAP is initiated either through event processing or request processing.
This section describes:
Two RFC-enabled functions in an SAP application initiate all event processing for the ALE Module. The ALE's business object handler for event processing supports the functions idoc_inbound_asynchronous and inbound_idoc_process.
When processing events, this business object handler persistently stores the business objects in an MQSeries queue. The connector maintains the Transaction IDs (TIDs) associated with the RFC call to guarantee that each piece of data is delivered once and only once.
This section describes the following:
Figure 19 illustrates how the ALE Module processes the MQSeries queue.
Figure 19. Business object event processing
Business-object event processing for the ALE Module executes in the following manner:
Each JMS-MQ message represents a single RFC call. Each RFC call can represent one or more business objects associated with a single TID. The connector stores the TID in the message's CorrelationID property, sets the TidStatus to CREATED, and sets the IDocProcessStatus to unknown. The connector uses the message body to store IDoc data.
If the AleUpdateStatus configuration property evaluates to true, the connector updates the status of the IDoc in SAP. If it retrieves a packet of IDocs, it updates the status of all IDocs in the packet. For more information, see Updating the IDoc status in SAP.
The Ale module uses FIFO (First In, First Out) to maintain the processing order when reading the messages from the Event queue.
Table 23 describes the structure of the message that the connector
sends to the Event and Archive queues.
Table 23. Structure of JMS-MQ message for event and archive processing
Property name | Description |
---|---|
CorrelationId | The JMS message header property--the connector sets the value of this property from the Transaction ID (TID) sent by SAP |
TidStatus | The JMS message header property that maintains the status of the TID |
IDocProcessStatus | The JMS message header property that maintains the status of the IDoc object during event processing |
BOProcessingStatus | The JMS message header property that maintains the status of all IDocs in the message using the following format, <CID> :: <IDoc sequence number><Status symbol>. Possible status symbols are S for Success, F for fail and U for unsubscribed. For example "<CID> :: 0S, 1F, 2U" means the first IDoc was successful, second failed, and third was unsubscribed for CorrelationId = <CID>. |
Table 24 describes the possible values for the IDocProcessStatus
property after an event is moved to the Archive queue.
Table 24. Archive queue values for the IDocProcessStatus message property
IDocProcessStatus property value | Event status | Description |
---|---|---|
success | Success | All business objects in the message have been posted with no errors. |
partial | Partial success | One or more but not all business objects in the message have been posted with an error. If the integration broker is WebSphere Interchange Server, one or more but not all business objects in the message have been posted with an error or are unsubscribed. |
unsubscribed | Unsubscribed | If the integration broker is WebSphere Interchange Server, all business objects in the message are unsubscribed. |
fail | Fail | All business objects in the message have been posted with an error. |
When the message is moved from the Event queue to the Archive queue, the IDocProcessingStatus and BOProcessingStatus are updated. The message body remains unchanged.
For example, assume the connector processes an event message with four
IDocs, each of which it transforms or attempts to transform into a business
object, with the results illustrated in Table 25:
Table 25. Archive message creation
Status of IDoc or business object | Resulting archive message |
---|---|
Successfully transforms the first IDoc, and posts the business object to the integration broker | The IDocProcessStatus is updated to success and the BOProcessingStatus is <CID> :: 0S |
Fails to transform the second IDoc into a business object | The IDocProcessStatus is updated to partial and the BOProcessingStatus is <CID> :: 0S, 1F |
Successfully transforms the third IDoc, and posts the business object to the integration broker | The IDocProcessStatus is set to partial and the BOProcessingStatus is <CID> :: 0S, 1F, 2S |
Successfully transforms the fourth IDoc, but the business object created is not subscribed in the integration broker |
|
To cause the connector to update a standard SAP status code after the ALE Module has retrieved an IDoc for event processing, you must:
If AleUpdateStatus evaluates to true, the connector sends the ALEAUD IDoc to SAP with status code information and, optionally, descriptive text. The ALEAUD IDoc calls the IDOC_INPUT_ALEAUD function module. The connector supports sending the following status codes to this function module:
The AleSuccessCode connector-specific configuration property can have a value of 52 or 53. SAP converts this value to 41.
The AleFailureCode connector-specific configuration property can have a value of 68. SAP converts this value to 40.
In both of the cases above, the business integration system does not send further status codes that would indicate further processing.
For information on setting the connector-specific configuration properties that are required to return IDoc status, see:
For information on setting the connector-specific configuration properties that are optional to return IDoc status, see:
The vision connector framework uses the value of the verb AppSpecificInfo property of the top-level business object to instantiate the ALE request-processing business object handler. The doVerbFor() method in the request-processing business object handler initiates all business object requests.
The business object handler converts the business object data into two tables that represent the IDoc format and its meta-data component, the control record. Once the data is in IDoc format, the business object handler makes an RFC call to the appropriate SAP function module: either idoc_inbound_asynchronous or inbound_idoc_process. Because ALE is asynchronous, the connector does not wait for a return response.
If the TransactionId attribute does not have a value, the ALE Module sends the request directly to SAP. If the TransactionId attribute has a value, the ALE Module does the following:
After successfully processing a service call request, the corresponding entry in the table of the JMS-MQ message in the SAPtid_Queue is removed and archived to a directory. A file is created in the \ale\request sub-directory for WINNT or /ale/request for Unix systems. The ale sub-directory is located in the directory where the adapter is started. The entry that has been removed from the table will be used to create the new file. The file name will have the following format: <ObjectID>_<TID><timestamp>.executed where ObjectID is the value from the TransactionId attribute, TID is the transaction ID from SAP, and timestamp is the time stamp of when the file was created.
The adapter itself manages the deletion of these archive files using the connector configuration property ArchiveDays. The value in the connector configuration property, ArchiveDays, determines the amount of days these archived files will persist in the ale\request sub-directory. Any files older than the number of days specified in ArchiveDays will be deleted. If this property is not configured, the default value for ArchiveDays is seven days. These archive files can also managed manually by deleting the files yourself.
For all failed requests indicated by the integration broker, check whether an archive file has been created for the request. If the archive file exists for the Object ID in the request then do not resubmit the request from the integration broker. Resubmit the request if there is no archive file for that ObjectID. Ensure the ArchiveDays connector configuration property is set to a value that will allow for verification of resubmitted requests.
Table 26 describes the columns of the JMS-MQSeries message that the
connector gets from the SAPtid_Queue:
Table 26. Columns of JMS-MQ message for request processing
Column name | Description |
---|---|
ObjectID | The value that is in the TransactionID attribute of the requested business object. This value is used as the key for the table |
TID | The transaction ID obtained from SAP |
TidStatus | Status of the transaction |