M226: Standing by HTTP Request

 

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 Process that is standing by to trigger the Process to resume. For example, a "Web production process" can call a "Translation process" 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 process" 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 "Process ID", “API key” and the “business data that you want to store”

$ curl https://example.questetra.net/System/ReceiveTask/HttpPost/123/0/receive \ -d "processInstanceId=456" \ -d "key=XYZXYZ" \ -d "q_exampleString1=foo" \ --data-urlencode "q_exampleString2=a&b"

• Request parameters can be either GET or POST (POST is recommended, GET is partially prohibited)
• File data is transmitted in POST multipart
• The system variable "${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.

1. Place [Receive Task (Webhook)] in the middle of the flow
   Change the standing-by node from [Receive Task (HTTP)] to [Receive Task (Webhook)]
2. Set the receiving method
   Specify the method and content-type (e.g. "POST application/json", "PUT text/xml", etc.）
3. Set the storage location of the Body section
   Specify a String type multiple-line Data Item in which received data will be stored
4. Define the response
   Insert Issue data as necessary ("application/json;charset=UTF-8","text/xml;charset=UTF-8")
5. Set API key
   Designate a String type single line Data Item
6. 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 Issue (Process)

BPMN Icons: Receive Task (Webhook)
R2272: Output of Strings via EL syntax

X. Business Apps

• Designing Request Flow
• BPO Shipment Process