vRealize Orchestrator

vRealize Orchestrator – using Telnet to test port connectvitiy

vRealize Orchestrator has a TelnetClient scripting class that you can use to test port connectivity. This is far easier to use than dropping to a telnet client on a cli and test connectivity that way. Together with using the TelnetClient scripting class and a workflow that would loop and wait for the port to be open, fail gracefully or continue the workflow but notify that connectivity wasn’t available, the options the TelnetClient scripting class gives you are very handy.

Here a screenshot of what the scripting class looks like in the API browser:

Screen Shot 2015-03-08 at 11.19.18

The constructor looks like this:


var telnet = new TelnetClient(string)

The parameter is a string and takes a terminal type, which be default is VT100. Other terminal types would be ANSI, VT52, VT102, VTNT and so on. VVT stands for video terminal so mostly you can use the default value of VT100.

Here is some simple code to test telnet connectivity:


var port = 22; // number
var target = "localhost"; // string

try {

// testing for port connectivity on target host
System.log("Trying to connect to port " + port + " on host  " + target);
var telnet = new TelnetClient("vt100") ;
telnet.connect(target, port);
connectionSuccess = telnet.isConnected();
System.log("Connectivity to target host " + target + " is successful")

} catch (e) {

connectionSuccess = telnet.isConnected();
System.log("Connection failed: " + e)

} finally {

telnet.disconnect()

}

The isConnected() method returns a boolean of true or false, depending on the connection result, so together with this block of code and a loop workflow, you can test connectivity to a telnet port or wait for a socket to be up. Using a try / cath / finally statement, you catch any errors and disconnect appropriately, although strictly speaking disconnec() can go in the try statement as you’ll only ever connect in the try block so you can only ever disconnect there as well. Skin a cat in several ways on that one. Up to you 🙂

Here’s a screenshot of a workflow that puts it all together. The decision just checks for true or false which is set depending on the connection response.

Screen Shot 2015-03-08 at 11.27.05

Obviously in the sample code above, you should configure the inputs appropriately for the target and the port. This is also a good way to check if a service is available, for example check for SMTP or a REST API service by using telnet.

Happy telnetting!

references:

http://goo.gl/f7NqqR
http://goo.gl/v8QZA

workflow:

http://goo.gl/cOLz8d

Advertisements

vRealize Orchestrator – connecting to more than one domain using the Active Directory plugin

  1. The vRealize Orchestrator plugin only supports connecting to one active directory domain so what happens if you want to connect to more than one domain to create a user or an organizational unit? Well, it is possible to refocus the active directory plugin on the fly to do just that but you need to consider how this will work in your environment and design your AD workflows appropriately.

    Firstly, lets take a look at the vRO Active Directory plugin ‘Configure Active Directory server’ workflow that configures the plugin to connect to a domain.

    Screen Shot 2015-03-08 at 14.21.03

    When you run the workflow to add a domain, you are presented with the following form:

    Screen Shot 2015-03-08 at 14.23.08

    Now you can relate these presentation inputs to what is going on inside the workflow. So the first scripting element in the workflow determines whether you are using SSL and the second workflow element imports the certificate if you are.

    The reason why I mention this is that if you are using SSL for LDAP connectivity, it’s worth importing all your domain SSL certificates into vRO so vRO can use a valid certificate if you are to refocus the plugin to connect to a domain over SSL.

    Now if we take a look at the ‘Update configuration’ scripting element, you can see the following code:

    
    var configuration = new AD_ServerConfiguration();
    configuration.host = host;
    configuration.port = port;
    configuration.ldapBase = ldapBase;
    configuration.useSSL = useSSL;
    configuration.defaultDomain = defaultDomain;
    configuration.useSharedSession = useSharedSession;
    configuration.sharedUserName = sharedUserName;
    configuration.sharedUserPassword = sharedUserPassword;
    
    ConfigurationManager.validateConfiguration(configuration);
    ConfigurationManager.updateConfiguration(configuration);
    
    

    So what you can do is run this specific block of code to connect to another domain each and every time time you want to do domain operations in a specific domain in a multi-domain environment. It’s best to use a configuration element to store your domain information and by using some logic, you can determine what domain you want to use and then use the values in your configuration element to populate the required domain configuration values in the block of code above.

    However, there is one absolute key thing here to implement and that is design your workflow using the LockingSystem scripting class. Any workflow that needs to configure active directory objects will need to run the block of code that refocuses the domain connection to use, then run a workflow to create, update, read, delete AD objects. So you need to let workflow operation finish first before allowing another workflow change the focus of the domain that you are connecting to. You can do this using the LockingSystem scripting class, example as follows:

    Screen Shot 2015-03-08 at 14.39.09

    So the set lock would look like this:

    
    LockingSystem.lockAndWait("AdOperationLock", workflow.id);
    
    

    Then once the lock is set, the refocus domain code runs and you can change to a different domain,  then run an AD operation, then remove the lock. So the remove lock would look like this:

    
    LockingSystem.unlock("AdOperationLock", workflow.id);
    
    

    You can have multiple workflows using this locking system, as long as the lock you use is called the same, in other words “AdOperationLock” in the example above.

    Also, you could use an action item to lock and refocus the domain connection and use the action item for any workflows you are calling that run AD operations, making the locking and refocus aspects modularized. Remember to unlock the lock and to use the same lockid name, for example “AdOperationLock”.

    There are limitations with this as you can only ever run one workflow to read / configure / delete active directory objects at any one time as you can’t have refocusing happen when existing AD operation workflows are running. However, most of the time active directory updates are generally small operations and the workflows should run pretty quick. Therefore, if you do have a lot of AD operations, the likelihood is that you should only have a few seconds to wait until your workflow in waiting runs – workflows check every 2 seconds to see if the lock it has has been released in the vRA database, so the length of time the workflow in waiting will have to wait before it runs will be 2 seconds max plus the length of time the current workflow execution time is. However this is something you need to consider in your environment.

    There are other solutions in a multi-domain environment, for example using PowerShell scripts, but if you can keep it all in vRO, you can keep all the code in one place, and create modular workflow elements for AD operations, then it’s one less programming language and dependancy to manage in vRO.

