BusinessWorks - Asynchronous process component

Use Case Scenario

A telecommunication company wants to provide a new service for new customers. The use case "UserAccount" is identified among all the use cases.

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.

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 posts 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.

planItemExecuteService.bwp:

This process receives planItemExecuteRequest through POST and sends it to planItemExecuteStub.bwp. After notifying planItemExecuteStub.bwp, planItemExecuteService.bwp responds Orchestrator with success message code 202. After receiving response, Orchestrator releases the lock and planItemExecuteStub.bwp continues to execute PlanItemExecuteResponse generation.

For the POST operation of planItemExecuteResponse on Orchestrator, this stub requires the access token. You can configure /om/authorization-service/access_token in the module properties and set /om/authorization-service/useModulePropertyAccessToken to true. Otherwise, this stub receives Authorization Service from getAuthToken.bwp and stores a token in the cache for future use.

getAuthToken.bwp:

The getAuthToken.bwp process sends a GET request to authorization service and retrieves the cache access_token.

You must configure module properties at /om/authorization-service/* with the following values: authorization service host, port, user name, password, TENANTID, order-management-client, and order-management-secret.

planItemExecuteStub.bwp:

The planItemExecuteStub.bwp receives planItemExecuteRequest and starts processing it.

Then you can send a subprocess call to DefaultProcessComponent.bwp.

Module Properties

DefaultProcessComponent.bwp:

This process receives a PlanItemExecuteRequest and an access_token.

If the process component is configured as short lived (/om/data-service/includeTDS property in module is set to false), it avoids Transient Data Store call and directly calls sendExecutionResponse.bwp.

If the process component is configured as long lived (/om/data-service/includeTDS property in module is set to true), it calls Transient Data Store service through GetAndSetUDFData.bwp and then calls sendExecutionResponse.bwp.

GetAndSetUDFData.bwp:

This process calls Transient Data Store services to set and get user-defined field data on plan or planItem level. Data Service Configuration can be done in module properties. This process is called only when process component is Long lived.

ExecuteServiceClient.bwp:

The sendExecutionResponse.bwp process generates a planItemExecuteResponse with the success flag as true, completed flag as true, and canceled flag as false.

Then sendExecutionResponse.bwp POST on the planItemExecuteReply service of the Orchestrator. You can change the configuration of Orchestrator by modifying the module properties.