Triggering a process by using HTTP or HTTPS calls
Processes can be triggered using HTTP or HTTPS calls.
Actors must be assigned at least the InbasketUser_ST role to use HTTP or HTTPS calls to trigger work units. Triggering of work units is only allowed if the security class is assigned to a role for users who must perform this.
To use HTTP or HTTPS to trigger a process flow on IPA, specify a URL in this format:
http(s)://host:port/bpm/trigger?queryString
The queryString portion of the URL is a set of name/value pairs. Name and values are paired with an equals sign (=). Name and value pairs are separated with an ampersand (&).
name1=value1&name2=value2&name3=value3&...&nameN=valueN
These examples show how HTTP or HTTPS calls are used to trigger processes:
Example 1: This an example of a simple HTTP call URL which shows only required parameters:
http://ipa.example.com:8080/bpm/trigger?triggerType=ServiceAsync&triggerName=Test%20Service&dataArea=ipa1&workTitle=Trigger%20Test
Example 2: This an example of a more detailed HTTP call URL which shows some work unit values:
http://ipa.example.com:8080/bpm/trigger?triggerType=ServiceAsync&triggerName=Test%20Service&dataArea=ipa1&workTitle=Trigger%20Test&varName\[0\]=FirstName&varValue\[0\]=John&varName\[1\]=LastName&varValue\[1\]=Doe
This table shows the parameter names and values used in a queryString:
Name | Value |
---|---|
triggerType |
Specify ServiceAsync, ServiceSync, ProcessAsync, or ProcessSync. Note: When triggering a ServiceSync or ProcessSync HTTP
call, the process flow must not have a User Action node or a Wait node, and the
process must not take longer than 30 seconds to run. Otherwise, a Proxy Timeout
error will occur. This behavior is only applicable to a Service Definition that has
no more than one process flow.
|
triggerName |
Specify the name for the service trigger if the triggerType is ServiceAsync or ServiceSync. Specify the name for the process trigger if the triggerType is ProcessAsync or ProcessSync. |
dataArea | Specify the data area. Gen is not supported. |
subSystem | Specify the sub-system, or source, for the workunit. |
workTitle | Specify the work title for the workunit. |
categoryKey | Specify the category, or filter, key for the workunit. |
categoryValue | Specify the category, or filter, value for the workunit. |
bizCriteria[#] (Where # is a number from 0 to 2) | Specify the business criteria. |
inputData | Specify the input data needed for the workunit. |
product | Specify the product, or source type, for the workunit. |
varName[#] (where # is any number and # must start at 0) | Specify the name of a workunit variable. |
varValue[#] (where # is any number and # must start at 0) | Specify the value of a workunit variable. |
folderName[#] (where # is any number and # must start at 0) | Specify the name of a folder, or related link. |
folderKeyStr[#] (where # is any number and # must start at 0) | Specify the value of a folder, or related link. |
The result of a trigger call is in XML and is in this format:
<bpm-trigger-result workUnitNumber="" name="" eventType="">
<return-code="[int value]" />
<i18n-status-str="[string value]" />
<message="[string value]" />
<detail-message="[string value]" />
<errorCode="[int value]" />
<informationCode="[int value]" />
<returnData="[string value]" />
<returnMessage="[string value]" />
<errorActivityName="[string value]" />
<errorLog="[string value]" />
<debugLog="[string value]" />
</bpm-trigger-result>
In the return XML, only the workUnitNumber attribute and the return-code element are required. The return-code will be 0 and the workUnitNumber will be a positive value if the trigger was successful.
This is an example of the XML that can be returned:
<?xml version="1.0" encoding="UTF-8" standalone="true"?>
<bpm-trigger-result workUnitNumber="1750">
<return-code>0</return-code>
<detail-message>Workunit 1750 released for processing</detail-message>
<errorCode>0</errorCode>
</bpm-trigger-result>