Cisco Cisco Process Orchestrator 3.1 User Guide

Data defines desired services, and the service instance drives automation to achieve the desired state. 
This separates the desired state from the implementation (the “what” from the “how”).

It acts on the higher-level service rather than its technology elements. Services can span tools, and 
workflows can navigate service topologies to lower-level elements on which they act.

It provides operational views of automation by service.

It lets you monitor the environment vs. the service definition and bring them in line with policy.

It provides federated storage, including push objects and relationships to and from Service Catalog, 
CMDB, and Service Assurance tools when needed.

Automation becomes easier to extend and customize.

Several features in Process Orchestrator combine to bring these capabilities: 

Service instances are targets. A target type allows you to define a new service; all new targets are 
created based on a target type. Target types can be based on the DMTF Common Information Model, 
but this is not required.

Target types are service definitions that allow Process Orchestrator to deliver service-oriented 
automation, where the service, not the process, is the focal point. In service-oriented automation, 
the content, not the Process Orchestrator platform, defines the solution models; the platform is open 
to any model you want to produce. 

Some target types can be ‘abstract’, meaning they cannot be directly instantiated into targets but are 
only available for inheritance by other target types. In Process Orchestrator, these target types are 
marked as either ‘creatable’ or ‘not creatable’.

Target types support inheritance, which allows you to extend a general type for a specialized need. 
In Process Orchestrator, you can select a ‘base target type’ for a target type that specifies that the 
target type inherits from the base target type.

Target types have an extensible list of properties including field-customizable default values.

In these properties, data can be stored that might come from Process Orchestrator in terms of 
defining an order or a desired state, or might include data that is collected from the environment. 
For example, periodic network device discovery can store information such as the operating system, 
version, which line cards are installed, and so on. Network automation can use that information in 
its workflows.

Relationships allow modeling of topologies of lower level services assembled to offer higher-level 
services; that is, relationships allow lower-level objects to be bound together to achieve a larger 
whole. Automation can navigate from a higher-level object, such as a service, to lower-level objects 
against which they can perform automation.

Relationships allow you to navigate from one object to another in a workflow.

Target types define the property that models the relationship.

Target instances provide the link to a specific instance.

Relationships support inheritance.

Relationships can be set in the northbound web service like any property.

Processes provide actions that can be executed against targets. Process Orchestrator allows you to 
view a target to see what actions are possible, or what automation is being done against those targets.

The target types that a process can accept define the services on which a process can act.