Types of retries

The following types of retries are supported in TIBCO Order Management:

Messaging level

Messaging level retries are applicable wherever JMS is used. In the Archival, Data service, Orchestrator, Catalog, Jeopardy, and Migration services JMS is used. In case of any error, the retry mechanism is triggered as per the configuration.

Feasibility retry

Feasibility retry takes place when com.tibco.fom.orch.feasibilityRequired and retryFailedFeasibility flags from the orchestrator application are set to true.

When an error occurred, it retries for a specified number of times (feasibilityRetries) in a specified interval (feasibilityRetryInterval) before the order goes in to the preQualificationFailedReply.

Plan fragment based retry

Plan fragment based retry takes place when the retryOverride flag from the process component model is set to true.

When an error occurred, it retries for a specified number of times (retryCount) in a specified interval (retryDelay) before the plan item goes in to the ERRORHANDLER/ERROR state.

Plan Item failure retry configurations

This is a backup of Plan fragment based retry. Plan Item failure retry configurations take place when the retryOverride flag from the plan fragment model is set to false.

When an error occurred, it retries for a specified number of times (maxRetryCount) in a specified interval (retryInterval) before the plan item goes in to the ERRORHANDLER/ERROR state. The system uses the default properties configured in the Orchestrator under the "Plan Item Failure Retry Configurations" category.

Web client retry

TIBCO Order Management uses Spring's WebClient for inter-service communication on HTTP.

When an error occurred, it retries for a specified number of times (*RetryCount) in a specified interval (*RedeliveryDelay) before the HTTP communication failed.