BusinessWorks - Asynchronous Process Component

Use Case Scenario

A telecommunication company wants to provide a new service for new customers and between all the Use Cases identified there is the Use Case: UserAccount.

This Use Case creates a new user account by calling a backend application and passing it all the information related to the user. The backend application has an asynchronous interface and after receiving a request will send a reply back to the caller.

Let’s assume that the Use Case has got:

• A Functional Product (FP) called: UserAccount
• A Technical Product (TP) called: Account, which is related to UserAccount via a Product-Comprised-Of relationship. To perform an action on the TP Account, an asynchronous backend call is required.

Below there is an Activity Diagram which describes the steps to be performed to create TP Account.

Process Component Example - Use Case Activity Diagram

Account Implementation

As described in the previous section, there is one FP UserAccount and one TP Account.

Once the order for the Product UserAccount has been submitted to OMS, AOPD will generate the PLAN and the Orchestrator will send a PlanItemExecutionRequest Event with the plan item to be executed based on the sequence defined in Fulfillment Catalog when the product has been modelled.

The PlanItemExecuteRequest message is received in a main BW process as shown in Process Component Example - Use Case Activity Diagram in the process component implementation. This process sends a message on a queue which is internal to process component implementation.

Process Component Example: Receive PlanItemExecutionRequest from Orchestrator

Process Component Example: Send Backend Request

The process in Process Component Example: Send Backend Request receives the message from the internal queue and calls the specific BW process that implements the actual process component as mentioned in Process Component Example: Backend application call.

As mentioned in the previous section, the backend interface is asynchronous so when the Process Component sends a request to the backend application, it also has to send a CorrelationID which needs to be returned with the response from the backend application in order to correlate it with the request. In this example it is assumed that the Backend is capable of doing this.

This can be observed in the Process Component Example: Backend application call that represents the “Create Account” Process Component which makes a call to the backend application:

Process Component Example: Backend application call

In the Process Component Example: Backend application call it is possible to notice that:

1. The CorrelationID is passed in the call of the CallBackEndApplication.
2. BackEndApplicationName is: “UserAccount”.
3. Action is “create”.

Regarding which CorrelationID to use, one possibility is to use a concatenation of PlanID-PlanItemID. OrderRef or Order ID could also be used instead of PlanID.

PlanID and PlanItemID can be used to set a UDF using OMS data access interfaces when the Process Component sends the request to the backend application and this UDF could either contain:

1. A BW process name which will deal with the response.
2. A unique queue name which is used to send a message into it in order to trigger the process that will deal with the response. This means that each BW process that consumes the reply from the backend application has to have a unique queue name.

Let’s assume that there will be one BW process that receives all the replies from the backend application and it will work as a dispatcher of the messages amongst other BW processes that are the consumers of the replies coming from the backend system.

When the backend application replies it will insert the CorrelationID in the response which can be used to retrieve information using OMS data access interfaces and the particular UDF which contains the consumer of the response.

Here it is assumed that TP sends a message to a backend application in a queue and receives the reply by listening to another queue.

Process Component Example: BW process receiver

In Process Component Example: BW process receiver above the JMS Queue Receiver activity receives the response from the backend application; it is the BW process that receives all the replies from the backend system. The “GetPlanID” mapper activity parses the id parameter coming from the backend application and gets the planID and planItemID.

At the end of the process there is a call to a BW process: “ConsumeResponse” which dispatches the response and it is possible to pass the planID and planItemID to it which will be used to retrieve, using the OMS data access interfaces, the UDF we set in the request containing the information regarding which BW process has to be called or to which queue it is necessary to send the reply from the backend application in order to elaborate the response.

The Process Component Example: Set UDF for response shows how to store the UDF by using the "setPlanItem" JMS data access interface of OMS.

Process Component Example: Set UDF for response

In the Process Component Example: Set UDF for response it is possible to observe that before calling the backend application (CallBackEndApplication), a UDF called “callBackQueue” has been set with a queue name: “rfs.UserAccount.Account.response”. A BW process as seen in the Process Component Example: Start Specific BW Technical Product Consumer Process will listen on this queue and will process the message sent by the “ConsumeResponse” BW process as seen in the Process Component Example: BW ConsumeResponse Process.

Alternatively, as mentioned before, it was also possible to set the UDF with a BW Process name that would have dealt with the response; in this way the main BW process, which receives all the responses, would have redirected it to the BW process contained in the UDF by performing a dynamic call to it.

To summarise, these are the steps to be performed by the main BW process that receives all the responses from the backend application:

