BusinessWorks - Asynchronous process component
This section provides an example of 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 ends.
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 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 to the caller.
Let us 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 the 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 the Order Management Server, Automated Order Plan Development generates the PLAN, and the Orchestrator posts a PlanItemExecutionRequest event with the plan item to be run 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 the response, the Orchestrator releases the lock and planItemExecuteStub.bwp continues to run 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 the 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 the Authorization service and retrieves the cache access_token.
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
The following table shows the description and default values of the module properties:
Property name | Default Value | Description | |
---|---|---|---|
/om/authorization-service/enableSecureAPI
| TRUE
| If the secure API is enabled on the Orchestrator, this must also be the same. It must be in sync with the Orchestrator. | |
/om/authorization-service/host
| localhost | Host of authorization-service | |
/om/authorization-service/order-management-client | order-management-client
| Order-management-client | |
/om/authorization-service/order-management-secret
| order-management-secret
| Order-management-secret | |
/om/authorization-service/password
| admin | Password for user | |
/om/authorization-service/port
| 9091 | Service port for authorization | |
/om/authorization-service/username
| admin | User name | |
/om/data-service/getPlan/idsOnly
| FALSE | The
idsOnly is an input parameter in the
getPlan endpoint of the data-service.
| |
/om/data-service/getPlan/includeItems
| TRUE
| The
includeItems is an input parameter in the
getPlan endpoint of the data-service.
| |
/om/data-service/getPlan/requestReply
| FALSE | The
requestReply is an input parameter in the
getPlan endpoint of the data-service.
| |
/om/data-service/getPlanItem/idsOnly
| FALSE | The
idsOnly is an input parameter in the
getPlanItem endpoint of the data-service.
| |
/om/data-service/getPlanItem/requestReply
| FALSE | The
requestReply is an input parameter in the
getPlanItem endpoint of the data-service.
| |
/om/data-service/setPlan/requestReply | FALSE | The
requestReply is an input parameter in the
setPlan endpoint of the data-service.
| |
/om/data-service/setPlanItem/requestReply
| FALSE | The
requestReply is an input parameter in the
setPlanItem endpoint of the data-service.
| |
/om/data-service/host
| localhost | Data-service host | |
/om/data-service/includeTDS | FALSE | This flag indicates whether you want a
tds call during
planitem execution or not.
| |
/om/data-service/port
| 9095 | Data-service port | |
/om/data-service/tds_mode | REST | This property is used to toggle between
REST tds call and
JMS tds call (Legacy support)
| |
/om/data-service/tds_read_timeout
| 3000 | This property used to set wait time in milliseconds if
the requestReply flag is true; used in
JMS tds call (Legacy support)
| |
/om/jms-connection/MIG_Password
| admin | JMS password
| |
/om/jms-connection/MIG_QueueConnectionFactory | QueueConnectionFactory
| Queue Connection Factory | |
/om/jms-connection/MIG_TopicConnectionFactory | TopicConnectionFactory
| Topic Connection Factory | |
/om/jms-connection/MIG_Url
| tibjmsnaming://localhost:7222
| JMS URL
| |
/om/jms-connection/MIG_Username
| admin | JMS user name | |
/om/orchestrator/preQualificationFailed/response_action | RetryOPD | The Response action takes place when
PreQualificationFailedReply sent to the Orchestrator. The possible values are
RetryOPD ,
WITHDRAW , and
RetryFeasibility (Case sensitive)
| |
/om/orchestrator/planItemErrorHandler/response_action | Error | The Response action takes place when
PlanItemErrorHandlerReply sent to the Orchestrator. The possible values are
Retry ,
Resume ,
Complete , and
Error (Case sensitive)
| |
/om/orchestrator/orderInjector/orderTemplate
| $OM_HOME\samples\TestHarness\RestTestHarnessBW6.module\config\OrderTemplate.json
| Order Template Path | |
/om/orchestrator/orderInjector/testInjectorConfig
| $OM_HOME\samples\TestHarness\RestTestHarnessBW6.module\config\TestInjectorConfig.xml
| TestInjector configuration file
| |
/om/orchestrator/host | localhost | Orchestrator service host | |
/om/orchestrator/orch_mode | REST | Orchestrator communication mode, value can be
REST or
JMS | |
/om/orchestrator/planItem-activate-request-queue | tibco.aff.orchestrator.planItem.activate.request
| planItem activate request queue
| |
/om/orchestrator/planItem-execute-reply-path | /v1/planitem/executionreply
| planItem execute reply path
| |
/om/orchestrator/planItem-execute-request-queue | tibco.aff.orchestrator.planItem.execute.request
| planItem execute request queue
| |
/om/orchestrator/planItem-suspend-reply-path
| /v1/planitem/suspendrep ly
| planItem suspend reply path
| |
/om/orchestrator/planItem-suspend-request-queue
| tibco.aff.orchestrator.planItem.suspend.request
| planItem suspend request queue
| |
/om/orchestrator/port
| 9093 | Orchestrator port | |
/om/process-component/host
| localhost | Current host | |
/om/process-component/port | 9089 | Port where application is opened for communication |
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 the module is set to false), it avoids the Transient Data Store call and directly calls sendExecutionResponse.bwp.
If the process component is configured as long lived (/om/data-service/includeTDS property in the 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 the process component is Long lived.
ExecuteServiceClient.bwp:
The
sendExecutionResponse.bwp
process generates a
planItemExecuteResponse
with the success flag as true, the completed flag as true, and the canceled flag as false.
Then
sendExecutionResponse.bwp
POST on the
planItemExecuteReply
service of the Orchestrator. You can change the configuration of the Orchestrator by modifying the module properties.