Questetra has auto-steps that receive an HTTP request and start a new process, or wait for an HTTP request in the middle of a workflow. Among them, [Message Start Event (HTTP)] and [Receive Task (HTTP)] (formerly called [Catching Message Intermediate Event (HTTP)]) can receive values in parameters of a specified format and set them in Data Items (both are available in the Professional Edition).
As of November 2024, the field name of a data item (q_field_name) is used for the name of this parameter, but in the past the data definition number (such as data[1].input) was used. Old-style parameters using data definition numbers still work, but are scheduled to be discontinued in April 2026.
This article will show you how to find and deal with deprecated old-style parameters.
Abolition of HTTP Parameters Using Data Definition Numbers
In [Message Start Event (HTTP)] and [Receive Task (HTTP)], old-style parameters using data definition numbers (data[1].input, data[2].email, etc.) will be discontinued in April 2026.
Related Documentation
- R2210: Parameters and Settings Samples for Receiving HTTP Requests
- M221: Auto Start Triggered by HTTP Request
- M226: Standing by HTTP Request
- M225: Auto Sending of HTTP Requests with Business Data Inserted
How to Find Where Obsolete Parameters Are Used
If an HTTP request using old-style parameters is received, a warning ([Warn]) will be output to the [Process Log]. This warning will allow you to identify the receiving App and Step, and you can use that information to identify the request sender.
Users with [System Administrator] privileges can search and view Process logs from [System Settings] > [Process Log]. By setting the filter conditions to [Only logs with warnings] and search, you can view only logs with warning ([Warn]). You can also narrow down the search further by adding conditions for the target App and date.
You can check the Apps that have [Message Start Event (HTTP)]/[Receive Task (HTTP)] from the [System Settings] > [App External Connectivity] > [Incoming HTTP – Message Start Event (HTTP), etc.] menu. The warning log is also output on other deprecated features, so if a large number of logs are listed, find the target App and narrow down to it.
Click the mark in the list to view the details (log message) of each log. If you are receiving logs using old-style parameters, a log message starting with [Warn] will be output in the following format:
[Warn] data[5].input has been deprecated. Use q_date5 instead.
The Process Log also records the App name and Step name, allowing you to identify the Process or automated Step that received the HTTP request.
If you do not have [System Administrator] authorization, the [App Administrator] User of each Workflow App should ask a User with [System Administrator] to check the warning log (Warn).
Alternatively, in the Administrator mode of the Process Details screen, check the [Auto-Processing Log] in the [Operation History] (requires [Process Manager] authorization).
How to Deal With Old-style Parameters
If you confirm that an HTTP request is being received with old-style parameters, change the parameter names to a format that uses field names at the source of the HTTP request.
The HTTP Request Was Received By The [Message Start Event (HTTP)]
If the sender is another Process on the same workflow platform
You can check the Process ID of the sending Process (Parent Process) on the Process Details screen of the receiving Process.
Once you have identified the Parent Process, check the Step that is sending the HTTP request on the edit screen of that App, and change the sending parameter name to the field name of the receiving Data Item.
If the sender is not on the same workflow platform
Identify the sender (mainly an external system) from the App definition, business content, etc. Once you have identified the sender, change the sending parameter name of the HTTP request to the field name.
If you are unable to identify the HTTP sender, please contact us with the following information:
・Date and time of warning log
・HTTP request URL (or a combination of HTTP reception Step type, App ID, and node ID)
The HTTP Request Was Received By A [Receive Task (HTTP)] (previously called [Catching Message Intermediate Event (HTTP)])
Identify the sender from the App definition, business content, etc. Once you have identified the sender, change the send parameter name of the HTTP request to the field name.
We apologize for the inconvenience, but for [Message Start Event (HTTP)] / [Receive Task (HTTP)] where the Warning Log [Warn] is output, please change the send parameter name at the HTTP request sender.