Using wait()

The BI Bus API provides options to specify the amount of time a primary or secondary request can execute before IBM® Cognos® responds to the client. When a request cannot be satisfied within the specified time, the server responds with a status of working. The default values for wait thresholds for primary and secondary requests are specified using the bibus » asynchOptionEnum » primaryWaitThreshold value and the bibus » asynchOptionEnum » secondaryWaitThreshold value respectively.

When the client (portal request, client application, or another service) receives a status of working, it enters a wait loop to allow the server to complete the request. The client continues to call the asynch » wait(conversation, parameterValues, options) method until a status other than stillWorking is returned, as shown in the following diagram.

Figure 1. Wait loop for a run() request
A diagram showing the typical wait cycles of a run request as it transistions through the working and stillWorking states.

The client or application can also choose to abandon the request by calling the asynch » cancel(conversation) method (if the status is working or stillWorking) or the asynch » release(conversation) method (if the status is complete, to free up resources). If the status is conversationComplete, the conversation is already terminated and no secondary requests can be made.

Important: In order to improve resource utilization, you should call the asynch » release(conversation) method if you are finished with a conversation context before it has reached a status of complete. Doing so can free up system resources earlier by discarding unneeded contexts before they are released automatically.

It is also possible to relinquish control of a conversation by calling the monitor » background(conversation) method passing the current conversation context as an input parameter. The monitorService takes control of the conversation and continues to call the asynch » wait(conversation, parameterValues, options) method until the task is complete. This can be useful if you want to allow your application to engage in other tasks without waiting for the conversation to end.