Web Client
The Web Client target writes data to an HTTP endpoint. The target sends requests to a request endpoint URL. For information about supported versions, see Supported systems and versions.
The Web Client target provides much of the same functionality as the HTTP Client target. It also provides functionality not available in the HTTP Client target. For more information, see Comparing Web Client and HTTP Client targets.
Use the Web Client target to perform a range of standard requests or use an expression to determine the request for each record.
When you configure the Web Client target, you define the request endpoint, optional headers, and method to use for the requests. You can also use a connection to configure the target.
You configure the target to generate one request for each record or to generate a single request containing all records in the batch.
You define the pagination mode and optional status response actions.
You can configure the timeout, request transfer encoding, and authentication type for both requests and responses.
You can optionally use a proxy server and configure TLS properties. You can also configure the target to use the OAuth 2 protocol to connect to an HTTP service.
Comparing Web Client and HTTP Client targets
Data Collector provides two targets that write to HTTP endpoints. The HTTP Client target was the first target. The new Web Client target includes key functionality available in the older target, as well as improvements and new features.
- The Web Client target allows you to configure different data formats for request data and response data.
- The Web Client target allows you to configure per-status and per-timeout actions.
- The HTTP Client target can be configured to use Kerberos and Universal authentication. Both targets can be configured to use Basic, Digest, OAuth 1, and OAuth 2 authentication.
HTTP method
- GET
- POST
- PUT
- PATCH
- DELETE
- HEAD
- Expression - An expression that evaluates to one of the other methods.
Expression method
The Expression method allows you to write an expression that evaluates to a standard HTTP method. Use the Expression method to generate a workflow. For example, you can use an expression that passes data to the server using the PUT method based on the data in a field.
Headers
- Security Headers
- Common Headers
You can define headers in either property. However, only security headers support using credential functions to retrieve sensitive information from supported
If you define the same header in both properties, security headers take precedence.
Grouping style
The Web Client target can generate one HTTP request for each record, or it can generate a single request containing all records in the batch.
Configure the target to generate requests in one of the following ways:
- Multiple requests per batch
- If you set the Grouping Style property to One Request per Record, the target generates one HTTP request for each record in the batch and sends multiple requests at a time. To preserve record order, the target waits until all requests for the entire batch are completed before processing the next batch.
- Single request per batch
- If you set the Grouping Style property to One Request per Batch, the target generates a single HTTP request containing all records in the batch.
Event generation
The Web Client target can generate events that you can use in an event stream. When you enable event generation, the target generates event records each time the target completes processing all available data.
- With the Email executor to send a custom email
after receiving an event.
For an example, see Sending email during flow processing.
- With a target to store event information.
For an example, see Preserving an audit trail of events.
Event records
Event records generated by the Web Client target include the following event-related record header attributes. Record header attributes are stored as String values:
| Record Header Attribute | Description |
|---|---|
| sdc.event.type | Event type. Uses one of the following types:
|
| sdc.event.version | Integer that indicates the version of the event record type. |
| sdc.event.creation_timestamp | Epoch timestamp when the stage created the event. |
The target can generate the following types of event records:
- finished
- The target generates a finished event record when the target finishes writing data to the endpoint.
- start
- The target generates a start event record when the target starts writing data to the endpoint.
Per-status actions
The Web Client target accepts only responses that include a status code that has been configured to be read as successful by the stage. When the response includes any other status code, the target generates an error and handles the record based on the error record handling configured for the stage.
You can configure the target to perform one of several actions when it encounters an unsuccessful status code.
- Retry with constant backoff
- Retry with linear backoff
- Retry with exponential backoff
- Generate output record
- Generate error record
- Abort flow
When defining the retry with a constant, linear, or exponential backoff action, you also specify the backoff interval to wait in milliseconds. When defining any of the retry actions, you specify the maximum number of retries and a status failure response. If the stage receives a successful status code during a retry, then it processes the response. If the stage doesn't receive a successful status code after the maximum number of retries, then the stage performs the specified status failure action. You can only specify a status failure action for a retry action.
You can add multiple status codes and configure a specific action for each code.
Per-timeout actions
By default, the Web Client target retries an operation five times before generating an error. You can configure the stage to use different timeout criteria and perform one of several actions when a specific type of timeout has reached its configured timeout limit.
- Retry with constant backoff
- Retry with linear backoff
- Retry with exponential backoff
- Generate output record
- Generate error record
- Abort flow
When defining the retry with a constant, linear, or exponential backoff action, you also specify the backoff interval to wait in milliseconds. When defining any of the retry actions, you specify the maximum number of retries and timeout failure action. If the stage receives a response during a retry, then it processes the response. If the stage doesn't receive a response after the maximum number of retries, then the stage performs the specified timeout failure action.
You can add multiple timeout types and specify timeout criteria and actions for each of them.
Pagination
The Web Client target can use pagination to retrieve a large volume of data from a paginated API.
When configuring the Web Client target to use pagination, use the pagination type supported by the API of the HTTP client. You will likely need to consult the documentation for the source system API to determine the pagination type to use and the properties to set.
The Web Client target supports the following common pagination types:
- Link in Header
- After processing the current page, the stage uses the link in the
HTTP header to access the next page. The link in the header can
be an absolute URL or a URL relative to the next page link base
URL configured for the stage. For example, let's say you
configure the following next page link base URL for the
stage:
https://myapp.com/api/objects?page=1 - Link in Body
- After processing the current page, the stage uses the link in a
field in the response body to access the next page. The link in
the response field can be an absolute URL or a URL relative to
the next page link base URL configured for the stage. For
example, let's say you configure the following next page link
base URL for the
stage:
http://myapp.com/api/tickets.json?start_time=138301982 - Page
- The stage begins processing with the specified initial page, and
then requests the following page. Use the
${startAt}variable in the resource URL as the value of the page number to request. You can optionally set a final page or offset for the stage to stop reading data. - Offset
- The stage begins processing with the specified initial offset, and
then requests the following offset. Use the
${startAt}variable in the resource URL as the value of the offset number to request.
Page or offset number
When using page or offset pagination, the API of the HTTP client typically requires that you include a page or offset parameter at the end of the response endpoint URL. The parameter determines the next page or offset of data to request.
The name of the parameter used by the API varies. For example, it
might be offset, page, start, or
since. Consult the documentation for the source system API to
determine the name of the page or offset parameter.
The Web Client target provides a ${startAt} variable that you can
use in the URL as the value of the page or offset. For example, your resource URL might
be any of the following:
http://webservice/object?limit=15&offset=${startAt}https://myapp.com/product?limit=5&since=${startAt}https://myotherapp.com/api/v1/products?page=${startAt}
When the flow starts, the Web Client stage
uses the value of the Initial Page or Initial
Offset property as the ${startAt} variable
value. After the stage reads a page of results, the stage increments the
${startAt} variable by one if using page pagination, or by
the number of records read from the page if using offset pagination.
Example
https://myapp.com/product?limit=5&since=${startAt}https://myapp.com/product?limit=5&since=0${startAt} variable
by 5, such that the next response endpoint is resolved
to:https://myapp.com/product?limit=5&since=5The second page of results also includes 5 items, starting at the 5th item.
OAuth 2 authentication
- OAuth 2 client credentials
- OAuth 2 access token
- OAuth 2 owner credentials
The OAuth 2 protocol authorizes third-party access to HTTP service resources without sharing credentials. The Web Client target uses credentials to request an access token from the service. The service returns the token to the target, and then the target includes the token in a header in each request to the request endpoint.
- Client credentials grant
- The stage sends its own credentials - such as the client ID and client secret, or the basic or digest authentication credentials - to the HTTP service. For example, use the client credentials grant to process data from the Twitter API or from the Microsoft Azure Active Directory (Azure AD) API.
- Access token grant
- The stage sends an access token to an authorization service and obtains an access token for the HTTP service. You can specify the details to use in the access token request, such as token headers and claims, and a signing algorithm and key. When using Data Collector 7.2 and later, if you specify a signing key, it must be Base64-encoded.
- Owner credentials grant
- The stage sends the credentials for the resource owner - such as the resource owner user name, password, client ID, and client secret - to the HTTP service. Or, you can use this grant type to migrate existing clients using basic or digest authentication to OAuth 2 by converting the stored credentials to an access token.
Data formats
The Web Client target writes data to HTTP endpoints based on the data format that you select.
The Web Client target processes data formats as follows:
- Avro
- The stage writes records based on the Avro schema. You can use one of the following methods to specify the location of the Avro schema definition:
- Binary
- The stage writes binary data to a single field in the record.
- Delimited
- The target writes records as delimited data. When you use this data format, the root field must be list or list-map.
- JSON
- The target writes records as JSON data. You can use one of
the following formats:
- Array - Each file includes a single array. In the array, each element is a JSON representation of each record.
- Multiple objects - Each file includes multiple JSON objects. Each object is a JSON representation of a record.
- Protobuf
- Writes one record in a message. Uses the user-defined message type and the definition of the message type in the descriptor file to generate the message.
- Text
- The target writes data from a single text field to the target system. When you configure the stage, you select the field to use.
- XML
- The target creates a valid XML document for each
record. The target requires the record to have a single root field that contains the
rest of the record data. For details and suggestions for how to accomplish this, see Record structure requirement.
The target can include indentation to produce human-readable documents. It can also validate that the generated XML conforms to the specified schema definition. Records with invalid schemas are handled based on the error handling that is configured for the target.