Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Scheduler maintenance REST API is designed to provide the possibility to interfere when running blueriq on single or multi-nodes environments. 

This REST API must be used when:

  • Servers shutdowns occur unexpectedly on multi-nodes environments. In this situation the abandoned tasks have to be recovered by calling Cancel All Started Tasks Endpoint.
  • Application name and/or version is changed in Blueriq Studio. In this situation the changes are propagated to the database by calling the Update Application Name and Version Endpoint.

These two endpoint are described below:

Cancel All Started Tasks

Situation

Cancel started tasks is the mechanism of recovering the abandoned tasks that were not completed due to unexpected runtime nodes shutdowns.

Blueriq provides two ways for enabling this mechanism:

  1. Setting the property blueriq.processengine.cancel-started-tasks to true on the process module. This is supported also in previous Blueriq versions and it is designed for single node environments. For more information about process module properties please consult Process Module Properties.
  2. Using the cancel started tasks endpoint described below. It is designed for multi-nodes environments and overrules the blueriq.processengine.cancel-started-tasks property.

Setting the property 

Cancel all started tasks

Description

By calling this endpoint, all the started tasks across all nodes will be reopen. Automatic tasks will also be executed.

Info
iconfalse

PUT http://<server>:<port>/<runtime_name>/api/v1/scheduler/maintenance/tasks/cancelStarted

Setting the property blueriq.processengine.cancel-started-tasks to  to true when  when running in a multi-node environment environment might cause problems because unexpected behavior. For example while the cancellation of started tasks triggered on one runtime node is running, a specific task could be still in progress on another runtime node and it might be reopen.

Cancel all started tasks endpoint was created in order to avoid these types of situations.

Info

The endpoint overrules the blueriq.processengine.cancel-started-tasks property.

Usage

The following steps should be followed for using this endpoint:

Info

When unexpected runtime nodes shutdowns occur:

  • It is recommended to use the endpoint in multi-node environments.
  • In single node environments either the endpoint or the property can be used.

