Updated Call from Orchestrator to AOPD as Asynchronous

Communication between Orchestrator and AOPD was synchronous. Until now, Orchestrator used to call AOPD to generate plans and once the plans were generated, AOPD returned the plans to Orchestrator.

The v1/generatePlan and v1/plan/amend APIs were used to generate and amend plans respectively. The generated or amended plans were returned in the response to the Orchestrator.

When AOPD takes longer to generate plans for some large plans or any other reason, Orchestrator times out and and the plans fail to generate. This was the issue with the synchronous call.

Updates:

Now, the communication between Orchestrator and AOPD is asynchronous.

The following new asynchronous APIs are introduced in AOPD:

  • /v1/plan/async to generate plans
  • /v1/plan/amend/async to amend plans

Orchestrator calls AOPD through these APIs to generate or amend plans. In the response, AOPD acknowledges that it has received the plan generation request. Then AOPD generates the plans and submits the plans to the Orchestrator in the submitOrderExecutionPlan API.

Note: These new APIs are not yet secured and hence are not exposed on Swagger.

Retry Mechanism

The plan publication is backed up by a retry mechanism. This retry can be controlled by the following newly introduced properties:

  • planSubmissionRetryCount (Default = 5)
  • planSubmissionRetryDuration (Default = 5 seconds)

For example, you have the default values and plan generation fails, AOPD retries up to 5 times in 5-second intervals to submit the plan to Orchestrator.

Note: The retry mechanism is ignored for the BadRequest and Unauthorized errors.

Troubleshooting:

When the plan generation fails even after maximum retry attempts, perform the following steps to generate or amend plans.

  1. Call getOrderDetails API from Orchestrator to get the order request details.
  2. Call v1/generatePlan or v1/plan/amend APIs from AOPD to generate or amend plans.
  3. Submit the generated plan to Orchestrator using the submitOrderExecutionPlan API.

Re-introduced FEASIBILITY and OPD states

Previously, there were three states for an order for processing flow:

PENDING > EXECUTION > COMPLETE

As the call between Orchestrator and AOPD is now asynchronous, FEASIBILITY and OPD states are re-introduced. The order flow is updated as follows:

PENDING > FEASIBILITY > OPD > EXECUTION > COMPLETE