URL parameters

URL parameters are utilized by the flowcontext_in and flowcontext_out cards of ITX maps, and are also used for routing and authentication.

The following list provides an explanation of URL parameter information. All URL parameters have the element type URI Parameter and the data type String.

Note: Values can be specified in either the URL or in HTTP headers and are not case-sensitive. Unless otherwise specified, all values are optional. If a value is provided as both an HTTP header and a URL parameter, they must match, or an error will be returned to the customer.

username: Required if not provided in an HTTP header. The username that is used to authenticate the request
Note: The username parameter cannot be provided if the Authorization HTTP header is provided, or an error will occur.
password: Required if not provided in an HTTP header. The password that is associated with the username that is used to authenticate the request.
senderID: Required if not provided in an HTTP header. A value that identifies the sender; can be a static value per client.
receiverID: Required if not provided in an HTTP header. The shipper ID or carrier code
documentType: Required if not provided in an HTTP header. A value that identifies the type of data that is sent in the payload.
requestType: IBM implementers can use this value to determine which flow to call.
mode: Tells whether the flow is synchronous or asynchronous. Valid values are sync, async and check. A value of check indicates that the Rapid Transit POD will use a specified value for lookup, which can be configured in legacy InFlight under Rapid Transit Decision Criteria. If this property is left blank, the flow defaults to synchronous.
modeCheckField1: Indicates which header or parameter to use for the mode lookup as Text 1.
modeCheckField2: Indicates which header or parameter to use for the mode lookup as Text 2.
modeCheckField3: Indicates which header or parameter to use for the mode lookup as Text 3.
modeCheckField4: Indicates which header or parameter to use for the mode lookup as Text 4.
modeCheckField5: Indicates which header or parameter to use for the mode lookup as Text 5.
modeCheckField6: Indicates which header or parameter to use for the mode lookup as Text 6.
modeCheckField7: Indicates which header or parameter to use for the mode lookup as Text 7.
modeCheckField8: Indicates which header or parameter to use for the mode lookup as Text 8.
modeCheckField9: Indicates which header or parameter to use for the mode lookup as Text 9
Note: Each modeCheck field corresponds to the Text field of the same number on the Rapid Transit Decision Criteria screens. For example, modeCheckField1 corresponds to Text 1. If a check field is not specified (for example, if modeCheckField2 is left blank), the Rapid Transit POD looks for criteria where the text field of the same number (for example, Text 2) is empty.