By placing a [Receive Task (HTTP)], an auto-processing task, in the middle of a flow diagram, the Issue stays on the Step standing by for HTTP requests. The external program sends a request specifying the location of the standby task and ID of the Case that is standing by to trigger the Case to resume. For example, a "Web production App" can call a "Translation App" and build a mechanism to wait for the translation result.
1. Usage Example of "HTTP Standby"
- a. Waiting for the Completion of Outsourced Work
Throwing a request to the "Translation App" and waiting for the translation result.
- b. Wait for External System Communication
Throwing a Sales Aggregation Request to the Core system and waiting for the resulting summary.
- c. Waiting for Two-Stage Communication
Receive fault information from a detection system and perform the user's response while waiting to receive recovery information
2. Set the HTTP Standby Task
- 1. Receiving Data Items
Set the Data editing permission to [Editable (Read/write)].
- You can see the URL/Parameter Details which show the Request URL and the names of the Receptions parameters, etc.
- The data receiving parameter is the [Field Name] set in the Data Item
3. Preparing Mechanism of Data Transmission (External Setting)
- 1. Request URI
Specify the App ID and Task Node number using Path Parameter
- 2. POST body parameter
Specify the "Case ID", “API key” and the “business data that you want to store”
- Request parameters can be either GET or POST (POST is recommended, GET is partially prohibited)
- File data is transmitted in POST multipart
- The system constant "${var[applicationRoot]}" is available for communication on the same Workflow platform
- The value of the API key can be arbitrarily set (alphanumeric characters, at most 100 in length)
- Communication from external networks is not permitted by default (M312)
- It is possible to filter the source IP address for each start URL (M312)
- If a parameter value is sent as an empty string it will clear that value
- If no parameters are sent the input value is maintained as it is
BPMN Icons: Receive Task (HTTP)
R2210: Naming Convention for Data Receiving Parameter
A. Corresponding with JSON-Webhook, etc.
- Place [Receive Task (Webhook)] in the middle of the flow
Change the standing-by node from [Receive Task (HTTP)] to [Receive Task (Webhook)] - Set the receiving method
Specify the method and content-type (e.g. "POST application/json", "PUT text/xml", etc.） - Set the storage location of the Body section
Specify a String type multiple-line Data Item in which received data will be stored - Define the response
Insert Issue data as necessary ("application/json;charset=UTF-8","text/xml;charset=UTF-8") - Set API key
Designate a String type single line Data Item - Set the deadline (optional)
The [Boundary Event] will be displayed on the auto-Step icon and you can define the flow after the timeout
- Even though it is possible to set patterns that are improbable with normal REST communication, it is not recommended (e.g. Get communication specifying the Content-Type, etc.)
- In many cases some automatic Steps are placed at the downstream for extracting the necessary information from the received data
- Even if the Query parameter has been given [Receive Task (Webhook)] ignores the query part
- It is possible to dynamically change the API key for each Case
BPMN Icons: Receive Task (Webhook)
R2272: Output of Strings via EL syntax