You can configure your service implementation so that the service request is completed asynchronously for the following service types: EJB, HTTP, Java, JMS, MQ, and SOAP.
When a service is configured to run asynchronously, it responds to the external application’s request by queuing the service request and returning a queue ID that identifies the request. A batch requestor then immediately begins processing the service request. The external application calls back later to retrieve the results of the service request.
To set up a service that processes service requests asynchronously, use the Service Wizard to generate the rules and data objects. Then you determine which queue class to use for the queued service requests, create the service request processor, and edit the generated service rule. You then use the GetExecutionRequest activity to create another service rule to get the results.
To configure a service to process requests asynchronously, complete the following steps:
- Generate the service
- Identify the queue class
- Create the Service Request Processor
- Configure the service rule for processing requests
- Create the service rule that delivers the results of the service request
To generate the service, click Configure > Integration > Services > Service Wizard and then complete the steps in the Service Wizard.
Determine whether you can use the standard service queue class System-Queue-ExecutionRequest-Service-Default or whether you need to use different queues for different services and in different rulesets.
If you need more than one queue, create one queue class for each queue that you need. Queue classes for service requests must extend the standard Process Commander class named System-Queue-ExecutionRequest-Service.
If you need to use more than one queue for the same service, create when condition rules that specify when a service request should be routed to that queue. You use the when condition rules in the service request processor that you create for the service. The when condition rule must apply to the queue class that it evaluates.
A service request processor provides configuration information about where to queue a service request and how many times to attempt to execute it if it fails the first time. For more information, see Service Request Processor data instances.
To create a service request processor, complete the following steps:
- In the navigation panel of Dev Studio, click Records, and then right-click Integration-Resources.
- Click Create > Service Request Processor.
- Enter a short description, the service package name, and the request processor name.
- Click Create and open.
- On the Queuing Options tab, in the Queue Class Name field, specify the queue classes for the service requests that this request processor supports. The default service queue class is System-Queue-ExecutionRequest-Service-Default.
- Perform one of the following actions:
- If you specify one queue class, leave the When to use this queue field blank.
- If you specify more than one queue class, configure when condition rules in the When to use this queue field for each queue class that you added. Order the queue classes by dragging the fields so that the default queue is the last one in the list. Do not assign a when condition rule to the default queue.
- On the Dequeuing Options tab, in the Maximum number of execution attempts field, specify how many times the service request should be attempted if it fails the first time.
- Select both Keep in queue after all execution attempts failed and Keep in queue after successful execution check boxes.
- Click Save.
Edit the service rule that was generated by the Service Wizard.
- In the navigation panel of Dev Studio, click Records > Integration-Services.
- Double-click the name of the service rule in the list to modify the service rule.
- On the Service tab, in the Processing options section, select Execute asynchronously (queue for execution) in the Execution mode field.
- In the Request processor field, specify the service request processor that you created in the Creating the Service Request Processor section.
- On the Request tab (HTTP, JMS, MQ, or SOAP) or Parameters tab (EJB or Java), verify that the data mappings generated by the wizard for the request are appropriate. Modify them if you need to.
- On the Parameters tab for an EJB or Java service or the Response tab for an HTTP, JMS, MQ, or SOAP service rule, configure the data mapping for the pxQueueItemID parameter.
- For SOAP, in the Response headers section, click Add Item to create a row for the parameter.
- For HTTP, JMS, or MQ, in the Message Contents section, configure the default Response Condition to contain the parameter.
- For EJB and Java, you specify the parameter as the Return Value.
- Click Save.
Create a service rule that uses the standard service activity GetExecutionRequest to deliver the results of the original service request when the external application calls back.
- Click Configure > Integration > Services > Service Wizard.
- As you run the wizard, make the following selections:
- On the Select Service Purpose step, in the Service purpose field, select Invoke existing activity rules.
- On the Select Activity Class step, in the Activity Class field, select @baseclass.
- On the Select Service Activities step, select the check box for the GetExecutionRequest activity.
- On the Select Service Resources step, make the following selections:
- In the Ruleset name and Ruleset version fields, specify the same ruleset and ruleset version, respectively, that you used for the first service you created in the Generating the service section.
- In the Service package options field, select Use an existing service package.
- In the Existing service packages field, select the same service package that you used for the first service you created in the Generating the service section.
When the service creates its response, all the data from the retrieved service request is on the clipboard. You can map as much or as little of the data as necessary on the Response tab for a SOAP, JMS, MQ, or HTTP rule or on the Parameters tab for an EJB or Java service.
If the external application needs confirmation about whether the request ran successfully, you can configure a data mapping for the pxExecutionStatus parameter.