We will now look at all the plugins that come pre-installed in Orchestrator. We will be looking at these recipes:
Working with XML
Working with SQL (JDBC)
Working with SQL (SQL plugin)
Working with PowerShell
Working with SOAP
Working with Active Directory
Working with SNMP
Working with AMQP
By now you are aware of the importance of plugins and how they expand the capabilities of Orchestrator. The next parts of the book will focus on plugins that were firstly touched upon in Chapter 9, Essential Plugins, where we discussed some of the very essential plugins. Here, we will go over all the plugins that are pre-installed in Orchestrator, while future chapters will show additional plugins and then finish on the vCenter plugin, which will round off the possibilities for expansion.
We have already had a look at the return values of the REST plugin, but there are also the return values of the SOAP and PowerShell plugin to look at. All of them are a bit more complex than just a string. A lot of the return values are either JSON, XML, or Arrays of Properties. In the JavaScript complex variables recipe in Chapter 6, Advanced Programming, we showcased how to harness them.
The most important thing to figure out is the information you really need for...
In this recipe, we explore how to use the XML plugin to create and phrase XML structures with Orchestrator. XML is a good way to exchange complex information between systems.
We don't need anything special; however, we need to understand the basics of XML. Take a look at http://www.w3schools.com/xml/ .
You should be familiar with the JavaScript concept of functions (see the introduction to this chapter).
This recipe is split into two parts; first, we create an XML document, and then phrase an XML document.
This is the rather more complex part; however, we will go through it slowly.
We will create a simple XML document that looks like this:
<?xml version="1.0" encoding="UTF-8">
<MailMessages>
<Mail>
<From>test@test.net</From>
<Subject>Test message</Subject>
<Content Date="10/12/12">This is a test message
</Content> &...This recipe focuses on the interaction between Orchestrator and an SQL database using the Java database connector (JDBC). You will learn how to send SQL queries as well as commands to a database.
Obviously, we need a database. This database can be PostgreSQL, MS SQL, Oracle, or MySQL. For testing, you can use the PostgreSQL database that is implemented in the appliance (refer to the Tuning the appliance recipe in Chapter 2, Optimizing Orchestrator Configuration). Also, take a look at the There's more... section of this recipe.
We will use a Microsoft SQL 2008 R2 database in this example; however, the steps are the same for all databases. The database we will be using is called testDB.
You will need an existing database and a user who is able to create/drop tables as well as insert/delete information, for example, the DBO role.
In this recipe, we will explore the SQL plugin to work with SQL. This is a bit different from the JDBC recipe.
Obviously, we need a database. This database can be PostgreSQL, MS SQL, Oracle, or MySQL. For testing, you can use the PostgreSQL database that is implemented in the appliance (refer to the Tuning the appliance recipe in Chapter 2, Optimizing Orchestrator Configuration). Also, take a look at the There's more... section of this recipe.
We will use a Microsoft SQL 2008 R2 database in this example; however, the steps are the same for all databases. The database we will be using is called testDB.
You will need an existing database and a user who is able to create/drop tables as well as insert/delete information, for example, the DBO role.
In this recipe, we will enable Orchestrator to execute PowerShell scripts on a Windows host and deal with the results.
We need a Windows host where the PowerShell scripts are stored and can be executed from. This can be any Windows host; however, a Windows 2008 R2 (or better) server contains all the programs required to allow Orchestrator to connect to the Windows host.
To configure the Windows host, we need to use Windows Remote Management (WinRM), which is already installed and integrated into Windows.
Installing the VMware PowerCLI add-on to PowerShell on the Windows host is optional.
You may also add a Linux PowerShell host to vRO. Check this: http://kaloferov.com/blog/how-to-add-a-linux-machine-as-powershell-host-in-vro-skkb1030/
This recipe focuses on the interaction between Orchestrator and a SOAP-based server. We will learn how to add a SOAP host to Orchestrator and execute SOAP operations.
We need a host that can present SOAP operations for Orchestrator to use. If you don't have a SOAP host that you can access, you can follow our example.
Orchestrator's SOAP API has been retired and is not available anymore.
To add a SOAP-based service to the Orchestrator host, we need its WSDL address.
For our example, we will use http://www.webservicex.net to test our SOAP plugin. The WSDL we will use is http://www.webservicex.net/globalweather.asmx?WSDL .
Again, this recipe is split into different parts.
In this recipe, we will look at how Orchestrator uses the Active Directory (AD) plugin.
We split this recipe into multiple parts.
You can add AD to Orchestrator without using SSL; however, you will not be able to create users, change passwords, or use any other more secure options. If you decide not to use SSL, skip this step.
First, we will install Active Directory Certificate Services.
Microsoft does not recommend that you run a CA server on a domain controller; however, for a lab, it is totally okay.
To activate SSL for AD, follow these steps:
Log in to the Windows server that will host the CA. In my case, this is my domain controller, central.mylab.local, with domain administrator rights.
Add the Active Directory Certificate Services server role.
Just click on Next and accept all the default settings. In the following screenshot,...
This recipe centers on SNMP. Here, you will learn how to use Orchestrator to receive SNMP traps from vCenter/ESXi and use them to trigger workflows.
For this recipe, we need an SNMP source. We will use vCenter and ESXi hosts as SNMP sources.
To prepare vCenter and ESXi servers to send or receive SNMP messages, refer to the There's more... section of this recipe.
We will split this recipe into configuring and using SNMP with Orchestrator.
To configure Orchestrator to send or receive SNMP messages from SNMP devices, follow these steps for each SNMP device:
In Device address, enter the IP or FQDN of the device you want to send or receive SNMP messages to/from.
In the Orchestrator Client, start the workflow by navigating to Library | SNMP | Device Management | Register an SNMP device.
Name is just a string to identify the SNMP device in the inventory.
The Advanced function is the configuration that is used to send SNMP messages....
This recipe demonstrates how to use Orchestrator as a producer and consumer of AMQP message queues, how to create a subscription, and how to use Orchestrator policies to react to messages in the queues.
If you are totally new to AMQP, I suggest you start reading the How it works... section first.
An AMQP broker such as RabbitMQ is required. You can download it from http://www.rabbitmq.com . You can find a fast and easy Windows installation and configuration for RabbitMQ in the There's more... section.
As with SOAP, REST, and a lot of other modules, we can actually use the provided workflows. So in the following sections, we will make use of them.
To start with AMQP, we first need to add an AMQP broker to Orchestrator:
Start the workflow by navigating to Library | AMQP | Configuration | Add a broker.
Give the connection a name.
Add the broker IP or FQDN; the default port is TCP 5672.
Virtual host (vhost) is always in a freshly installed...
© 2016 Packt Publishing Limited All Rights Reserved