1. Upon the receiving of a response from the backend application, retrieve the planID/planItemID from it.
2. Use "getPlanItem" OMS data access interface by using planID/planItemID to retrieve the UDF containing the BW process that will consume the response.
3. Make a dynamic call to the BW process contained in the UDF and pass the replies obtained from the backend application as an input to it.
4. If the UDF was set as a queue name, then send a message to the queue specified in the UDF. A BW process as seen in the Process Component Example: Start Specific BW Technical Product Consumer Process will listen on that queue and process the response received from the back-end application.

Process Component Example: BW ConsumeResponse Process

Process Component Example: Start Specific BW Technical Product Consumer Process

From the Process Component Example: Start Specific BW Technical Product Consumer Process it is possible to see that if the resultCode coming from the backend application response is not equal to zero, then a PlanItemExecuteResponse with complete set to true and success set to false is sent back to orchestrator; otherwise the ImplementConsumer BW process is called and it will consume the response from the backend application and a successful PlanItemExecuteResponse is sent back to Orchestrator.

Process Component Example: Example of BW Process Component Consumer

When the TP has been executed and the PlanItemExecutionResponse with complete and success set to true sent back to orchestrator, this will send the PlanItemExecutionRequest for the FP and the Process Component Example: FP Process Component is an example of the BW process that manage the request for the FP. The FP process component does not make any backend calls,so is simpler than the process component for the TP. There is always a call to an Implementation BW process that consume the request, it returns to the process caller and sends a successful PlanItemExecuteResponse back to the Orchestrator.

Process Component Example: FP Process Component

Exception Handling Component

Having a look at the Activity Diagram shown in the Process Component Example - Use Case Activity Diagram it is possible to notice that when a request is submitted to the backend application, if the error code is equal to zero then the successful path flow is followed (ex: update a variable state with “Submitted”) whereas if the result code is different from zero, it is possible to have a Retry/Continue or Rollback scenario.

In this section it is assumed that the Process Component sends/receives a message to/from a queue to communicate with a backend application.

When the backend application replies with an error code, the Process Component sends a PlanItemExecutionResponse Event to the Orchestrator with: completed flag set to “true”, success and cancelled set to “false”.

Here it is necessary to analyse the different kinds of Exception Handling one by one:

1. Retry with Edit

   The Process Component made a call to the backend application which replies with an error. Orchestrator will then communicate with the Exception Handler (see Exception Handling Guidelines for more information) to see what the next action is. The Exception Handler has determined that the required action is that the data on the order needs to be edited, and the plan item step retried. The Exception Handler communicates with Orchestrator and asks it to resend the planItem which failed. Orchestrator will resend another PlanItemExecutionRequest for that Process Component.

2. Continue

   In this case, the Exception handler returns to Orchestrator a Resume response. On receipt of the resume, Orchestrator will send an activate message to the Process Component, with a flag (<resumeExecution>) to indicate that processing should resume. In this case the Process Component executes the next step that would have normally executed in a success case scenario, for example: update the installed base. The Process Component Example: Activate Event shows a BW process that implements the Continue scenario:

   Process Component Example: Activate Event

   

   When the Process Component receives the Activate Event(PlanItemActivateRequest Event) message and the action is not “CANCEL” it means that it has to Resume and carry on with the next step which in the Process Component Example: Activate Event is called the BW process that represent the continue step.

3. Rollback

   In case of Rollback, the following steps will be executed:

   • A Cancel Order is sent to OMS by the Exception Handler.
   • Orchestrator sends a PlanItemSuspendRequestEvent to the Process Component as shown in the Process Component Example: Suspend Event. The suspend event is sent because a plan in execution state needs to go into suspend state before being compensated.
   • The Process Component replies with a PlanItemSuspendResponseEvent and sets success and completed flags to “true”.
   • Cancel order is treated as a special case of amendment. An updated plan is created by AOPD to cancel all the existing plan items. Compensation plan items that are required against some of the existing plan items are also added in the amended plan so as to actually rollback the tasks there were done by the existing plan items.
   • Once the amendment plan is received by the Orchestrator from AOPD, the Orchestrator will send PlanItemActivateRequest to all the suspended plan items, for canceling them, by passing the <cancelWithNoRollback> flag.
   • Once the activated plan items are successfully cancelled, the corresponding compensating plan item (COMP) that were newly added in the amendment plan, will be executed so as to rollback the tasks that were done by the original plan items.

Process Component Example: Suspend Event