HTTP Request

This action sends data to the destination Web server using the selected HTTP method. HTTP and HTTPS URI schemes are allowed.

HTTP works as a request-response protocol in client-server computing model. In this action, Loftware acts as a client that communicates with a remote server. This action submits a selected HTTP request message to a server. The server returns a response message, which can contain completion status information about the request and may also contain requested content in its body.

About group identifies the selected action.

Name: allows you to define a custom action name. This makes actions easily recognizable on the solution's list of actions. By default, the action name is taken from its type.
Description: custom information about the action. Enter a description to explain the purpose and role of action in a solution.
Action type: read-only information about the selected action type.

Connection Settings group sets connection parameters.

	Note
	This action supports Internet Protocol version 6 (IPv6).

Destination: address, port and destination (path) of the Web server.

	Tip
	If a Web server runs on default port 80, skip the port number. Hard-code the connection parameters and use a fixed host name or IP address. Use a variable value to define this option dynamically. For more information, see section Using Compound Values in Loftware Automation user guide.

Example 75. Example

If the variable hostname provides the Web server name and the variable port provides the port number, you can enter the following for the destination:

[hostname]:[port]

Request method: available request methods.
Timeout: timeout duration (in ms) during which the server connection should be established and response received.

Save status reply in a variable: variable to store the status code received from the server.

	Tip
	Status code in range 2XX is a success code. Common "OK" response is code 200. Codes 5XX are server errors.

Save data reply in a variable: variable to store the data received from the server.

Authentication group enables you to secure the Web server connection.

Enable basic authentication: allows you to enter the required credentials to connect to the Web server. User name and password can either be fixed or provided using a variable.

	Note
	HTTP Basic authentication (BA) uses static standard HTTP headers. The BA mechanism provides no confidentiality protection for the transmitted credentials. They are merely encoded with Base64 in transit, but are not encrypted or hashed in any way. Basic Authentication should be used over HTTPS.

Show password: unmasks the password characters.

Note

HTTP Request action is executed on Web Printing Server and not on the Web Printing Client.

If you use HTTP Request action in LoftwareWeb Client and you want to execute locally (bypassing the Web Printing Server), add the prefix "LOCAL_" to your action name.

Content group defines the contents to be sent to a Web server.

Data: content to be sent outbound. Fixed content, mix of fixed and variable content, or variable content alone are permitted. To enter variable content, click the button with arrow to the right of data area and insert variable from the list. For more information, see section Combining Values in an Object in Loftware user guide.

Encoding: encoding type for the sent data.

	Tip
	Auto defines the encoding automatically. If needed, select the preferred encoding type from the drop-down list.

Type: Content-Type property of the HTTP message. If no type is selected, the default application/x-www-form-urlencoded is used. If an appropriate type is not listed, define a custom one or set a variable that would define it dynamically.

Additional HTTP Headers are requested by certain HTTP servers (especially for REST services).

Note

HTTP Request action already uses a built-in subscription key, so you don't need to enter Ocp-Apim-Subscription-Key value in Additional HTTP Headers.

You must provide Ocp-Apim-Subscription-Key value if you make a call to Cloud API from non-Loftware application.

Additional headers: hard coded headers or headers obtained from variable values. To access the variables, click the small arrow button to the right hand side of the text area. For more information, see section Combining Values in an Object in Loftware user guide.

Certain HTTP servers (especially for REST services) require custom HTTP headers to be included in the message. This section allows you to provide the required HTTP header.

HTTP headers must be entered using the following syntax:

header field name: header field value

For example, to use the header field names Accept, User-Agent and Content-Type, you could use the following syntax:

Accept: application/json; charset=utf-8
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
Content-Type: application/json; charset=UTF-8

You can hard code the header field names, or you can obtain their values from trigger variables. Use as many custom header fields as you want, just make sure that each header field is placed in a new line.

	Note
	The entered HTTP headers override the already defined headers elsewhere in the action properties, such as Content-Type.

Action Execution and Error Handling

Each action can be set as a conditional action. Conditional actions only run when the defined conditions allow them to be run. To define these conditions, click Show execution and error handling options.

Execution options are:

Enabled: specifies if the action is enabled or disabled. Only enabled actions will execute. This functionality may be used while testing a form.
Condition: defines one-line programming expression that must provide a Boolean value (true or false). When the result of the expression is true, the action will execute. Condition offers a way to avoid executing actions every time.

Error handling options are:

Ignore failure: specifies whether an error should be ignored or not. With Ignore failure option enabled, the execution of actions continues even if the current action fails.

	Note
	Nested actions that depend on the current action do not execute in case of a failure. The execution of actions continues with the next action on the same level as the current action. The error is logged but does not break the execution of the action.

Example 76. Example

At the end of printing, you might want to send the status update to an external application using HTTP Request action. If the printing action fails, action processing stops. In order to execute the reporting even after the failed print action, the Print Label action must have the option Ignore failure enabled.

Save error to variable: allows you to select or create a variable to save the error to. The same cause of the error is also saved to internal variables ActionLastErrorId and ActionLastErrorDesc.