Overview of Send Service Transaction Processing

Before you can use a send service you must make sure the Adapter for Oracle Applications’s custom tables are installed, and you must install and enable the custom triggers for each send service you want to implement. The custom tables are installed with the core database scripts. See Core Database Scripts for more information. For information about custom triggers, see Database Scripts. For information about custom tables, see Custom Tables Used with Send Services.

Custom triggers for the send service register changes to the Oracle Applications business objects in the WM_TRACKCHANGES custom table. For more information about how the triggers record these changes, see Custom Tables Used with Send Services.

Send services process transactions as follows:

Step Description
1 Specify Default Settings: Send services use a set of high-level settings to define how the services will execute. The default settings should be adequate for most cases. However, you can modify the default settings if necessary, as follows:
  • In the specifyDefaultSettings MAP step, the noOfRowsToFetch parameter defines the maximum number of business documents the service will retrieve per polling interval. By default this value is set at 100000.
Note: In version 3.0 of the adapter, the $dbAlias parameter in the specifyDefaultSettings MAP step could be modified to specify the connection the service will use. In version 6.0 of the adapter, that is no longer true. The $dbAlias parameter is still available, however it is no longer used to control a service’s connection and cannot be modified.
2 lockTxnCtrl Service: The send service calls the lockTxnCtrl service, which queries the WM_CONTROL table for a specific TRANSACTION_TYPE to determine the polling status of the business document.
  • If the lockTxnCtrl service cannot lock the WM_CONTROL table, then the send service exits and waits for next scheduled interval.

    This action prevents send services from processing the same business documents for a specific TRANSACTION_TYPE multiple times if the service’s polling interval is shorter than the time it takes to process the business document.

  • If the lockTxnCtrl service can lock the WM_CONTROL table, then the lockTxnCtrl service updates the polling status from READY to IN PROCESS.

    This action ensures that no other service can retrieve the same business document for the same TRANSACTION_TYPE.

Important: If you test a send service by stepping through its supporting services in Designer and you exit after you run the lockTxnCtrl service to lock the WM_CONTROL table but before you run the unlockTxnCtrl service to unlock it, the send service will no longer be able to run successfully because the WM_CONTROL table will continue to be locked. To unlock the table manually, you can run the commonOA1227.utils:unlockTxnCtrl service, providing the appropriate TRANSACTION_TYPE parameter. This service is located in the WmOACommon1227 package.

For more information, see WM_CONTROL Table.

3 getDocTxn Service: The send service calls the getDocTxn service. The getDocTxn service uses the getDocTxnOutputRec document to define the business document’s logical structure. The getDocTxn service also queries the WM_TRACKCHANGES table and the Oracle Applications production tables to create one or more business documents, as follows:
  • In the WM_TRACKCHANGES table, the getDocTxn service finds the records representing the latest unprocessed events made to the business object. Unprocessed event records have a value of N in the PROCESSED_FLAG field.
    Note: For some services, the business document must have a status of Approved in Oracle Applications for the service to retrieve it, preventing the service from picking up business documents that are not completed and approved, such as an incomplete Purchase Order.
  • For each unprocessed business document in the WM_TRACKCHANGES table, the getDocTxn service selects records based on the business object type (TRANSACTION_TYPE), groups the records by the specified business object (TRANSACTION_ID), and calculates the total TRANSACTION_STATUS for all records of a specific business object.
    Note: The TRANSACTION_STATUS is a numeric field. Each record contains a value that corresponds to its status: 0 for UPDATE, 1 for INSERT, and 2 for DELETE. For more information about the WM_TRACKCHANGES table, see WM_TRACKCHANGES Table.
  • Based on the sum of the TRANSACTION_STATUS fields for all of the records in the WM_TRACKCHANGES table for the business object, the service processes the record as follows:
    • 0: The service processes the record as an UPDATE event.
    • 1: The service processes the record as an INSERT event.
    • 2: The service processes the record as a DELETE event.
    • 3 or higher: The service takes no action.

    For a description of how the service processes INSERT and UPDATE events, see Send Services.

    For a description of how the service processes DELETE events, see Send Services.

The service uses the WEB_TRANSACTION_ID to process the oldest records first.

The service generates one or more business documents based on the results of the getDocTxn service.

Note: Polling services query the WM_TRACKCHANGES table and Oracle Applications production tables by executing SQL trees against them. For more information about SQL trees, see IBM webMethods Adapter for Oracle Applications Installation and User’s Guide.
4 processBizDoc Service: The send service calls the processBizDoc service to process the business document. By default, this service does not send the business document anywhere. You must modify this service to send the business document to the desired recipients.

After the processBizDoc service processes the business document, it sets the transferStatus field of the docTransferResults document to SUCCESS or ERROR. By default, the transferStatus field for each business document is set to ERROR.

5 WM_TRACKCHANGES Table: The send service manages the records in the WM_TRACKCHANGES table as follows, depending on whether the service is configured to run in debug mode:
  • If the service is not running in debug mode (debugMode parameter = FALSE), then it deletes one or more records from WM_TRACKCHANGES table after it processes them.
  • If the service is running in debug mode (debugMode parameter = TRUE), then it keeps the records in the WM_TRACKCHANGES table and updates them to indicate that they have been processed.

If a business document fails during transmission, the send service inserts a new record into the table for the failed record. The new record will have a TRANSACTION_STATUS that contains the sum of the TRANSACTION_STATUS fields for all of the related business object records for the business document that failed.

You do not need to manually re-process a transaction that fails in the processBizDoc service because it will be processed again during the next scheduled execution of the service.

6 unlockTxnCtrl Service: The send service calls the unlockTxnCtrl service to unlock the WM_CONTROL table after the send service finishes processing.