C.6 Example: Overriding the Default Task Order with Custom REST Callouts

The following is an example of how to use the REST API to get the current configuration:

method: GET

URL: http://localhost:8183/cloudmanager-api/system/integrationconfigitems/TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST

Return packet:

{
  "key": "TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST",
  "sourceObjId": 1,
  "sourceObjName": "System",
  "sourceObjType": "SYSTEM",
  "value": "2=TASK_SPONSOR_BS@!@1=TASK_ADMIN_APPROVE_BS",
  "url": "http://localhost:8183/cloudmanager-api/system/integrationconfigitems/TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST"
}

This GET call returns the current configuration for the specified configuration item. In this case, the specified item called for is the TaskBasedApproval step in new business services requested throughout the Cloud Manager system.

NOTE:You could replace the /system/ component of the URL with /organizations/<orgID>/ if you wanted to work with the configuration for a specific organization.

If a configuration doesn't exist at /organizations/<orgID>/, it inherits that configuration from the system level.

To change the current configuration, execute a PUT call with an appropriate packet. In the example to follow, assume a new custom permission, MY_CUSTOM_PERMISSION, has been created in the system and that specific users have been given this permission.

If you want to change the approval task order so that it is routed first to administrator approval permission and then to the new custom permission, you would use the following procedure:

Method: PUT

URL: http://localhost:8183/cloudmanager-api/system/integrationconfigitems/TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST

Input Packet:

{
  "key": "TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST",
  "sourceObjId": 1,
  "value": "2=MY_CUSTOM_PERMISSION@!@1=TASK_ADMIN_APPROVE_BS"
}

In both of these sample REST calls, the PUT and the GET methods both use the cloudmanager-api configuration URL. The value property in the packet is defined by the specific callout. Task callouts expect an order of permissions, but custom callouts define their own value format.

To accomplish the same GET and PUT that we did above, but in a Task callout-specific way, use the following procedure, with the GET call first:

Method: GET

URL: http://localhost:8183/tasks-api/system/taskconfigurations/TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST

Return Packet:

{
  "calloutName": "TaskBasedApproval",
  "configItem": {
    "key": "TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST",
    "sourceObjId": 1,
    "sourceObjName": "System",
    "sourceObjType": "SYSTEM",
    "value": "2=TASK_SPONSOR_BS@!@1=TASK_ADMIN_APPROVE_BS"
  },
  "key": "TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST",
  "opType": "NEW_BUSINESS_SERVICE_REQUEST",
  "option": "",
  "taskAssignmentOrder": 
  [
    {
      "name": "TASK_ADMIN_APPROVE_BS"
    },
    {
      "name": "TASK_SPONSOR_BS"
    }
  ],
  "url": "http://localhost:8183/tasks-api/system/taskconfigurations/TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST"
}

The GET call results in more information, and makes sense of the value property in a way that the Task Callout understands it.

The PUT call would look like this:

Method: PUT

URL: http://localhost:8183/tasks-api/system/taskconfigurations/TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST

Input Packet:

{
  "key": "TaskBasedApproval:NEW_BUSINESS_SERVICE_REQUEST",
  "taskAssignmentOrder": 
  [
    {
      "name": "TASK_ADMIN_APPROVE_BS"
    },
    {
      "name": "MY_CUSTOM_PERMISSION"
    }
  ]
}