SmartTasks

Management SmartTasks let you configure automatic actions according to different triggers in the system. A SmartTask is a combination of trigger and action.

  • Triggers are events – currently defined in terms of existing management operations, such as installing a policy or publishing a session.

  • Actions are automatic responses that take place after the trigger event , such as running a script, posting a web request or sending email.

Available Triggers

  • Before Publish - Fired when an administrator publishes a session. The SmartTask passes the sessions meta-data (publishing administrator, domain information and session name) to the action. If the local Management API server is available, the session changes about to be published are formatted as a response to the "show changes" API.

  • After Publish - Fired after an administrator successfully publishes a session. The SmartTask passes the same information to the action as the Before Publish trigger.

  • After Install Policy - Fired after a policy has been installed. The SmartTask passes to the action information related to the policy installation task, such as the package installed, the administrator who initiated the installation and the task's result.

Available Actions

  • Run Script - Runs a pre-defined Repository Script. The script gets the trigger's data as the first parameter. The trigger's data is passed as Base64 encoded JSON data, which can be decoded to implement custom business logic.

    For SmartTasks configured to run with "Before" operation triggers, the repository script can signal whether to abort or continue the operation by printing a JSON object with the "result" and optional "message" fields and then exit with code 0. If the value of the "result" field is "failure" the operation aborts.

    For SmartTasks configured to run with other triggers, exit code 0 is treated as success. Any other exit code is treated as failure.

    Note - By default, Repository Scripts run on the local Security Management ServerClosed Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server. although this can be customized using the Web API.

  • Web Request - Executes an HTTPS POST web request to the configured URL. The trigger's data is passed as JSON data to the request's payload.

    Notes:

    • The configured URL must start with HTTPS and the target web server capable of handling such requests.

    • For web servers with self-signed SSL certificates, establish trust by specifying the certificate's fingerprint. You can get the fingerprint by clicking Get Fingerprint in the SmartTask editor or by viewing the certificate in a web browser.

    For SmartTasks configured to run with "Before" operation triggers, the repository script can signal whether to abort or continue the operation by responding with JSON object "result" and optional "message" fields and a status of 200 OK. If the value of the "result" field is "failure" the operation aborts.

    For SmartTasks configured to run with other triggers, a 200 OK return code is treated as success. Any other exit code is treated as failure.

Configuring SmartTask Properties

  1. Enter a unique name for the SmartTask - The name property is required and case sensitive.

  2. Switch the SmartTask ON or OFF using the toggle button.

  3. Optional - Enter a description for the SmartTask.

  4. Select a trigger for the SmartTask.

  5. Select an action that will happen once the trigger is fired.

  6. Custom Data – You can add additional information to the JSON data sent with the trigger information by adding a JSON object to the Custom Data field. The JSON custom data is concatenated to the trigger's payload and passed to the action.

  7. Optional - Add tags for the SmartTask object.

SmartTask Advanced Properties

The available advanced options depend on the action selected on the General tab.

Send Web Request

Run script

  • Time-out – Number of seconds before the request times out and the request aborted.

  • If the script fails to run or times-out – Treat time-out (or execution failure) as an error and abort the event or continue normally.