BusinessWorks - Asynchronous process component
This section provides an example on how to approach the implementation of a Business Works process component that is “asynchronous”, in the sense that the back-end call is asynchronous. After a call is made to a backend system, the sending process terminates.
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.
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.
planItemExecuteStub.bwp:
The planItemExecuteStub.bwp receives planItemExecuteRequest and starts processing it.
To POST planItemExecuteResponse on Orchestrator, this stub requires access token. You can configure /om/authorization-service/access_token in 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.
Then you can send a subprocess call to DefaultProcessComponent.bwp.
|
Property Name |
Description |
Default Value |
|---|---|---|
| /om/orchestrator/host | Orchestrator Service host | localhost |
| /om/orchestrator/port | Orchestrator Service port | 9093 |
| /om/orchestrator/planItem-execute-reply-path | planItem execute reply path on Orchestrator | /v1/planitem/executionreply |
| /om/process-component/host | Self Service Host | localhost |
| /om/process-component/port | Self Service Port | 9089 |
| /om/data-service/host | Data Service Host | localhost |
| /om/data-service/port | Data Service Port | 9095 |
| /om/data-service/includeTDS | Include DataService Call in process component | false |
| /om/authorization-service/host | Authorization service host | localhost |
| /om/authorization-service/port | Authorization service port | 9091 |
| /om/authorization-service/username | Authorization service username | admin |
| /om/authorization-service/password | Authorization service password | admin |
| /om/authorization-service/order-management-client | Authorization service order-management-client | order-management-client |
| /om/authorization-service/order-management-secret | Authorization service order-management-secret | order-management-secret |
| /om/authorization-service/TENANTID | TENANTID | TENANTID |
| /om/authorization-service/useModulePropertyAccessToken | Use AccessToken from Module Property | false |
| /om/authorization-service/access_token | already generated access_token | token value |
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.
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.
sendExecutionResponse.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.
