Plug-ins for systems connect the Orchestrator workflow engine to an external system so that you can orchestrate the external system.
Following are examples for plug-ins for systems.
- vCenter Server plug-in
- Lets you manage vCenter Server instances using workflows.
- vCloud Director plug-in
- Lets you interact with a vCloud Director installation within a workflow.
- Cisco UCSM plug-in
- Lets you interact with Cisco entities within a workflow.
Following are the main characteristics of plug-ins for systems.
- Plug-ins for systems have a higher level of complexity than general-purpose plug-ins, because the technologies that they expose are relatively complex. Plug-ins for systems must represent all the elements of the external system inside Orchestrator to interact with the external system and offer its functionality in Orchestrator. If the external system provides an integration mechanism, you can use it to expose the functionality of the system in Orchestrator more easily. However, besides representing the elements of the external system in Orchestrator, plug-ins for systems might also need to offer high scalability, provide a caching mechanism, deal with events and notifications, and so on.
- Plug-ins for system are medium to big in size. Plug-ins for systems require many classes apart from the basic set of classes because usually they offer a large number of scripting objects. Plug-ins for systems might require some other helper and auxiliary classes that will interact with them.
- Usually, plug-ins for systems have a large number of objects, and you must expose these objects properly in the inventory so that you can locate them and work with them easily in Orchestrator. Because of the large number of objects that plug-ins for systems need to expose, you should build auxiliary tool or a process to auto-generate as much code as possible for the plug-in. For example, the vCenter Server plug-in provides such a tool.