Cisco Cisco Process Orchestrator 3.0 Guida Utente

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.

Targets and target types have events. These can be internal process events or the open Advanced 
Message Queuing Protocol (AMQP) protocol. Triggering processes in response to patterns in 
underlying processes provides policy.

Extensible by services, partners, customers. The content, not the platform, defines service 
models. The platform is open to model any IT service topology within automation content. For 
example, some types, actions, properties, etc. may come from the packaged product, some from 
team 1, some from team 2, some from a partner, and some from a customer. Using this capability 
you can assemble a complex solution from parts. Each author controls the version control and 
lifecycle of the elements they deliver so they can deliver upgrades.

A consistent API, even if elements come from different authors. Users and automation pack authors 
(see 

) can control which target types are published to the NorthBound 

Web Service (NBWS; see the Northbound Web Services Guide). For published objects, Process 
Orchestrator exposes the type uniquely in the NBWS. As content teams, services, partners, or 
customers extend types, these APIs are maintained to provide a consistent format for APIs across 
all types of objects. However, each type of object is uniquely supported. 

Authors can also configure which properties are exposed in the NBWS as optional parameters in the 
per-type WSDL.

While Service-Oriented Automation is open, allowing any model, it aligns to IT best practices such as 
the IT Infrastructure Library (ITIL). ITIL prescribes a configuration management database (CMDB) as 
a central tenet which allows high level services to be decomposed into their supporting lower level 
services and ultimately to the lower level systems and devices. In ITIL, each element in the model is 
called a Configuration Item since it is a unit of configuration. This provides a mapping of how lower 
level elements support business services. Service-Oriented Orchestration allows automation to be driven 
through a model of current and desired IT services, aware of their relationships and interdependencies. 
In this aspect, the principles of service modeling are substantially the same as modeling services within 
ITIL and CMDBs. 

However, the implementation bypasses many of the negatives and weight of typical CMDB 
implementations. Process Orchestrator can integrate with a CMDB if it is there. Targets provide a natural 
synchronization point to exchange data with a CMDB, and target events allow that synchronization to 
be externalized from other processes. However, Service-Oriented Orchestration does not require a 
CMDB; one does not have to have a CMDB to enable orchestration to function. Often orchestration 
needs a reduced model vs. what is in the CMDB, and it is therefore much easier to keep the smaller data