Publishing Engine Programmer's Guide > The Arbortext Publishing Engine Request Manager > Understanding the Internal Structure of Arbortext PE Request Manager > Request Processing > Basic Flow of Control for Request Processing
  
Basic Flow of Control for Request Processing
Each time it receives an HTTP request from its servlet container, the Arbortext PE Request Manager performs the following steps to process the request:
1. First, the Arbortext PE Request Manager assigns a transaction ID and creates a transaction directory. Then it saves the request descriptor into the transaction directory. If the request includes a body, the Arbortext PE Request Manager reads the request body from the network and saves it to disk in the transaction directory.
2. Next, the Arbortext PE Request Manager iterates through the cache managers and calls each cache manager's com.arbortext.e3.E3CacheManager.search method. Possible results:
If a cache manager returns a cached response, stop iterating and return the response to the client.
If a cache manager doesn't contain the response but wants to cache it, remember that and continue the iteration.
If more than one cache manager is willing to store the response for a request, once one is generated, the response will be placed in the first cache manager willing to cache the response.
3. If no cache manager provides a response, the Arbortext PE Request Manager iterates through every queue manager and calls each queue manager's com.arbortext.e3.E3QueueManager.service method. Possible results:
If a queue manager can't queue the request, continue the iteration.
If a queue manager returns a response, stop the iteration and return the response to the client.
Presumably, the response will state that the request was queued for execution later and provide the Transaction ID so that the client can check for completion and retrieve the transaction result. The Arbortext Queue Manager that ships as part Arbortext Publishing Engine does this. Custom queue managers must return something, but the content is up to the application.
Also, presumably, the queued transaction will execute at a later time, as explained in Basic Flow of Control for Queued Requests.
4. If no cache manager or queue manager provided a response, the Arbortext PE Request Manager iterates through every Request Handler and calls each request handler's com.arbortext.e3.E3RequestHandler.service method.
If a request handler returns a response, the Arbortext PE Request Manager places the response in a cache manager (if one indicated an interest), then stops the iteration and returns the response to the client.
5. If no cache manager, queue manager, or request handler generated a response, the Arbortext PE Request Manager generates an error response stating that it was unable to process the request.
6. At any point in processing, when a response gets generated, the Arbortext PE Request Manager writes the response descriptor and the response body (if any) to the transaction directory.
If an error is detected during processing, the error is translated into a response and saved to the transaction directory.
7. At the end of processing, the response descriptor and response body (if any) are transmitted back to the client and the request is considered complete.
8. The Arbortext PE Request Manager then passes the completed request to its Transaction Archive subsystem, which will optionally compress the transaction directory into a single file and save the file in the transaction archive, and then delete the transaction directory.