Actions

After an event triggers a subscription, the subscription performs an action - such as using a webhook to send an HTTP request to an external system or sending an email.

Webhook Action

When you configure a webhook action for a subscription, you specify the HTTP method to use and the URI to send the request to. You also define the authentication type used to connect to the receiving system. You can optionally include additional HTTP headers in the request.

A webhook action can be as simple as sending a message through an application API or as powerful as calling an external API to perform an action in another system.
Important: If the receiving system resides behind a firewall, you must add all Control Hub IP addresses to the allow list for the firewall.
When you set up a webhook action, you select the HTTP request method to use. You can use the following methods in webhooks:
  • GET
  • POST
  • DELETE
  • PUT

You can include a request body or payload for a webhook action that uses a PUT, POST, and DELETE request. In the payload, you can use parameters to include information about the cause of the action, such as the text of the data SLA alert. Depending on the receiving system, the payload might not be used.

Configure webhooks as expected by the receiving system. For details on how to configure incoming webhooks, check the receiving system's documentation. You might also need to enable webhook usage within that system.

Allow Control Hub IP Addresses

Applies to: IBM StreamSets as a Service

By default, Control Hub does not directly send requests to any systems or machines in your corporate network, including deployed IBM StreamSets engines and your origin and destination systems.

However when you configure a webhook action, the Control Hub subscription directly sends the request to a system in your corporate network. If the receiving system resides behind a firewall or in a system that limits access to specific IP addresses, you must add all Control Hub IP addresses to the allow list for the firewall or system.

Control Hub instances are available in several geographic regions operated by different infrastructure providers. Some of the IP addresses in this list are not within the control of IBM StreamSets and might change. As a best practice, allow all of the following DNS names so that your account is always up to date:
  • ap01.hub.streamsets.com - 34.116.110.117
  • ap22.hub.streamsets.com
    • 13.236.218.126
    • 3.106.45.70
    • 52.62.79.52
  • ap102.hub.streamsets.com
    • 13.228.156.211
    • 18.140.180.81
    • 54.251.123.5
  • eu01.hub.streamsets.com - 34.89.186.14
  • eu02.hub.streamsets.com - 34.79.117.241
  • eu23.hub.streamsets.com
    • 3.73.29.173
    • 3.78.43.79
    • 35.159.135.221

  • eu38.hub.streamsets.com - 4.185.170.117

  • eu101.hub.streamsets.com
    • 18.195.181.255
    • 18.197.179.179
    • 63.176.120.189
  • me36.hub.streamsets.com - 4.161.35.167
  • na01.hub.streamsets.com - 34.83.161.219
  • na02.hub.streamsets.com - 35.237.50.237
  • na03.hub.streamsets.com - 34.68.170.91
  • na24.hub.streamsets.com
    • 100.24.233.125
    • 174.129.170.24
    • 3.214.238.195

  • na39.hub.streamsets.com - 52.167.173.119

  • na100.hub.streamsets.com
    • 35.174.237.103
    • 54.210.60.136
    • 98.82.83.165

Authentication Type

You configure a webhook action to use one of the following authentication types to connect to the receiving system:

None
The request does not authenticate with the receiving system.
API Key
The request includes an API key used to authenticate with the receiving system. You define the API key and value, and whether Control Hub encodes the API key and value in the request header or in the URI as query parameters.
Bearer Token
The request includes a bearer token used to authenticate with the receiving system. You define the bearer token value. Control Hub encodes the value in the request header.
Basic
The request includes a user name and password used to authenticate with the receiving system. You define the user name and password values. Control Hub encodes the values in the request header.
OAuth 2.0
The request uses the OAuth 2.0 protocol to request an access token from an HTTP service using the Client Credentials grant flow. The service returns the token to the webhook request, and then the webhook request includes the token in the request header to authenticate with the receiving system.
To configure OAuth 2.0 authentication, you define the account token URL, client ID, and client secret required to obtain the access token. You specify whether Control Hub encodes the client credentials in the request header or in the request body. You can optionally define a scope, resources, and audiences for the request.

Payload

You can use any valid content type when you define the payload. You then specify the content type in the subscription properties. When defining a payload message, be sure to consider when the subscription sends the webhook and include the information that the recipient needs.

You can use parameters in the payload to include information about the event that triggered the webhook action. For example, when configuring a webhook action that sends a text message when a job transitions to an inactive status, you might include the job name and changed job status in the message.

You can use a parameter that contains an object ID to construct URLs to the object. That way, the user receiving the message can click the URL to view the object that generated the event in the Control Hub UI.

For example, the following message includes the URL to the job that generated the event:
{
     "text":"The job {{JOB_NAME}} changed to a {{TO_STATUS}} status. \n https://cloud.streamsets.com/#/jobs/monitor/{{JOB_ID}}"
}

For more information, see Parameters.

Email Action

When you configure an email action, you specify the email recipient, a subject line and the message. In the subject line and message body, you can use parameters to include information about the cause of the action, such as the latest job status.

You can use parameters in the email subject line and body to include information about the event that triggered the action. For example, when configuring an email action when a new pipeline version has been committed, you might include the pipeline name.

For example, the following email message includes the pipeline name and version that has been committed:
Pipeline version {{PIPELINE_VERSION}} has been committed by the user {{PIPELINE_COMMITTER}} for pipeline {{PIPELINE_NAME}}.

For more information, see Parameters.