Description

  • Make sure that there exists a runtime user with a role that has the permission SCHEDULER_MANAGER.
  • Check that blueriq.oauth2.client-id and blueriq.oauth2.secret are defined in application.properties file. If they are missing, please define them.
  • Access Runtime Swagger Interface: 

    Info
    iconfalse

    PUT http://<server>:<port>/

    <runtime>

    <runtime_name>/api/v1

    /docs/index.html
  • Fill the username and the password and press Generate Token in order to obtain a new token.
  • Expand scheduler.
  • Expand PUT

    /scheduler/maintenance/tasks/cancelStarted

    .
  • Press Try it out!
  • By calling this endpoint, all started manual tasks across all nodes will be reset to open and all started automatic tasks will executed. 

    Update Application Name And Version

    Situation

    This endpoint is needed in case you already ran a process enabled project and find out that you have to rename the model name and/or version. Renaming the model in studio doesn't change the cases and jobs references to the model in the database; they still use the old, previous model. The result is that the previously created timers cannot be used anymore, priority algorithm won't be called anymore and tasks with expiration will not expire anymore. To get it back working normally the application name and/or version have to be changed to the new name and/or version (as provided in the studio model) in the database. This can be done by using this endpoint.

    Description

    By calling one of these endpoints, endpoint, the application ids for cases matching the application id name from the url will be updated for the cases and jobs matching the specified criteriawith new values. Every job registered to these cases will be updated as well.

    Info
    iconfalse

    PUT http://<server>:<port>/<runtime_name>/api/v1/scheduler/maintenance/applications/{oldApplicationNamecurrentApplicationId}/?caseId={oldApplicationVersioncaseId}

    {
    "name" : {newApplicationName},
    "version" : {newApplicationVersion}
    }

     

    Validations

    1. Current application id consists of application name and application version. Format of the application id is: applicationName:applicationVersion.
    2. Current application id is mandatory, case id is optional.
      If case id is specified, only one case will be updated. If case id is not specified all cases matching the application id will be updated.
    3. At least new name or new version must be specified in the request body.

    Steps:

    1. Find all cases where matching the application id contains the old application name. If old application version is specified in the url, find all cases where application id matches with the name and version(from the url). If case id is specified, find the case by it's id.
    2. Update application id for these the cases from step 1, with the new data sent in the request body. Name or version or both can be updated, depending on what is specified in the request body.
    3. Get the jobs for the cases and update them accordingly.

    Request examples:

    1. Update application name.1.1

      Update application name on every version of your old application.
      All cases where application name is The application ids, for the cases with the current application id "export-TestOldProject:0.0-Trunk", are updated to "export-TestNewProject:0.0-Trunk". 

      Info
      iconfalse

      PUT http://<server>:<port>/<runtime_name>/api/v1/scheduler/maintenance/applications/export-TestOldProject:0.0-Trunk

      {
      "name" : "export-TestNewProject"
      }

      Note
      titleNote

      If you do not specify the old application version in the url, this endpoint will update the application name for every version of the specified old application. If you would like to update the application name only for a specific version, you should use the endpoints below.

    2. 1.2. Update application name for a specific version.
      All cases where application name is "export-TestOldProject" and version is "Update application version

      The application ids, for the cases with the current application id "export-TestOldProject:0.0-Trunk" are , are updated to "export-TestNewProject". Version remains the sameTestOldProject:0.1-Trunk"

      Info
      iconfalse

      PUT http://<server>:<port>/<runtime_name>/api/v1/scheduler/maintenance/applications/export-TestOldProject/:0.0-Trunk

      {
      "nameversion" : "export0.1-TestNewProjectTrunk"
      }

    3. Update application id (both name and version.
      All cases where application name is )

      The application ids, for the cases with the current application id "export-TestOldProject" and version is ":0.0-Trunk", version is  are updated to "export-TestNewProject:0.1-Trunk". Application name remains the same. 

      Info
      iconfalse

      PUT http://<server>:<port>/<runtime_name>/api/v1/scheduler/maintenance/applications/export-TestOldProject/:0.0-Trunk

      {
      "name" : "export-TestNewProject",
      "version" : "0.1-Trunk"
      }

    4. Update application id (both name and version)for a specific case
      1. Update application name

        The application id, for the case with the current application id 


      All cases where application name is
      1. "export-TestOldProject

      " and version is "
      1. :0.0-Trunk"

      , application name is
      1. and case id 1, is updated to "export-TestNewProject

      " and version is updated to "
      1. :0.

      1
      1. 0-Trunk". 

        Info
        iconfalse

        PUT http://<server>:<port>/<runtime_name>/api/v1/scheduler/maintenance/applications/export-TestOldProject

      /
      1. :0.0-Trunk?caseId=1

        {
        "name" : "export-TestNewProject"

      ,

      1. }

      "version" : "0.1-Trunk"
      }

    Usage

    The following steps should be followed for using this endpoint:

      1. Update application version

        The application id, for the case with the current application id "export-TestOldProject:0.0-Trunk" and case id 1, is updated to "export-TestOldProject:0.1-Trunk".

    1. Make sure that there exists a runtime user with a role that has the permission SCHEDULER_MANAGER.
    2. Check that blueriq.oauth2.client-id and blueriq.oauth2.secret are defined in application.properties file. If they are missing, please define them.
    3. Access Runtime Swagger Interface:
      1.  

        Info
        iconfalse

        PUT http://<server>:<port>/

      <runtime>
      1. <runtime_name>/api/v1

      /docs/index.html
    4. Fill the username and the password and press Generate Token in order to obtain a new token.
    5. Expand scheduler.
    6. Expand PUT
      1. /scheduler/maintenance/applications/

      {oldApplicationName} or PUT /scheduler/maintenance/applications/{oldApplicationName}/{oldApplicationVersion}.
    7. Specify the old application name you would like to update. Optionally specify the application version.
    8. Specify the body of the request with the new application name, or new application version or both.
    9. Press Try it out!

    Update Application Name and Version for a Case

    Description

    By calling this endpoint, only one case and it's jobs will be updated with the new information.
      1. export-TestOldProject:0.0-Trunk?caseId=1

        {
        "version" : "0.1-Trunk"
        }

      2. Update application id

        The application id, for the case with the current application id "export-TestOldProject:0.0-Trunk" and case id 1, is updated to "export-TestNewProject:0.1-Trunk". 

        Info
        iconfalse

        PUT http://<server>:<port>/<runtime_name>/api/v1/scheduler/maintenance/applications/

    cases/{caseId} 
      1. export-TestOldProject:0.0-Trunk?caseId=1

        {
        "name" :

    {newApplicationName}
      1. "export-TestNewProject",
        "version" :

    {newApplicationVersion}
    }

    Steps:

    1. Finds the case with the specified case id. 
    2. Update the application id for the case found.  Application id is updated with the new application name sent in the request body. Optionally, if specified in the body, application version will be updated as well.
    3. Calls the scheduler to find all jobs for the case from step 1.
    4. Updates all the jobs with the new application id.
      1. "0.1-Trunk"
        }

    Usage

    The following steps should be followed for using this endpoint:

    1. Make sure that there exists a runtime user with a role that has the permission SCHEDULER_MANAGER.
    2. Check that blueriq.oauth2.client-id and blueriq.oauth2.secret are defined in application.properties file. If they are missing, please define them.
    3. Access Runtime Swagger Interface: 

      Info
      iconfalse
      http://<server>:<port>/<runtime>/api/v1/docs/index.html
    4. Fill the username and the password and press Generate Token in order to obtain a new token.
    5. Expand scheduler.Expand
    6. Expand the endpoint you want to use. Available options are:
      • PUT /scheduler/maintenance/tasks/cancelStarted
      • PUT
       PUT
      • /scheduler/maintenance/applications
      /cases
      • /{
      caseId
      • currentApplicationId}
      .
    7. Specify the case idrequest parameters.
    8. Press Try it out!