Polling and Callback Requests

You can poll the server to check the status of your REST request or you can subscribe to a callback.

This page includes the following:

AE REST API Polling

You can poll the server to check the status of a REST request/response sequence in case the desired result is not yet available. For example, you could poll the server after executing an object and getting the RunID to check if the execution has ended.

The following sample shows how polling for execution status can be done through the AE REST API:

AE REST API Callback Request

If you do not want to poll the server to check the status of an execution, you can subscribe to a callback. In this case, the system sends you -the subscriber - a REST request to inform you that the execution has ended (successfully or not). You can subscribe by adding an optional callback URL to the REST execution request so that the system knows where to reach you.

You can see the callback (CBCK) notification entries in the Tasks list in the Process Monitoring perspective in the Automic Web Interface. You can also apply a filter to specifically search for them by opening the filter pane and selecting Task Type > Runtime Objects > Callback.

More information:

You can customize the callback request using the UC_CALLBACK_SETTINGS variable. The variable allows you to determine the number of retry attempts (in case the initial try fails) and their interval, which can be constant, linear, or exponential:

Constant: the system uses the value defined in the CALLBACK_INTERVAL key as is
Linear: the system multiplies the value defined in the CALLBACK_INTERVAL key by the number of failed attempts

Example

You have define an interval of 30 seconds and want to use the linear mode.

If the initial try fails, the first callback attempt takes place after 30 seconds (1 failed attempt * 30 seconds), the second after 60 seconds (2 failed attempts* 30 seconds), and so on.
Squared: the system exponentially calculates the interval from the definition of the CALLBACK_INTERVAL key and the number of failed attempts.

Example

You have define an interval of 30 seconds and want to use the squared mode.

If the initial try fails, the first callback attempt takes place after 30 seconds (1 failed attempt: 12 * 30 seconds), the second after 120 seconds (2 failed attempts: 22 * 30 seconds), the third after 270 seconds (3 failed attempts: 32 * 30 seconds), and so on.

You can also enforce the use of HTTPS and decide if you want a default payload response. In this case, the response includes only the run_id, the object_type, and the execution_status. You can also customize the payload response to your needs. For more information, see UC_CALLBACK_SETTINGS - REST Callback Request Customization.

To customize the payload, you can use one or more of the following options:

Variables that are valid for any executable object and are consistent throughout the system, see List of System Properties
Variables that are specific to an object, see Variables Page
Template placeholders that are specific for callbacks:
- &$EXECUTION_STATUS#
- &$EXECUTION_STATUS_TEXT#
- &$LAST_ERROR_MESSAGE#
- &$LAST_ERROR_CODE#
- &$LAST_ERROR_INSERT#

Examples of Object Executions

Request: POST http://{host}:{port}/ae/api/v1/executions

Example: http://ae_host:8088/ae/api/v1/executions

Object execution with optional callback URL using the default response payload:

{
  "object_name": "JOBP.EXAMPLE",
  "alias": "EXAMPLE_WORKFLOW",
  "queue": "TEST_QUEUE",
  ...
  "callback":
  {
     "type": "http",
     "http":
     {
        "url": "https://axa.dxi-na1.saas.broadcom.com/ae-doi-integration/v1/54643542353543/jobStatus?caemmlutkn=LTExNzM1OTM5NTE",
     }
  }
}

HTTP 200 Response:

{
  "runid": "0001005016",
  "object_type": "SCRI",
  "execution_status": "1900",
}

Subscribing to callbacks for recurring executions ("execution_option":"recurring") is not supported. When you start a recurring execution via the REST API including a callback subscription, the execution is carried out but the callback does not take effect.

Object execution using TEMPLATE_EXECUTION:

{
   "runid": "&$RUNID#",
   "object_type": "&$OBJECT_TYPE#",
   "execution_status": "&$EXECUTION_STATUS#",
   "execution_status_text": "&$EXECUTION_STATUS_TEXT#",
   "ae_system": "&$SYSTEM#",
   "client_number": "&$CLIENT#",
   "client_description": "&$CLIENT_DESC#",
   "user_department": "&$USER#/&$DEPARTMENT#",
   "archive_key1": "&$ARCHIVE_KEY1#",
   "last_error_message": "&$LAST_ERROR_MESSAGE#",
   "last_error_code": "&$LAST_ERROR_CODE#",
   "last_error_insert": "&$LAST_ERROR_INSERT#",
   "object_variable1": "&VAR1#",
   "object_variable2": "&VAR2#"
}

HTTP 200 Response:

{
  "runid": "0001005016",
  "object_type": "SCRI",
  "execution_status": "1900",
  "execution_status_text": "ENDED_OK - ended normally",
  "ae_system": "AUTOMIC",
  "client_number": "0100",
  "client_description": "Test client",
  "user_department": "CD/CD",
  "archive_key1": "Category17",
  "last_error_message": "",
  "last_error_code": "00000000",
  "last_error_insert": "",
  "object_variable1": "17842312",
  "object_variable2": "a text value"
}

Callback Headers

You can define any key/value pair in the "headers": section of an execution request. The values stated here are then taken over in the callback header.

For example, you can use Bearer tokens for authorization purposes and define the key/value pair in the "headers": section of the execution request.

Execution request:

{
  "object_name": "JOBP.MY_MITIGATION_WORKFLOW",
  "callback":
  {
    "type": "http",
    "http":
    {
       "url": "https://myserver:8888/ae-doi-integration/v1/jobStatus",
       "headers":
       {
         "Authorization": "Bearer 435345f1232a34543b34fff"
       }
    }
  }
}

Callback header:

...
Authorization: Bearer 435345f1232a34543b34fff
...

Callback payload:

{
    "run_id": 2303535,
    "name": "JOBP.MY_MITIGATION_WORKFLOW",
    "status": 1900
}