The Cisco Process Orchestrator has very rich integration capabilities, yet we often hear the question, "Does it integrate with..." or "Does it work with" [insert product]. The Cisco Process Orchestrator is a primary component in the Cisco Intelligent Automation for Cloud management solution.

The fact is that in modern environments with modern orchestrators the answer is always yes. The reality is that cloud automation requires a Process Orchestrator tie into a variety of different systems in order to start offering cloud services. Remember, Cloud is an operating model, not a product. This means that to deliver self-service, on-demand services requires all the elements of the service be orchestrated.

Cisco's internal private cloud is one such example.

The graphic below shows the components in the deployments. You see integration with Cisco UCS, VMware and storage, as you would expect. It also orchestrates IP address management (that IP won't provision itself), Remedy incident, CMDB, ActiveDirectory (so tenants can log in), image management and a few other things such as Service Assurance.

By the way, the architecture below is Cisco Process Orchestrator provision across multiple Cisco data centers.

 Here's a quote from our knowledge base about our integration capabilities.

It's been a long time since we encountered a product with which we cannot integrate. A common response with the list of packaged integrations is for customers to look at it as a list of applications with which PO can integrate.  It is not.  Many of the existing PO adapters are designed to make PO open to say "yes it can" in integration scenarios, so just because an integration is not on the list, does not mean PO cannot integrate with it. Through these features, PO can provide integration with most IT tools without requiring any special purpose-built adapter:

• CLI invocations -Most IT tools have some type of command line that provides integration.  For example, integration with an enterprise job scheduler would typically be performed through its CLI.  The PO CLI allows invocation from these tools into PO.
• Web Service integration -PO supports both SOAP and REST based web services.  Where more sophisticated integrations are needed than CLIs allow, modern applications typically provide web services.  For integration with application APIs which are not web service based, one can easily write a shim which exposes a web service to PO and makes the native API call with any technology.
• Support SNMP Integration -PO allows sending SNMP traps for its Tasks such as alerts, incidents, change requests, and approvals.  This capability can be used to integrate generically with event managers.  PO also provides further SNMP implementation capabilities to support for SNMP-based integrations.  PO also supports SNMP gets, puts, and can trigger processes in response to incoming traps.
• Windows Event Logs -PO has an activity to write Tasks to the Windows event log.  Microsoft supplies a command line to write generic events to the event log which can be invoked by PO.  Since most enterprise IT systems management tools can read Windows logs, this suffices for event integration with many systems management purposes.  PO can also consume logs that other products publish.
• Windows Management Instrumentation -PO's Publish Metrics activities not only publish metrics to the PO database for reporting, but also publish metrics to WMI.  This facilitates open integration of performance data with IT tools.
• Email -many IT tools can send emails for notifications.  One can leverage these mechanisms to send data about important events to PO, and PO's email trigger can be used to initiate a process when the email arrives.  Conversely, many IT applications can receive emails.  For example, many service desks can create an incident from an incoming email.  PO can send an email from within a process to leverage these integration mechanisms in other products.
• Scripting support -on Windows, Linux, and UNIX, PO has the ability to run scripts.  Often more sophisticated functions like calling a COM or Java object are possible via scripting.
• Messaging / Event integration support via Process Events.

• Creation or importing of external files -often systems support Export Transport Load scenarios for integration.
• Also native adapters to Cisco UCS, Network Services Manager, VMware, vCloud, Remedy, SAP, ActiveDirectory, SAP BI,, Oracle DB, MS SQL, JDBC

All of these provide integrations that can be built within process definitions.  Aspects of integration can be placed in reusable child processes and then re-used across processes.  For example, a process that invokes an EMC SAN job can be placed in a process "Invoke EMC SAN Job" with parameters that specify the job name and parameters, then that process can be invoked.

This one of the important differentiating features of our orchestrator: We can take a workflow, encapsulate it, and it will be have as an adpater. This means the next person can use it as an atomic activity. This is what we are doing with our free, open automation packs like the ones that integrate with vCloud, Openstack, and Amazon EC2. Code and demos at our Solution Accelerator Community.

The challenge, then, is to not allow customers to view the list of integrations as a list of possible integrations.  Instead, they need to evaluate the interfaces present, see if they are covered, and if so, answer "yes we can."

In other words, when evaluating whether the Cisco Process Orchestrator will work with a device or software, the first question is: what kind of interfaces does that tool / device offer.

via PO Integrations and Automation Packs -Cisco Support Community. 

Here's a demo showcasing the capabilities Cisco Intelligent Automation for Cloud (including CIsco Process Orchestrator) has to manage cloud services on any combination of platforms: https://youtu.be/gRYYElKdN-M