Step 1 - Create profile and customise configurations

First, create an additional profile that builds a JSON request in the mapping that is transferred to the profile from the previous example:

• Give the profile a meaningful name, e.g. Lobster_Tutorial_HTTP_calculator_call_json.

• Set the mapping type to Data Routing.

• In phase 1 we use the time-driven Input Agent Custom class → DummyDataCron.

Note: The time-driven Input Agent Custom class → DummyDataCron is a fast and uncomplicated way to start a profile manually without expecting specific input data. In contrast to the event-based Input Agent Manual upload, you do not need to pass a test file.

Step 2 - Mapping

In phase 3, the following structure is expected:

• New node RequestNode in target structure.

• Node properties Maximum and Minimum = 1 (thus this node is not displayed as an array).

• Target node property XML/JSON handling = Transparent (prevents the name of the top node from being displayed).

• Create three fields with the names

  • OP1 with fixed value 42 and data type Integer.

  • OP2 with fixed value 24 and data type Integer.

  • OPR with fixed value + and data type String.

Step 3 - Prepare output file

In phase 5, the ExtendedJsonCreationUnit is used to create a valid JSON. The default settings are sufficient for this case, you only need to specify the parameter Start at node, which in our case is RequestNode.

Step 5 - Create output file

The generated JSON is output and sent via phase 6 in a Response of type "HTTP". Store the destination address, credentials, etc. in the Response or select a suitable partner channel.

• Target computer expects the actual address of the remote system (DNS name or IP address; the protocol addition http: or https: can be omitted).

• If you have a DMZ server in use, activate the option Via DMZ.

• You only need to specify the port here if no default value is used on the remote system (HTTP - port 80 and HTTPS - port 443).

• User or password must be filled in if access control is available.

• HTTP URI requires the specification of the actual resource on the target system, e.g. /dw/Request/calculator_json_body.

• If an HTTP header is to be sent, any header can be specified with the exception of Content-Length.

• HTTP method: POST

• In the Query/Body field you can specify additional query parameters. In the case of multipart calls, also the identifier for the subsection.

• The MIME-Type field is particularly interesting for methods such as POST, PUT and PATCH, as you use it to tell the receiving server which 'document type' was used for transmission.

• To check the response of the remote system, the field Expected response is available.

• Further options can be set for the TLS connection, web service and multipart calls or the encoding for variables.

Important note: You must always set the option Use SSL if the destination address expects HTTPS. It is not sufficient to specify port 443 or to set https://.... for the target system. If the target system can only use HTTPS and the option is not active, an error will certainly occur.

Normally, the run of the profile is finished with the completion of phase 6. In the case of HTTP, however, a response is always returned when a target system is called.

With the option Pass on HTTP response as message in phase 6 of the "HTTP" Response, you can forward the response from the server to a subsequent profile. In this way, for example, status or error messages of the call can be deliberately evaluated.

In the Response, set the content settings to "Output of IU" and the encoding to "UTF-8". Save the profile and start it via "Restart → Start Cron". In the Control Center, check the profile job and the data.

Note: You should always create an additional, simple profile that can record the error responses of an "HTTP" Response. This makes any analysis much easier if an error does occur. Furthermore, such a profile is also very helpful if you implement a new Response for HTTP. You do not have to define a separate error profile for each Response, but you can use a single profile as a collection point for error messages, so to speak. Such a profile only needs a meaningful name in the main settings (e.g. HTTP_ERR_COLLECTOR). In phase 1, the Input Agent of type Message is expected. Mapping is not relevant.

To better check a successful transmission, it is helpful to activate a detailed logging for the "HTTP" Response. In the Control Center (→ "Logs/Configuration/Profile Logging"), navigate to the desired profile and activate the options "Trace" and "HTTP" for phase 6.