| Panel | |
|---|---|
|
Disclaimer
...
| Template Name | Extension Name | Extension Version |
|---|---|---|
| Web Service Integration | ue-webservice | 1.3.1 |
...
Requirements
This integration requires a Universal Agent and a Python runtime to execute the Universal Task.
Software Requirements for Universal Template and Universal Task
Requires Python 3.7.0 or higher. Tested with the Universal Agent bundled Python distribution (version 3.7.6)
Software Requirements for Universal Agent
...
Field | Input type | Default value | Type | Description |
|---|---|---|---|---|
Protocol | Required | HTTP(S)/REST | Choice | The communication protocol to be used towards the foreign API. |
HTTP Version | Required | 1.1 | Choice | The Hypertext Transfer Protocol version. |
Authorization Type | Required | Basic | Choice | The authorization type to be used for communicating with the foreign API. The following options are available.
|
Credentials | Optional | - | Credentials | Credentials for "Basic" Authorization Type. The Credentials definition should be as follows.
Required when Authorization Type is "Basic". |
API Key Introduced in version 1.3.0 | Optional | - | Credentials | Credentials for “API Key” Authorization Type. API Key should either be stored as the “Password” or “Token” Credential attribute, during Credential definition. Required when Authorization Type is “API Key”. |
Grant Type Introduced in version 1.3.0 | Optional | Client Credentials | Choice | The OAuth 2.0 Grant Type used to get the token. Supported Grant Types are the following.
Required when Authorization Type is "OAuth 2.0". |
Access Token URL Introduced in version 1.3.0 | Optional | Text | The endpoint of the Authentication Server for the retrieval of access token. It is used to exchange the Client Credentials (and the Resource Owner Credentials in the case of "Password Credentials" Grant Type) for an access token. Required when Authorization Type is "OAuth 2.0". | |
Scope Introduced in version 1.3.0 | Optional | - | Text | A space-separated list of scopes used during retrieval of an OAuth 2.0 access token. Required when Authorization Type is "OAuth 2.0". |
Client Credentials Introduced in version 1.3.0 | Optional | - | Credentials | Used for retrieval of OAuth 2.0 access token. The Credential definition should be as follows.
Required when Authorization Type is "OAuth 2.0". |
Resource Owner Credentials Introduced in version 1.3.0 | Optional | - | Credentials | Used for retrieval of OAuth 2.0 access token. The Credential definition should be as follows.
Required when Grant Type is "Password Credentials". |
Client Authentication Introduced in version 1.3.0 | Optional | Send Client Credentials in Body | Choice | Controls whether the Client Credentials are sent in the request body or as a basic authentication header during retrieval of OAuth 2.0 access token. The following options are available.
Required when Authorization Type is "OAuth 2.0". |
Token | Optional | - | Large Text | The authentication access token. Required when Authorization Type is "Token". |
Add Authorization Data To | Optional | Request Header | Choice | Specifies where to include the Token in the request. The following options are available.
Required when Authorization Type is "Token" or "OAuth2.0". |
Authorization Header Prefix | Optional | Bearer | Text | The prefix for the Token. The token value is appended to the Authorization Header Prefix in the request Authorization header. For example: Bearer <token_value>. Required when Add Authorization Data To is "Request Header". |
Additional Credentials Introduced in version 1.3.0 | Optional | - | Credentials | Additional credentials that might be required to be used either as Query Parameters or as HTTP Headers. For more information on how to pass credentials as part of URL Query Parameters refer to "Passing Credentials as Query Parameters, Headers, or as Headers"Form Data. |
URL | Required | - | Text | The URL to be called. |
HTTP Method | Required | GET | Choice | The HTTP method to be used in the request. The following options are available.
|
Timeout | Optional | - | Integer | The time (in seconds) that the request will wait for the server to send data before closing the connection. If Timeout is not filled, the request will wait (hang) until the connection is closed. |
URL Query Parameters | Optional | - | Array | The list of parameters key/value pairs to be sent in the query string for the request. |
Payload Type | Optional | Raw | Choice | The type of data to be sent in the request body. The following options are available.
Required when HTTP Method is "POST", "PUT" or "PATCH". |
Payload Source | Optional | Form | Choice | For Payload Type of value "Raw", it specifies how the payload will be provided. The following options are available.
Required when Payload Type is "Raw". |
MIME Type | Optional | application/json | Choice | The MIME type to be used in the request's header. The following options are available.
Required when Payload Type is "Raw". |
Other Value For MIME Type | Optional | - | Text | The MIME type to be included in request's header in case "Other" is selected as MIME Type value. Required when MIME Type is "Other". |
Form Data | Optional | - | Array | The list of parameters key/value pairs to be sent in the request body. The request header will include ""x-www-form-urlencoded" as a "Content-Type" in this case. |
Payload | Optional | - | Large Text | The payload to be sent in the request body. Required when Payload Source is "Form". |
Payload Script | Optional | - | Script | The script to be used as a payload source. Required when Payload Source is "Script". |
HTTP Headers | Optional | - | Array | The list of HTTP Headers key/value pairs to be sent with the request. If "Content-Type" header is provided, it will be disregarded by the extension, as the MIME Type field is used for this purpose. |
Proxies (Deprecated) Deprecated in version 1.4.0 | Optional | - | Text | The proxy servers to be used, in the format of values separated by comma. For example: http://ip1:port1,ftp://ip2:port2 |
SSL Options | Required | False | Boolean | Displays the available SSL options. |
| SSL field is deprecated. For backward compatibility reasons, the field is kept and functioning as of version 1.3.1. However, it is strongly advised to migrate the task definition to the new logic to avoid disruptions in the future. For more information refer to Set Proxies with Environment Variables and Known Issues. | ||||
SSL Options | Required | False | Boolean | Displays the available SSL options. |
SSL Certificate Verification | Optional | True | Boolean | Enables certificate verification. Certificate verification is auto-enabled in case field "CA Bundle Path" field is populated. Required when SSL Options is checked. |
CA Bundle Path | Optional | - | Text | Path and file name of the Certificate Authority bundle to use in certificate verification. The file should be in PEM format. |
Client Private Key Path | Optional | - | Text | Path and file name of the private key file for SSL client-side authentication. The file must be in PEM format. |
Client Certificate Path | Optional | - | Text | Path and file name of the public key certificate for SSL client-side authentication. The file must be in PEM format. |
Print Result Body To
| Optional | STDOUT | Choice | Specifies where to print the web service output payload. The following options are applicable.
|
Process Exit Code Mapping
| Required | False | Boolean | The flag that determines whether exit code mapping is enabled or not. |
Path Expression
| Optional | - | Choice | Field visible only when Process Exit Code Mapping is checked and it is required when visible. The JSON path that which is used to check the provided patterns that are set up on the Response Exit Code Mapping array. |
Response Exit Code Mapping
| Optional | - | Array | Field visible only when Process Exit Code Mapping is checked and it is required when visible. An array that maps regular expression patterns to exit codes. Provided exit codes should be in the range [100-255]. |
...
Certifi provides a wide range of certificates signed by well-known Certificate Authorities, used for SSL Server verification.
Related Universal Task fields:
- SSL Options: enabledEnabled
- SSL Certificate Verification: enabledEnabled
Server SSL verification by custom CA
For SSL Server verification against hosts that have certificates signed by a custom Certificate Authority, certificates bundled with_certifi_ library shall not be enough. In such cases, the custom certificate a Certificate Authority Bundle should be provided as input.
Related Universal Task fields:
- SSL Options: enabledEnabled
- SSL Certificate Verification: enabledEnabled
- CA Bundle Path: populatedPopulated
Server and Client SSL verification
Additional An additional security layer can be achieved with two-way SSL verification, where both the Server is verified by the Client, and the Client is verified by the Server. This scenario is common for hosts with self-signed certificate, however it can be used to any SSL Client verification.
Related Universal Task .
Related Universal Task fields:
- SSL Options: enabledEnabled
- SSL Certificate Verification: enabledEnabled
- CA Bundle Path: populatedPopulated
- Client Certificate Path: populatedPopulated
- Client Private Key Path: populatedPopulated
| Info |
|---|
For HTTPS provided URL and disabled SSL Options, the established connection will still be secured over SSL protocol, however SSL certificate verification is not done.When the communication between the client and the server is based on HTTPS and SSL Certificate Verification is not enabled, communication is still encrypted. However, certificates are not verified. An appropriate warning is printed on the STDERR output |
Exit Code Mapping
As part of task configuration, it is possible for the user to define custom exit codes that depend on the contents of the web service response body.
...
When retry needs to be configured, based on the content of the web service response body. Task retry can be configured based on the exit code.
For example, a user can configure the Universal Controller task to retry execution when Exit the exit code is X. Exit code X can be configured by the user when the web service response payload field JSON "document.status" is equal to value "Under Processing".
...
Process Exit Code Mapping
Should be checked to enable this functionality.Path Expression
The JSONPath expression (JSONPath Syntax).Response Exit Code Mapping
A list of pairs (Pattern/Exit Code). If the pattern provided as python regular expression is matched, then the configured Exit Code exit code will be applied.
The web service output JSON body is parsed with the Path Expression. The matched response body content , is evaluated against the list of patterns provided on Response Exit code Mapping array. When a pattern is matched, the extension will return the respective Exit Codeexit code.
The following features and restrictions are applied.
It is possible to provide multiple pairs of Pattern/Exit Code. The extension will return the corresponding Exit Codeexit code, on the first match in the array.
Provide
.*as a pattern, to match any value returned by the JSONPath.Provided exit codes should be between 100 and 255.
An error will be raised in case:
No match found.
A Wrong Path Expression is provided.
The result body is not of type JSON.
The custom exit codes that intent intend to be considered successful, they have to be configured during appropriately in the Result Processing Details section.
Exit Code Processing
Option "Success Exit Code Range" to be selected in this field.Exit Codes
To be filled with the list of exit codes that the user expects to result success task reflect successful execution (Ranges can be provided. For example : 0,100-255).
Passing Credentials as Query Parameters, Headers, or as
...
Form Data
There are cases where the End Point endpoint might require credentials to be passed either as part of Query Parameters or , as Headers . This is typical for cases where API key is used, or in cases where the End Point might require thisor in a URL-encoded form. For example, Mulesoft APIs can include Client ID Enforcement Policy for which a Client ID and a Client Secret are mandatory to be passed on top of other authorization/authentication inputs.
Additional Query Parameters can be passed through URL Query Parameters field and through the "URL Query Parameters" field, additional HTTP Headers can be passed through HTTP Headers field. Both the "HTTP Headers" field and form data can be passed through the "Form Data" field. All of them are Array fields. Array "Name" represents the Query Parameter Name or , the Header Name, or the Form Data Key, and "Value" represents the value to be used. “Value” could be a specific string, or be in the format of [credential_name].attribute where
...
Example: Let's suppose that a credential with name = "valid_credential_name" and password = "example_pass" is passed to a task. The expression [valid_credential_name].password will be resolved to example_pass.
Task Examples
No Authorization Task Configuration
Example of Universal Task for "None" Authorization Type.
Basic Authorization Task Configuration
Example of Universal Task for "Basic" Authorization Type.
Token Authorization Task Configuration
Example of Universal Task for "Token" Authorization Type.
API Key Authorization Task Configuration
Example of Universal Task for "API Key" Authorization Type.
To see how to pass the API Key as HTTP Header refer to "Passing Credentials as Query Parameters or as Headers".
...
| Anchor | ||||
|---|---|---|---|---|
|
Set Proxies with Environment Variables
If a proxy is required to route the traffic between the Universal Task and the configured endpoint, then HTTP_PROXY and/or HTTPS_PROXY environment variables need to be set. HTTP_PROXY environment variable defines the proxy used in case of HTTP communication between the Universal Task and the endpoint, while the HTTPS_PROXY environment variable defines the proxy used in case of HTTPS communication between the Universal Task and the endpoint. In the majority of cases, only one proxy is used that routes both HTTP and HTTPS traffic (in such cases HTTP_PROXY/HTTPS_PROXY environment variables point to the same value).
The format is explained by the following examples.
Passing a single proxy for HTTP and HTTPS traffic
Passing different proxies with credentials for HTTP and HTTPS traffic
Task Examples
No Authorization With Exit Code Mapping Task Configuration
Example of Universal Task for "OAuth2.0None" Authorization Type with client credentials grant type.
To see how to pass credential fields as HTTP Headers refer to "Passing Credentials as Query Parameters or as Headers".
Example of Universal Task for "OAuth2.0" Authorization Type with password credentials grant type.
Task Configuration for SSL Protocol
Example of Universal Task for SSL Options checked.
Task Configuration for a POST request with JSON payload and use of proxy server
Example of Universal Task for SSL Options checked.
where the user expects an exit code equal to "101" if the employee's first name is "John".
Task Inputs for Result Processing Details:
Here the Exit Codes field is filled with two elements, "0" and the range [100-255] where the expected exit code "101" falls in.
Task Results:
Printing Result Body to STDOUT
Example showing the result body of the web service printed to STDOUT.
Response Code Output Field
Example showing the value of the output field "Response Code" filled with the actual response code from web service result.
Task Configuration for Exit Code Mapping Scenario
The following example scenario describes the configuration of a task where the user expects an exit code equal to "150" if the employee is "Tiger Nixon".
- Task inputs for Web Service Integration Details.
- Task Inputs for Result Processing Details:
Here the Exit Codes field is filled with two elements, "0" and the range [100-255] where the expected exit code ("150") falls in.
- Task Results:
Mulesoft Example
The following example shows the configuration of a task for a call to a Mulesoft API that has OpenID Connect access token enforcement and Client ID Enforcement policies enabled and when Okta is used as a Client Provider. OAuth2 Client Credentials flow is used in the following example.
Task Configuration
As it's 
Basic Authorization Task Configuration for a POST request with JSON payload
Example of Universal Task for "Basic" Authorization Type.
Token Authorization Task Configuration with URL Query parameters
Example of Universal Task for "Token" Authorization Type with URL Query parameters.
API Key Authorization Task Configuration
Example of Universal Task for "API Key" Authorization Type.
To see how to pass the API Key as HTTP Header refer to Passing Credentials as Query Parameters, Headers, or as Form Data.
OAuth2.0 Authorization Task Configuration
Example of Universal Task for "OAuth2.0" Authorization Type with client credentials grant type.
To see how to pass credential fields as HTTP Headers refer to Passing Credentials as Query Parameters, Headers, or as Form Data.
Example of Universal Task for "OAuth2.0" Authorization Type with password credentials grant type.
Task Configuration with SSL Client Authentication
Example of a Universal Task with SSL Client Authentication.
Mulesoft Example
The following example shows the configuration of a task for a call to a Mulesoft API that has OpenID Connect access token enforcement and Client ID Enforcement policies enabled and when Okta is used as a Client Provider. OAuth2 Client Credentials flow is used in the following example.
Task Configuration
As it's evident from the Client ID enforcement configuration, Client Credentials are also passed as HTTP Headers.
Task Output
...
To see how to pass the client credentials as HTTP Headers refer to Passing Credentials as Query Parameters, Headers, or as Form Data.
Task Output
Output Only Fields
Field | Type | Description |
|---|---|---|
Response Code | Text | The web service response code. |
...
- Python code modifications should not be done.
- Template Modifications
- General Section
- "Name", "Extension", "Variable Prefix", "Icon" should not be changed.
- Universal Template Details Section
- "Template Type", "Agent Type", "Send Extension Variables", "Always Cancel on Force Finish" should not be changed.
- Fields Restriction Section
The setup of the template does not impose any restrictions, However with respect to "Exit Code Processing Fields" section.- Success/Failure exit codes need to be respected.
- In principle, as STDERR and STDOUT outputs can change in follow-up releases of this integration, they should not be considered as a reliable source for determining success or failure of a task.
- General Section
Users and customers are encouraged to report defects or feature requests at Stonebranch Support Desk.
...
Changelog
- or failure of a task.
Users and customers are encouraged to report defects or feature requests at Stonebranch Support Desk.
| Anchor | ||||
|---|---|---|---|---|
|
Known Issues
- The "proxies" field does not work correctly in some cases. Task authors are advised to use HTTP_PROXY and HTTPS_PROXY environment variables on task definition, or alternatively set those variables on the runtime user environment, leaving this field empty. For more information refer to Set Proxies with Environment Variables.
| Anchor | ||||
|---|---|---|---|---|
|
Changelog
ue-webservice 1.4.0 (2023-07-26)
Deprecations and Breaking Changes
Deprecated: "Proxies" field is deprecated. For backward compatibility reasons, the field is kept and functioning as of version 1.3.1. However, it is strongly advised to migrate the task definition to the new logic to avoid disruptions in the future. For more information refer to Set Proxies with Environment Variables and Known Issues. (#33623)
Enhancements
Added: Support for passing additional credential information in URL-Encoded Form (#33612)
ue-webservice 1.3.1 (2023-04-28)
...
ue-webservice 1.3.0 (2023-03-23)
Enhancements
Added: Support for API Keys (#31456)Added: Support for retrieving OAuth 2.0 token using "Password Credentials" or "Client Credentials" grant and calling a Web Service within the same task (#31479)Added: Support for passing additional credential information as Query Parameters or as Headers (#31478)
ue-webservice 1.2.1 (2022-12-22)
Enhancements
Changed: The following Input Field Labels are improved to bring more context on the surrounding functionality (#31203):- Choice OAuth2Token in Authorization Type renamed to: Token
- Optional text field OAuthToken renamed to: Token
- Checkbox field Use SSL renamed to: SSL Options
- Checkbox field SSL Hostname Check renamed to: SSL Certificate Verification
- Optional text field Trusted Certificate File renamed to: CA Bundle Path
- Optional text field Public Key Certificate renamed to: Client Certificate Path
- Optional text field Private Key Certificate renamed to: Client Private Key Path
Changed: Payload input field is not mandatory anymore (#30639)
Up to ue-webservice-1.2.0, input field Payload was mandatory for HTTP Methods POST, PUT, PATCH. Starting from ue-webservice-version 1.2.1 it is not necessary to provide data payload.
...
Fixed: Field Pattern in Response Exit Code Mapping table is now evaluated as python regular expression, instead of a literal string (#31224)Fixed: Parse properly the JSON response when this is a list of objects (#30966)
ue-webservice 1.2.0 (2022-06-23)
Deprecations and Breaking Changes
Deprecated: "Print Result Body to" STDOUT functionality is intended to be used only for informational purposes. Users authoring workflows which that read STDOUT from tasks originating from this Universal Template , are encouraged to read this retrieve information from EXTENSION_OUTPUT instead of STDOUT to avoid disruptions. In future releases, the Response Body will be part only of EXTENSION_OUTPUT. (#28541)
Enhancements
Added: JSON body response formatted and printed in the Extension Output in new JSON attribute 'body_json' (#28541)
...
ue-webservice 1.1.0 (2022-03-10)
Enhancements
Added: Exit Code Mapping (#27233)Added: Print Response status on output only field (#26782)Added: Print Response Body in STDOUT (#26766)
...