Introduction

One of the useful things that you can do with an IBM Concert Workflows workflow is to execute SSH commands to retrieve status, restart services, run commands, etc.  In this article, I will cover how to pass different variables that you define within CW's Start block into a SSH command using the CW SSH block.

The Scenario

I want to create a "Service Control" workflow that allows someone to check and control the status of certain running services on a linux system without having to manually login and do so.

Steps Involved

1. I need to define an "Authentication" entry for my SSH request, telling my workflow which system to run the SSH command on.
2. I need to define some variables in the CW workflow Start block
   • I will need a "service name" variable
     • type: enum
     • values: ["snmpd"] only for this example
     • default value:  "snmpd"
   • I will need a "command" variable
     • type: enum
     • values: ["status","start","stop","restart"]
     • default value: "status"
   • I will use the pre-defined $result variable to populate the result of my SSH command.
3. I need to define the command in the SSH_1 block that I will be executing:

   • On the linux command line, I would check the status of the snmpd service using the following:  systemctl status snmpd

4. Once I run the command, I'll need to update the $result variable so I can log the result for the user to see.

Let's do it!

I first start with a new empty workflow:

Notice "result" is already there.  No adjustments needed for that one.

We create our two variables "service_name" and "command" and set the default settings for each.  We also check the "In" box for each, allowing us to pass different values into these variables (e.g. I want to restart the snmpd service, not just view status".

We want to control what the user can do and which services they have access to.  To do this, for the two variables we just created, we change the type to "enum" and then define the acceptable parameters for each.

For our "service name" variable we use the following, adding only "snmpd" to the list of options:

For our "command" variable we provide the allowed commands in the list:

Next, let's add a SSH block to our workflow.  It's found in the "Common"->"SSH" API endpoints list.

Here we will add the "authKey" setting using the "Authentication" we defined (not pictured here).

Then we will add our command, using Javascript syntax:

"systemctl " + $command + " " + $service_name

Notice we include spaces between our "systemctl" command and the variables to mimic how we would type it on the command line.

Finally, we are ready to assign the result of our SSH_1 block to the $result variable for viewing.

Let's run it and glory in our success!  The workflow will get the status of our snmpd service if all goes well!

Hmmmm!  All didn't go as expected.  Let's see what happened and how to fix it.

Going into "Flat Layout" mode, we can look at our SSH_1 block to see how the command is configured.

We notice that the command type is set to "C" for const.  I the SSH block we need the command to use type "f" for  expression.  This will cause the SSH block to read in the variable values when it runs.

Let's change it to use type "expression":

Once we make the change, we need to clean up the syntax a bit.  You will notice that all of the quote (") characters have been escaped using the backslash character.  Also the entire command has been enclosed in an extra set of quote (") characters.

Let's remove those:

Now let's try re-running our workflow to see if our luck is any better!

Success!

The workflow is now working correctly!

Using an Automation Center tile

You can create an Automation Center tile to provide users with a small UI interface to interact with your new workflow.

The user is limited to the service name and the commands that you added to your "Enum" list back in the Start block.

I hope you found this article useful and will help you quickly speed through your workflow development when it requires the use of the SSH block!

#TechnicalBlog