Plug-ins for services or general-purpose plug-ins provide functionality that can be considered as a service inside Orchestrator.

Figure 1. Architecture of plug-ins for services

Plug-ins for services

Plug-ins for services expose generic libraries or utilities to Orchestrator, such as XML, SSH, or SOAP. For example, the following plug-ins that are available in Orchestrator are plug-ins for services.

JDBC plug-in

Lets you use any database within a workflow.

Mail plug-in

Lets you send emails within a workflow.

SSH plug-in

Lets you open SSH connections and run commands within a workflow.

XML plug-in

Lets you manage XML documents within a workflow.

Plug-ins for services have the following characteristics.


Plug-ins for services have low to medium levels of complexity. Plug-ins for services expose a specific library, or part of a library, inside Orchestrator so as to provide concrete functionality. For example, the XML plug-in adds an implementation of a Document Object Model (DOM) XML parser to the Orchestrator JavaScript API.


Plug-ins for services are relatively small in size. They require the same basic set of classes as for all plug-ins, and other classes that offer new scripting objects to add new functionality.


Plug-ins for services require a small inventory of objects to work, or they do not require an inventory at all. Plug-ins for services have a generic and small object model, and so, they do not need to show this model inside the Orchestrator inventory.