vRealize Orchestrator – VCO CLI setup and use cases

I wanted to understand how to get more of a IDE user experience when using vRealize Orchestrator and a colleague mentioned the VCO CLI tool found here – https://labs.vmware.com/flings/vco-cli. Its a plugin you install via the vRO configuration and a batch file that launches a vCO CLI GUI. Whilst I wouldn’t classify the VCO CLI tool and a classic IDE or a tool that you should develop workflows in, it does offer IDE auto complete to 2nd level and deeper methods, attributes and properties, whereas the vRealize Orchestrator client only offers top level IDE autocomplete on object types it knows about configured as inputs or attributes.

vCO CLI setup

To set up the VCO CLI tool, you need java 1.7 installed (although I’ve not tested with other versions). It’s also important you have you java home directory set in your environment variables.

Screen_Shot_2015-03-08_at_18_45_56

Then download the VCO CLI package and install the plugin using vRO Configurator

vco-plugin

Then once you have the plugin installed, you need to then open up the vRealize Orchestrator and run the vCO CLI Start Session workflow:

Screen Shot 2015-03-08 at 19.20.12

Once you have a session started, you can then connect to that session when you run the vCO CLI GUI. To run the vCO CLI GUI, go to the folder you have downloaded and unzipped the vCO CLI zip file and run the vcocli-gui bat file. This should open up the vCO CLI GUI tool.

Screen Shot 2015-03-08 at 19.16.26

Click on the attach button and a window will appear listing all the open sessions that are available to connect to and you should see the one you started when you ran the vCO CLI Start Session workflow.

vco-cli-session

This should now open the vCO CLI GUI tool. (click to enlarge)

Screen Shot 2015-03-08 at 20.03.41

Using vCO CLI

So now we have a vCO CLI client running, we can see how the nested dot notations work. Take this code for example:


var catItems = Server.findAllForType("vCACCAFE:CatalogItem");

for each (var catItem in catItems){
catItem.name + " " + catItem.status.value();
};

When using the vCO CLI tool, we get auto complete on the available attributes and methods. Here’s a screen shot showing an example with the code above:

Screen Shot 2015-03-08 at 19.43.24

auto complete of catItem

Screen Shot 2015-03-08 at 19.44.16

auto complete on catItem.status

If you look at the API browser, you’ll see the same methods and attributes.

Also,  check the output of the code when I run it. This appears in the output window in the vCO CLI GUI.

Screen Shot 2015-03-08 at 19.46.43

You can see that is outputs the results without having to use the System.log() method.

If I try to use auto complete on catItem in vRealize Orchestrator like I have done in vCO CLI, I just get the old familiar error message:

Screen Shot 2015-03-08 at 19.48.07

Great!

So my conclusion is that the vCO CLI tool is really good if you want to write code quickly without having to browse the API explorer or keep using System.log() to see the output. What this can do is make writing code quicker, however it’s not a substitute to vRealize Orchestrator and you have to cater when using the object types by using Server.findAllForType(“vCACCAFE:CatalogItem”), where in vRealize Orchestrator we can use inputs or attributes and specify our type there and we do get auto complete on these object types and scripting classes in vRealize Orchestrator, but only at the top level. So having said that, I would love to see this type of auto complete feature that is offered vCO CLI in the vRealize Orchestrator client and then everyone’s a winner, well apart from the vCO CLI GUI 🙂