WS Connectors

Introduction

A WS Connector orchestrates multiple WS Requests into a sequential workflow. It provides a base URL, a default authenticator, and a shared context that all requests can read from and write to.

Access

Navigate to App > WS Component > Connector to access the connector list.

Configuration

WS Connector form

General Fields

Field Required Description

Name

Yes

A descriptive name for the connector.

Studio App

No

Associates the connector with a Studio App for packaging.

Default Authenticator

No

The WS Authenticator used for all requests in this connector. Authentication headers/cookies are injected automatically.

Base URL

No

The base URL prepended to all request URLs. Supports Groovy template expressions.

Request List

The Requests section defines the ordered list of requests to execute:

WS Connector request list

  • Request: Select an existing WS Request

  • Sequence: Defines the execution order. Requests are sorted by sequence number and executed sequentially.

Requests can be reordered using drag-and-drop (the list supports canMove).

Context

The Context section defines key-value pairs that form the shared execution context:

WS Connector context section

  • Key: The variable name

  • Value: The variable value

Context values are available to all requests via Groovy template expressions (${key}). Additionally, each request’s response is automatically stored in the context:

  • First request response: _1

  • Second request response: _2

  • And so on…​

This allows later requests to reference earlier responses, enabling request chaining patterns like "authenticate, then fetch data, then process result".

Request Execution

When a connector is executed, the following process occurs:

  1. Requests are sorted by sequence number

  2. For each request (in order):

    1. The callIf condition is evaluated; if false, the request is skipped

    2. The request URL is rendered with Groovy template expressions

    3. Headers are built from the request configuration

    4. For GET/DELETE: payload entries are added as query string parameters

    5. For POST/PUT/PATCH: a body entity is created based on the payload type

    6. Authentication headers/cookies are injected if an authenticator is active

    7. The HTTP call is executed via JAX-RS client

    8. The response is parsed based on media type (JSON, XML, or plain text)

    9. The response is stored in the context as _N (where N is the execution index)

    10. The repeatIf condition is evaluated; if true, the request is re-executed

Error Handling

  • If a request returns HTTP 401 (Unauthorized) and the authenticator is OAuth2, the system automatically refreshes the token and retries the request

  • Error responses are still stored in the context and can be checked by subsequent requests via callIf conditions

Testing

The connector provides a testing wizard accessible from the form view:

The testing wizard requires:

  • Connector: Select the connector to test

  • Authenticator: Select the authenticator to use

Click Call to execute the connector. The result is displayed in the $result field, showing all context variables (keys starting with _, except internal keys like _beans).

The Call button is disabled until both a connector and an authenticator are selected.

Call Tracking

When Enable track web services is enabled in the Studio application configuration, each connector execution creates a log file attached to the connector record.

The log file contains the execution details (request/response data) for debugging and auditing purposes.

When tracking is enabled, previous log files are removed before a new one is attached.