A Cloud Manager user can create, change, or delete a business service. Cloud Manager processes each of these three “requests” in its own unique workflow process: a series of steps occurring in the build and provisioning process.
During the workflow process, actions are taken sequentially as needed so that the process flows correctly. In general, the workflow proceeds in the order listed in the following table:
Table D-1 Cloud Manager Workflow Phases
|
Workflow Phase (Action Type) |
Operation Type |
Default, TaskBased Callout |
Customizeable by Using Callouts |
|---|---|---|---|
|
1. Submit |
n/a |
no |
no |
|
2. Approval |
Approval |
yes |
yes |
|
3. Pre-build configuration (also known as “PreConfig”) |
Configuration |
yes |
yes |
|
4. Mid approval |
Approval |
yes |
yes |
|
5. VM/workload build |
n/a |
no |
no |
|
6. Post-build configuration (also known as “PostConfig”) |
Configuration |
yes |
yes |
|
7. Post-build approval (also known as “PostApproval”) |
Approval |
yes |
yes |
|
8. Pre-deploy (or “PreDeploy”) |
Notification |
no |
yes |
At the appropriate time in the workflow, the Cloud Manager Application Server invokes a uniquely registered and configured external process to execute each individual, categorized step. After the process (also known as a “callout”) performs its function in order, it reports its status to the Application Server, so that the server can invoke the next process. For Approval type operations, the completion status is either or . For Configuration type operations, the completion status is either or . For Notify type operations, the callout is invoked asynchronously, so the server does not need to wait for confirmation. Without waiting for confirmation, the server signals this callout that it is time to execute its functions.
The default callout registered for each of these phases (except for PreDeploy) is handled by a task system (a TaskBasedCallout). One or more tasks are created for each phase and assigned, based on a set of rules. In theTaskBasedCallout system, each callout is configured with predefined tasks. For each business service request, the callout detects the tasks that must be created and to which Cloud Manager user (based on assigned roles and rights) the tasks should be assigned.
The workflow configuration can be specified at the system, organization, or business group layer. with the lowermost level dominating.
As a Cloud Administrator, you can skip any of the phases of the workflow and you can change or override default tasks by altering the permission assignment or the order.
As the Cloud Administrator, you can customize the workflow to invoke alternative callouts in place of Cloud Manager’s default task-based callouts. This might be useful if you want to integrate the Cloud Manager workflow with other existing approval processes or scripted configuration procedures. This section explains how to use REST calls to customize the callouts you need to integrate Cloud Manager’s workflow with the workflow of a 3rd party system.
This section includes the following information:
(header of customizing callouts section)
After you have created a custom callout (separate doc) you can invoke a REST API call to actually register a callout in Cloud Manager. The registration defines a combination of conditions that, when satisfied, trigger Cloud Manager to invoke that callout. The conditions include the following:
The domain level where the operation should happen, such as the entire Cloud Manager system, one of the organizations in the system, or one of the business groups in an organization.
When you register a callout, you do so at a domain level (system, organization, or business group). The registration levels are hierarchical. That is, if you do not register the callout at the organization level, it inherits the registration from its parent. You can register only one callout per operation, per domain level.
The intended behavioral differences for the callout when applied to different business service request types:
Create a new business service (NEW)
Change an existing business service (CHANGE)
Delete an existing business service (DELETE)
The intended action of “step” of the callout in the workflow, which would be one of the following:
Approval
PreConfig
PostConfig
PostApproval
PreDeploy
If you want to bypass (that is, “skip”) PreConfig approval of a workload that you customize for a user, it is not possible to do so using the Application Server Console, but you can invoke REST callouts that let you modify the skip flag in that stage of the workflow for new or changed business service requests.
The following skip flags are supported in Cloud Manager:
skipNewWorkflowApproval
skipNewWorkflowPreConfig
skipNewWorkflowPostConfig
skipNewWorkflowPostApproval
skipChgReqWorkflowApproval
skipChgReqWorkflowPreConfig
skipChgReqWorkflowMidApproval
skipChgReqWorkflowPostConfig
skipChgReqWorkflowPostApproval
skipDelWorkflowApproval
skipDelWorkflowPreConfig
The following instructions for modifying PreConfig workflow REST callouts assume that you want to invoke the change for the entire Cloud Manager system. The instructions also assume that you are using the application/json payload type, although Cloud Manager also supports the application/xml payload type.
Invoke a REST GET call at the following URL:
http://<server>:<port>/8183/cloudmanager-api/system/integrationconfigs
The call returns the current settings. For example:
{
"skipChgReqWorkflowPostApproval": true,
"skipDelWorkflowPreConfig": true,
"skipNewWorkflowPostApproval": true,
"sourceObjId": 1,
"sourceObjName": "System",
"sourceObjType": "SYSTEM",
"url": "http://localhost:8183/cloudmanager-api/system/integrationconfigs"
}
The skip flags are tri-state: true, false, or empty. The empty state implies that it is inherited from the parent (if there is one). The true and false states imply an override of the parent setting, if there is one.
In the callout, add the skip flag for the PreConfig stage of the workflow when business services are created or changed:
{
"skipChgReqWorkflowPostApproval": true,
"skipDelWorkflowPreConfig": true,
"skipNewWorkflowPostApproval": true,
"skipNewWorkflowPreConfig": true,
"skipChgReqWorkflowPreConfig": true,
"sourceObjId": 1
}
In this example, the URL and the source object information are removed from the callout packet because they are not necessary for the PUT.
Invoke a REST PUT call at the same URL,
http://<server>:<port>/8183/cloudmanager-api/system/integrationconfigs
making sure that the payload type is correct, then save the PUT.
Confirm that the PUT was correctly by invoking a GET at the same URL and checking the packet structure, shown in Step 2.
NOTE:If you wanted to make this modification for a single system, you would replace the http://<server>:<port>/8183/cloudmanager-api/system/integrationconfigs URL with http://<server>:<port>/8183/cloudmanager-api/organizations/<orgId>/integrationconfigs.
You can configure Cloud Manager by using different REST API calls on the Cloud Manager Application Server. The REST Client plugin for Firefox, or the Advanced Rest Client plugin for the Google Chrome browser have been tested for such calls.
You can visit http://<server>:<port>/cloudmanager-api for a full reference of the REST API, including the contents of the API packets include on return or should include on input.
The tables below show the REST endpoints you can use to view the current Cloud Manager callouts. The URLs in the tables contain variables (that is, address elements surrounded by brackets < >) that imply specific information that you must provide:
/<domID>/ implies that you substitute one of the following:
/system/
/organizations/<orgID>/
/businessgroups/<bgID>/
Table D-2 REST Calls for installed or available callouts
|
URL Suffix |
Method |
Purpose of the Command / The Resulting Payload |
|---|---|---|
|
/callouts |
GET |
Purpose: Represents the list of services mentioned in Section D.2, Using the REST APIs to Modify the Cloud Manager Workflow. Payload:
{"count":"4",
"items":[
{
"bundleName":"com….taskBasedCallouts",
"canonicalClassName":"org.eclipse….ServiceReferenceImpl",
"implementedInterface":"interface com….ApprovalCalloutIfc",
"provides":"Approval",
"registrationName":"TaskBasedApproval",
"simpleClassName":"ServiceReferenceImpl",
"url":"http://host:8183/cloudmanager-api/callouts/TaskBasedApproval"
},
…
] }
|
|
/callouts/{name} |
GET |
Purpose: Gets the specified callout available in the OSGI system. {name}=registrationName NOTE:Everything in this payload is defined by the OSGI bundle, nothing is configurable, so no PUT operation is used. Payload:
{
"bundleName":"com….taskBasedCallouts",
"canonicalClassName":"org.eclipse….ServiceReferenceImpl",
"implementedInterface":"interface com….ApprovalCalloutIfc",
"provides":"Approval",
"registrationName":"TaskBasedApproval",
"simpleClassName":"ServiceReferenceImpl",
"url":"http://host:8183/cloudmanager-api/callouts/TaskBasedApproval"
}
|
Table D-3 REST Calls for integration configuration flags
|
URL Suffix |
Method |
Purpose of the Command / The Resulting Payload |
|---|---|---|
|
/<domID>/integrationconfigs |
GET |
Purpose: Gets the domain object’s integration configuration flags. Payload:
{
"skipChgReqWorkflowApproval":false,
"skipChgReqWorkflowPostApproval":true,
"skipChgReqWorkflowPostConfig":false,
"skipChgReqWorkflowPreConfig":false,
"skipDelWorkflowApproval":false,
"skipDelWorkflowPreConfig":true,
"skipNewWorkflowApproval":false,
"skipNewWorkflowPostApproval":false,
"skipNewWorkflowPostConfig":false,
"skipNewWorkflowPreConfig":false,
"sourceObjId":1,
"sourceObjName":"System",
"sourceObjType":"SYSTEM",
"url":"http://host:8183/cloudmanager-api/system/integrationconfigs"
}
|
|
/<domID>/integrationconfigs |
PUT |
Purpose: Sets the domain object’s integration configuration “skip” flags. Payload: Same payload as specified above. Skip flags have a tri-state: True, False, or empty. An empty value implies inheritance from the domain object’s parent. |
|
/<domID>/integrationcalloutitems |
GET |
Purpose: Lists all callout registrations for the specified domain object. Payload:
{
"count":10,
"items":[
{
"key":"NEW_BUSINESS_SERVICE_REQUEST:POST_CONFIG",
"sourceObjId":1,
"sourceObjName":"System",
"sourceObjType":"SYSTEM",
"value":"TaskBasedPostConfig",
"url":http://host:8183/cloudmanager-api/system/integrationcalloutitems/<key>
},
…
] }
|
|
/<domID>/integrationcalloutitems/{key} |
GET |
Purpose: Gets the specified callout registration. Payload: The payload in the example below indicates that at the system level, the TaskBasedPostConfig callout is used for PostConfig phase of new business service requests.
{
"key":"NEW_BUSINESS_SERVICE_REQUEST:POST_CONFIG",
"sourceObjId":1,
"sourceObjName":"System",
"sourceObjType":"SYSTEM",
"value":"TaskBasedPostConfig",
"url":http://host:8183/cloudmanager-api/system/ integrationcalloutitems/<key>
}
|
|
/<domID>/integrationcalloutitems |
PUT |
Purpose: Creates or modifies the registration for the specified domain object. Payload:
{
"key":"NEW_BUSINESS_SERVICE_REQUEST:POST_CONFIG",
"value":"TaskBasedPostConfig",
}
|
|
/<domID>/integrationconfigitems |
GET |
Purpose: Gets the callout-specific configurations for the specified domain object. The “value” tag of the payload is specific to the callout. Payload: The payload in this example indicates that when the TaskBasedPostConfig callout is invoked for new business service requests. The callout creates a single task and assigns it to the TASK_COMPLETE_CONFIG_BS role.
{
"count":13,
"items":[
{
"key":"TaskBasedPostConfig:NEW_BUSINESS_SERVICE_REQUEST",
"sourceObjId":1,
"sourceObjName":"System",
"sourceObjType":"SYSTEM",
"value":"1=TASK_COMPLETE_CONFIG_BS",
"url":http://host:8183/cloudmanager-api/system/integrationconfigitems/key
}
…
] }
|
|
/<domID>/integrationconfigitems/{key} |
GET |
Purpose: Gets the callout-specific configuration for the specified key and domain object. The “value” tag of the payload is specific to the callout. Payload:
{
"key":"TaskBasedPostConfig:NEW_BUSINESS_SERVICE_REQUEST",
"sourceObjId":1,
"sourceObjName":"System",
"sourceObjType":"SYSTEM",
"value":"1=TASK_COMPLETE_CONFIG_BS",
"url":http://host:8183/cloudmanager-api/system/integrationconfigitems/key
}
|
|
/<domID>/integrationconfigitems/{key} |
PUT |
Purpose: Sets or modifies the callout-specific configuration for the specified key and domain object. The “value” tag of the payload is specific to the callout. Payload:
{
"key":"TaskBasedPostConfig:NEW_BUSINESS_SERVICE_REQUEST",
"value":"1=TASK_COMPLETE_CONFIG_BS",
"url":http://host:8183/cloudmanager-api/system/integrationconfigitems/key
}
|
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"
}
]
}