A delivery AIM receives transactions routed by an SFM and sends them to the endpoint application.
Program flow in a delivery AIM can begin either with a function that services a DFC or with the protocol object. Figure 1-3 illustrates the program flow through a delivery AIM, and the action sources that trigger entry into the AIM.
An SFM sends a servayt() DFC. The message AIM executes the servayt() function to service the DFC. This function gets the serial number of the last transaction that the AIM processed from the lastid file. The function finishes by sending that serial number to the SFM. Program control returns to the protocol object, which waits to receive data from the communication object, or waits for the SFM to send another DFC.
The SFM sends a servproc() DFC. The message AIM executes the servproc() function to service the DFC. This main task of this function is to put the data received from the SFM into the format required by the endpoint application and send the data through the communication object to the endpoint.
After servproc() sends the data to the endpoint, it calls clSuspend() to suspend processing of servproc() to wait for a response from the endpoint application. When the endpoint sends a response, the protocol object processes the response data through the preview control flow, then through the message frame objects and their control flows.
After the endpoint’s response is fully processed, the final control flow runs on the response data and calls clRelease() to return processing control to servproc(). The servproc() function finishes any required processing, including writing the transaction’s serial number to the lastid file and returning the appropriate value back to the SFM. The appropriate value sent back to the SFM may be an error condition if the endpoint system did not accept the transaction.
The AIM waits for the next DFC from the SFM. Program control returns to the protocol object, which waits to receive data from the communication object, or waits for the SFM to send another DFC.
The communication object connects or dies. When the communication object connects to its designated port, it notifies the protocol object that it connected. The protocol object executes the control flow object listed in its Open box. Program control returns to the protocol object, which waits to receive data from the communication object, or waits for the SFM to send a DFC.
If the communication object terminates unexpectedly, the protocol object executes the control flow object listed in its Close box. In this case, it uses the restart() method in the close control flow to restart the communication object or uses a timer object to delay restarting the connection.
The communication object gets a response from the endpoint. After servproc() sends data through the communication object to the endpoint, it calls clSuspend() and waits for a response from the endpoint. When the protocol object receives a response about the transaction from the endpoint application, it executes the control flow object listed in its Preview box. The protocol object processes the data received from the endpoint application through its message frame objects and their control flows.
After the endpoint’s response is fully processed, the final control flow runs on the response data calls clRelease() to return processing control to the servproc() function. If the protocol object receives data through the communication object while the AIM is processing a DFC, the data queues at the protocol object until the function processing the DFC calls clSuspend().
The communication object does not have to be connected to its port before the AIM can begin servicing a servayt() or servproc() DFC from the SFM. However, the communication object must be connected before the servproc() function can send the data to the endpoint application.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
