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 Table C-1:
Table C-1 Cloud Manager Workflow Phases
|
Workflow Phase (Action Type) |
Operation Type |
Default, Task Based Callout |
Customizeable by Using Callouts |
|---|---|---|---|
|
N/A |
No |
No |
|
Approval |
Yes |
Yes |
|
Configuration |
Yes |
Yes |
|
Approval |
Yes |
Yes |
|
N/A |
No |
No |
|
Configuration |
Yes |
Yes |
|
Approval |
Yes |
Yes |
|
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.
Approval: For Approval type operations, the completion status is either Approved or Denied.
Configuration: For Configuration type operations, the completion status is either Success or Failure.
Notify: 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 the TaskBasedCallout 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.
After you have created a custom callout, you can invoke a REST API call to actually register a callout in Cloud Manager. The registration defines a combination of conditions that, when they are 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 or step of the callout in the workflow:
Approval
PreConfig
PostConfig
PostApproval
PreDeploy