Deferred Requests Queue

There are use cases where an entity is set to a status that waits for a subsequent task to be performed asynchronously before it can progress in its lifecycle. Such task is implemented using monitor rules plugged into the entity's business object status definition along with a batch control. These monitor rules are not processed right away when the record enters that status but rather get deferred to when the associated batch runs next.

When the deferred task should be processed as soon as possible, a message can be added to the Deferred Requests Queue to perform the task near real-time. This mechanism offers a managed queue of messages, each representing a request to perform the deferred monitor rules of a given entity, similar to how these rules are processed in batch.
Note: This mechanism is only available in a cloud installation.
CAUTION: This feature should only be used to support business flows with time dependent events that require near real-time processing. All other asynchronous flows should remain deferred to batch processing.

The following sections describe concepts and features of the near real-time processing mechanism.

Requesting Near Real-time Processing

When an entity enters a status that is associated with time dependent deferred monitor rules, a request can be made to process these rules as soon as possible after the current transaction is committed.

The product supports the following options for requesting near real-time monitoring of an entity:

  • To always send the entity for near real -time processing when it reaches a specific status, add the 'Add a Deferred Request' (F1-DFREQADDN) 'Enter' algorithm to the respective business object status definition. Refer to the algorithm detailed description for more information.

  • You may use the DeferredRequestAPI function in a Groovy based algorithm to implement custom rules around when and how to add such request to the queue.

  • When applicable, the Generic Data Synchronization functionality also supports an option for near real-time processing that uses the Deferred Requests queue.

Exception Handling

When the deferred request is successfully processed by the real-time queue agent, the related entity is updated as per its business object rules. However, if the request keeps failing after several retries, the queue agent discards the request and the related entity stays in its current status, waiting to be picked up by the corresponding deferred monitor batch. At that point, if the error still persists the batch reports the issue as usual.
Warning: Do not remove the deferred batch control from the business object status definitions. These flows must remain deferred to batch as designed for data integrity reasons.

When applicable, sending entities to be processed near real-time allows the corresponding monitor batch to be scheduled less often as it no longer needs to meet near real-time frequency requirements. With most of the records successfully processed by the near real-time mechanism, the monitor batch is mainly used to handle exceptions.

Correlated Requests

By default, messages in the queue are processed in no particular order. In situations where multiple messages update the same resource there may be a need to process them serially to prevent concurrency errors.

When adding a message to the queue, the message can optionally reference the main entity it updates for the purpose of correlating it with other messages that update the same entity. Messages explicitly referencing the same main entity are processed serially.

Apply Polling Delay

When an entity's current status is associated with monitor rules that wait for a specific condition to be met in order to determine the next status the entity should transition to, it is not enough to perform these monitor rules once. The condition may not be met initially but could be met within a short period of time. In this situation, the deferred request placed in the queue could indicate that it requires polling delay.

When polling delay is requested, the deferred request message in the queue is processed as follows:

  • When the message is added to the queue the current status of the related entity is noted.
  • After successfully processing the message, if the related entity's status remains unchanged, the queue agent completes the current message and adds another message to the queue along with a short time delay, i.e. sets the entity to be processed again later.
  • This process repeats itself for a limited number of attempts. With each attempt the delay in seconds increases.
  • If the related entity's status remains unchanged after all attempts then the message is discarded with no exception. The related entity would be monitored as usual by the next scheduled batch run.