AE REST API - Database Maintenance

You can use the AE REST API to perform database maintenance activities such as archiving operational data or creating revision reports.

When you trigger the archive process or trigger a revision report using the REST API, a Job starts in the background that collects the relevant data in files and packages them in a ZIP file. The ZIP file is temporarily stored in the directory that you specify in the outputPath parameter in the Automation Engine's INI file (for on-premises environments) or in the values.yaml file (for AAKE environments). You can then transfer it to a directory of your choice. For more information see Automation Engine INI file and Preparing for the Container-Based Installation.

This page includes the following:

Prerequisites for Database Maintenance Tasks

Make sure you meet the following requirements:

To archive operational data:
- You need the Database Maintenance (DB_MAINTENANCE) privilege to start the archiving process
- You need the Access to metrics and download audit reports (ACCESS_METRICS_ENDPOINT) privilege to download archive files, see Granting Automation Engine Privileges.
- First configure the archiving parameters in the UC_UTILITY_ARCHIVE variable that is available in Client 0. For more information, see UC_UTILITY_ARCHIVE - Configuring the Archiving Parameters.
For more information, see Archiving Operational Data.
To create Revision Reports:
- You need the Database Maintenance (DB_MAINTENANCE) privilege to trigger Revision Reports
- You need the Access to metrics and download audit reports (ACCESS_METRICS_ENDPOINT) privilege to download Revision Reports, see Granting Automation Engine Privileges.
- To activate object logging, set the OBJECT_AUDIT key of the variable in UC_CLIENT_SETTINGS to Y, see OBJECT_AUDIT.
- Set the SECURITY Parameters in UC_CLIENT_SETTINGS to log authorized/denied accesses, see SECURITY Parameters.
For more information, see Creating Revision Reports.

REST API: Archiving Operational Data

Operational data are system messages, execution data (formerly called statistics), reports and comments. You can archive them and download the resulting archive files.

Archiving operational data involves the following steps:

Configure the directory where the archive package will be automatically stored as soon as you trigger the process (in the INI file for on-premises and in the values.yaml file for AAKE environments).
Trigger the archiving process either in one or in several Clients.
Use the runID of the executed archiving process to download the archive package.

Start Archiving Operational Data in a Specific Client

Request: POST {client_id}/system/clients/archive

Example This request starts archiving data in Client 100

POST https://rest-1228352288.ap-as.autsrv.com/ae/api/v1/0/system/clients/archive?target_client=100

Response:

{
    "run_id": 1007001
}

Start Archiving Operational Data in All Clients

Request: POST {client_id}/system/clients/archive

Example This request starts archiving data in all Client

POST https://rest-1228352288.ap-as.autsrv.com/ae/api/v1/0/system/clients/archive?target_client=ALL

Response:

 "parent_run_id": 1007003,
    "clients_archived": [
        {
            "run_id": 1007004,
            "client": 0
        },
        {
            "run_id": 1007005,
            "client": 100
        }
    ]
}

Getting Archive Files of a Specific Archive Run

Request: GET {client_id}/system/clients/archive/{run_id}

Example: This request gets the archived files for the specified runID.

GET https://rest-1213755983.ap-as.autsrv.com/ae/api/v1/0/system/clients/archive/1007001

To have the archive package sent and downloaded to your file system, you have the following options:

If you are using a REST client, such as Postman, you send and download the package directly from the client. For example, in Postman you must select the Send and Download option available for your GET command.
If you are using cURL to transfer data, you download the package using -o in the command.

Response:

The response in this case is the actual download of the archive package.

REST API: Creating Revision Reports

Revision Reports are designed to create chronologically structured reports that capture the history of changes within your Automic Automation Client or Clients, thus allowing you to maintain a secure, compliant, and well-managed automation environment.

Creating Revision Reports involves the following steps:

Configure the directory where the report will be automatically stored as soon as you trigger the process (in the INI file for on-premises and in the values.yaml file for AAKE environments).
Trigger the revision reporting process either for one or all Clients (in Client 0).
Use the runID of the executed report creation process to download the report.

Revision Report Parameters

You can use the following parameters to specify the request:

from: start of the date and time range for the report, default is 0
to: end of the date and time range for the report, default is now

The from and to parameters define the date and time range for the report.
updateArchiveFlag: Sets archive flags to the data included in the report. This is relevant for future reports in case you want to only include data that was never included in a report before.
readOnlyNotSeen: Include only modification entries that have never been included in a revision report before such as entries that do not have archive flags.
types: Content type that you want to be included in the report:
- ACCESS - Unauthorized access
- CANCEL - Tasks aborted
- CREATE - New objects created
- DELETE - Objects deleted
- IMPORT - Objects imported
- MOVE - Objects moved
- OBJ_MOD - Object modifications
- RENAME - Objects renamed
- RESTART - Tasks restarted
- RESTORE - Objects restored
- RUN_MOD - Objects modified at runtime
- START - Tasks started
- TRNSPRT - Objects transported
- USER - Successful user logons and logoffs
If not defined, all options are included.

Start Creating Revision Reports for One or All Clients

You can trigger a Revision Report in Client 0 for one or all Clients. You cannot select some of them.

Request: POST http://{host}:{port}/ae/api/v1/{client_id}/system/clients/revisionreport

Example for one Client: http://my-jcp-host:8088/ae/api/v1/0/system/clients/revisionreport?target_client=100

In this case, a report is triggered from Client 0 for Client 100.

Example for all Clients in Client 0: http://my-jcp-host:8088/ae/api/v1/0/system/clients/revisionreport?target_client=ALL

In this case, a report is triggered from Client 0 for all Clients.

You can further specify the request using the parameters listed above.

Request example:

{    
  "from": "2025-01-01T00:00:00Z",
  "to": "2025-01-01T00:00:00Z",
  "update_archived_flag": false,
  "read_only_not_seen": false,
  "types": [
    "ACCESS", "CANCEL", "CREATE", "DELETE", "IMPORT", "MOVE", "OBJ_MOD", "RENAME","RESTART", "RESTORE", "RUN_MOD", "START", "TRNSPRT", "USER"
  ]
}

Response:

{
    "run_id": 1016053
}

Getting the Revision Reports for One or All Clients

Request: GET http://{host}:{port}/ae/api/v1/{client_id}/system/clients/revisionreport/{run_id}

Example:

http://my-jcp-host:8088/ae/api/v1/0/system/clients/revisionreport/1234567

Response:

The response in this case is the actual download of the Revision Report for the run with runID 1234567.