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 sends 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 act on the Technical Product Account, an asynchronous backend call is required.

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

process component Example - Use Case Activity Diagram

Account Implementation

As described in the previous section, there is one Functional Product UserAccount and one Technical Product Account.

Once the order for the Product UserAccount has been submitted to Order Management Server, Automated Order Plan Development generates the PLAN and the Orchestrator sends a PlanItemExecutionRequest Event with the plan item to be executed based on the sequence defined in TIBCO Product and Service Catalog when the product has been modeled.

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 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 can also be used instead of PlanID.

PlanID and PlanItemID can be used to set a user-defined field by using Order Management Server data access interfaces when the process component sends the request to the backend application and this user-defined field can either contain:

1. A BW process name, which deals with the response.
2. A unique queue name, which is used to send a message into it to trigger the process that deals 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 is one BW process that receives all the replies from the backend application and it works 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 inserts the CorrelationID in the response, which can be used to retrieve information by using Order Management Server data access interfaces and the particular user-defined field, which contains the consumer of the response.

Here it is assumed that Technical Product 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 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 is used to retrieve, by using the Order Management Server data access interfaces, the user-defined field 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 to elaborate the response.

The user-defined field shows how to store the user-defined field by using the "setPlanItem" JMS data access interface of Order Management Server.

process component Example: Set user-defined field for response

In the user-defined field it is possible to observe that before calling the backend application (CallBackEndApplication), a user-defined field called “callBackQueue” has been set with a queue name: “rfs.UserAccount.Account.response”. A BW process as seen in the process component listens on this queue and processes the message sent by the “ConsumeResponse” BW process as seen in the process component.

Alternatively, as mentioned before, it was also possible to set the user-defined field 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 user-defined field by performing a dynamic call to it.

To summarize, 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" Order Management Server data access interface by using planID/planItemID to retrieve the user-defined field containing the BW process that consumes the response.
3. Make a dynamic call to the BW process contained in the user-defined field and pass the replies obtained from the backend application as an input to it.
4. If the user-defined field was set as a queue name, then send a message to the queue specified in the user-defined field. A BW process as seen in the process component listens 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 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 consumes 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 sends the PlanItemExecutionRequest for the Functional Product and the process component Example: Functional Product process component is an example of the BW process that manage the request for the Functional Product. The Functional Product process component does not make any backend calls, so is simpler than the process component for the Technical Product. 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: Functional Product 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 canceled set to “false”.

Here it is necessary to analyze 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 then communicates 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 resends 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 sends an activate message to the process component, with a flag (<resumeExecution>) to indicate that processing must 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 is executed:

   • A Cancel Order is sent to Order Management Server 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 Automated Order Plan Development 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 roll back the tasks there were done by the existing plan items.
   • Once the amendment plan is received by the Orchestrator from Automated Order Plan Development, the Orchestrator sends PlanItemActivateRequest to all the suspended plan items, for canceling them, by passing the <cancelWithNoRollback> flag.
   • Once the activated plan items are successfully canceled, the corresponding compensating plan item (COMP) that were newly added in the amendment plan, is executed so as to roll back the tasks that were done by the original plan items.

process component Example: Suspend Event