Parameters

When using parameters to define advanced expressions for event conditions, you can use them with functions in the IBM StreamSets expression language or by themselves. For example:

${str:contains(FROM_STATUS, "ACTIVE")}
${PIPELINE_NAME=='test'}

You can use the following general parameters for any event type:

• ORGANIZATION - The organization name that the triggered subscription belongs to.
• SUBCRIPTION_ID - The subscription ID.
• SUBSCRIPTION_NAME - The subscription name.
• TRIGGERED_COUNT - The number of times the subscription has been triggered.
• TRIGGERED_ON - The time that the subscription was triggered.

For example, if you configure a subscription to send a webhook when a job status changes, you might use the following message in the JSON request payload:

{  
   "text":"A job status change occurred on {{TRIGGERED_ON}}."
}

You can use the following parameters for a triggered data SLA:

• SLA_ID - The data SLA ID.
• SLA_LABEL - The data SLA label.
• ALERT_TEXT - The text configured for the data SLA alert.
• ALERT_VALUE - The threshold value that triggered the data SLA alert.

For example, if you configure a subscription to send a webhook each time a data SLA alert triggers, you might use the following message in the JSON request payload:

{  
   "text":"{{ALERT_TEXT}}: Alert {{SLA_LABEL}} was triggered by {{ALERT_VALUE}}."
}

Or, you can filter triggered data SLA events to a specific ID:

${SLA_ID=='5723e6'}

You can use the following parameters for an engine that stops responding:

• SDC_ID - The execution engine ID.
  Note: Displays as Engine ID in the UI when you define a simple condition for the event.
• HTTP_URL - The execution engine URL.
• LAST_REPORTED_TIME - The epoch or Unix time in milliseconds that the execution engine last sent a heartbeat to Control Hub.

For example, if you configure a subscription to send an email each time a Data Collector stops responding, you might use the following message in the email body:

The Data Collector with ID {{SDC_ID}} and URL {{HTTP_URL}} has stopped responding since {{LAST_REPORTED_TIME}}.

Or, you can filter an event to only include execution engines that have stopped responding since a specified epoch or Unix time:

${LAST_REPORTED_TIME>1539734400}

You can use the following parameters for a job status change event:

• JOB_ID - The job ID.
• JOB_NAME - The job name.
• JOB_OWNER - The email address of the job owner.
• JOB_TAG - The tag added to the job.
  Note: Jobs can have multiple tags. When a job has a single tag, you can define a simple event condition using the JOB_TAG parameter. When a job has multiple tags, you must define an advanced expression for the event condition.
• ERROR_MESSAGE - The error message associated with the job status change.
• FROM_STATUS - The status that the job changed from. Valid values are ACTIVATING, ACTIVATION_ERROR, ACTIVE, DEACTIVATING, INACTIVE, or INACTIVE_ERROR.
• TO_STATUS - The status that the job changed to. Valid values are ACTIVATING, ACTIVATION_ERROR, ACTIVE, DEACTIVATING, INACTIVE, or INACTIVE_ERROR.
• FROM_COLOR - The color that the job status changed from. Valid values are GRAY, GREEN, or RED.
• TO_COLOR - The color that the job status changed to. Valid values are GRAY, GREEN, or RED.

For example, if you configure a subscription to send a webhook when a job status changes, you might use the following multi-line message in the JSON request payload:

{  
   "text":"The job {{JOB_NAME}} changed status. \nFrom {{FROM_COLOR}} {{FROM_STATUS}} to {{TO_COLOR}} {{TO_STATUS}}."
}

If you configure a subscription to send an email when a job status changes, you might set the recipient to the job owner:

{{JOB_OWNER}}

Or, you can filter job status change events when they change to a status of inactive:

${str:contains(TO_STATUS, "INACTIVE")}

You can use the following parameters for a maximum global failover retries exhausted event:

• ERROR_MESSAGE - The error message that occurs when the job reaches the maximum number of pipeline failover retries.
• JOB_ID - The job ID.
• JOB_NAME - The job name.
• JOB_OWNER - The email address of the job owner.
• MAX_RETRIES - The number of failover retries.

For example, if you configure a subscription to send a webhook when a job reaches the maximum number of pipeline failover retries across all available engines, you might use the following message in the JSON request payload:

{  
   "text":"The job {{JOB_NAME}} has reached the maximum global failover retries of {{MAX_RETRIES}}."
}

You can use the following parameters for a pipeline committed event:

• PIPELINE_ID - The pipeline ID.
• PIPELINE_NAME - The pipeline name.
• PIPELINE_VERSION - The pipeline version.
• PIPELINE_COMMIT_ID - The commit ID for the pipeline version.
• PIPELINE_COMMITTER - The name of the user who committed the pipeline.
• PIPELINE_COMMIT_MESSAGE - The commit message.
• PIPELINE_COMMIT_TIME - The day and time the pipeline was committed.

For example, if you configure a subscription to send a webhook each time a pipeline is committed, you might use the following message in the JSON request payload:

{  
   "text":"{{PIPELINE_NAME}} was committed on {{PIPELINE_COMMIT_TIME}}."
}

Or, you can filter pipeline committed events to only include pipelines with a specific commit message:

${str:contains(PIPELINE_COMMIT_MESSAGE,"First commit")}

For example, if you configure a subscription to send a webhook when a pipeline status changes, you might use the following multi-line message in the JSON request payload:

{  
   "text":"The pipeline {{PIPELINE_NAME}} running on Data Collector {{SDC_ID}} changed status. \nFrom {{FROM_STATUS}} to {{TO_STATUS}}."
}

Or, you can filter pipeline status change events when they change to a status of RUN_ERROR:

${str:contains(TO_STATUS, "RUN_ERROR")}