Default Workflows

Description of Policy Manager service, contract, and policy default workflows.

Table of Contents

Introduction

The Policy Manager default installation installs three default workflow definitions for services, contracts, and policies.

  • Default Workflow Definitions are hard coded into the Policy Manager back-end to facilitate Workflow Reset and are also copied to the \config\workflow_definition_templates folder of the Policy Manager release directory.
  • Custom Workflow Definitions can also be stored in this directory.
  • The default workflow definitions provide standard Workflow processes for service and contract management and serve as a tutorial for understanding the construction of a Workflow Definition and the elements of the Workflow Library.

Using Workflow Definitions

This section provides a brief overview of the elements of a workflow definition. Refer to the OSWorkflow documentation for more information on OSWorkflow concepts.

A workflow definition is broken into several sections as follows:

Initial Actions

The Initial Actions section of a workflow definition XML file includes <initial-actions> </initial-actions> constructs. These constructs include <action id> entries that include action names that trigger the initialization of the Workflow. Workflow definitions for services and contracts have a unique set of initial action names.

Service Initial Actions

Initials actions in a service-specific Workflow Definition include @create, @discover, and @reset.

If you attempt to upload a Workflow Definition in the Services Workflow Administration section that does not include this set of initial actions you will see the following error message:

Not a valid "service" workflow definition. Cannot find initial actions @create, @discover, and @reset.

Additional information about these initial actions:

  • @create is initialized when a new service is created in Policy Manager using the Create Physical Service Wizard.
  • @discover is initialized when a service is discovered on an application server. In this scenario your Policy Manager deployment is configured with an application-specific Container.
  • @reset deletes existing active Workflow Instances and new Workflow Instances are created based on the Workflow Definition being uploaded.

Note: Each time you perform a reset, you must reload the Workflow Definition.

Contract Initial Actions

Initials actions in a contract-specific Workflow Definition include @CreateOffer, @CreateRequest, and @reset. If you attempt to upload a Workflow Definition in the Contract Workflow Administration section that does not include this set of initial actions you will see the following error message: Not a valid contract workflow definition. Cannot find initial actions @CreateOffer, @CreateRequest, and @reset.

  • @CreateOffer is initialized when a Provider Organization creates a contract.
  • @CreateRequest is initialized when a Consumer Organization creates a contract.
  • @reset deletes existing active Workflow Instances and new Workflow Instances are created based on the Workflow Definition being uploaded.

Note: Each time you perform a reset, you must reload the Workflow Definition.

Initial actions section of default_contract_workflow.xml

Policy Initial Actions

Initials actions in a policy-specific workflow definition include @create and @reset. If you attempt to upload a Workflow Definition in the Policy Workflow Administration section that does not include this set of initial actions you will see the following error message:

Not a valid "policy" workflow definition. Cannot find initial actions @create, @ImportPolicy, @ActivatePolicy, and @reset.
  • @create is initialized when you create a policy.
  • @ImportPolicy is initialized when a you import a policy.
  • @ActivatePolicy is initialized when you activate the policy workflow. Note that out-of-box system policies are activated as part of the default Policy Manager installation.
  • @reset deletes existing active workflow instances and new workflow instances are created based on the workflow definition being uploaded.

Steps—Actions—Conditions

After the processes of the initial action are complete, the Workflow then begins to execute the steps, actions, and conditions defined within the <step> </step> construct. In this section of the Workflow, each step represents a Workflow process. Each step is represented as a <step id> and is assigned a step number (for example, 100, 200) and name (for example, Draft).

Each step also includes an owner that represents the individual who is granted access to perform the action(s) defined in a step. An owner is specified as follows: owner=${caller} where caller represents the user account id of the individual who is granted access to perform the actions in the step.

Within each step there are Actions that include conditions, restrictions, and results. All the workflow action states mirror different tasks and how they function in Policy Manager.

Default Service Workflow

Click here to view the Default Service Workflow.

Default Contract Workflow

Click here to view the Default Contract Workflow.

Default Policy Workflow

Click here to view the Default Policy Workflow.