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.

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 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-clientorder-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/requestReplyFALSE 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/includeTDSFALSE 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_modeREST 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 adminJMS password
/om/jms-connection/MIG_QueueConnectionFactoryQueueConnectionFactory 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 adminJMS user name
/om/orchestrator/preQualificationFailed/response_actionRetryOPD 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_actionError 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/hostlocalhost Orchestrator service host
/om/orchestrator/orch_modeREST Orchestrator communication mode, value can be REST or JMS
/om/orchestrator/planItem-activate-request-queuetibco.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-queuetibco.aff.orchestrator.planItem.execute.request planItem execute request queue
/om/orchestrator/planItem-suspend-reply-path /v1/planitem/suspendreply 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/port9089 Port where application is opened for communication

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