Tag Archives:processes

Here’s a tip that might be helpful the next time you want to kick off deployments automatically or repeatedly in IBM UrbanCode Deploy: you can use the REST API to request processes directly from the server. From there, you can run the process repeatedly or trigger the processes from an external script or application.

Last week I posted about how to pass a property from one step to another using output properties and post-processing scripts. That technique works fine for simple things, but working with post-processing scripts can get clunky if you’ve got a lot of properties or a lot of steps.

There’s an easier way to pass properties between steps, if you’re willing to write some Groovy code. The Run Groovy Script step runs some Apache Groovy code, which is an easy-to-learn scripting language.

Here’s an example that uses two steps. The first step, a Run Groovy Script step named “Create URL value”, runs some Groovy code. The code ends in the command outProps.put("url", targetUrl), which creates an output property named “url.”

outProps.put("url", targetUrl)
Now you can refer to that output property in later steps with the syntax ${p:Run Groovy Script/url}. A simple way to refer to that property is with a Shell script and the code echo ${p:Run Groovy Script/url}, but you could just as easily use the property reference in any other step. Here’s the complete process, with the first step creating the output property and the second step referring to it:

That’s all there is to it — passing properties from step to step with Groovy just takes a little code.

We get a lot of questions on the forum about how to pass information from one place to another in IBM UrbanCode Deploy. Here’s a particular use case that comes up from time to time: passing a value from one step to another. Ideally, you don’t “pass” variables from one step to another. It’s better to put the info in properties (like environment properties) because then the info is persisted and available long-term in the appropriate scope.

But for small things, you might want to grab a value from one step’s output and refer to that value in later steps. For example, suppose that you want to take a value from a log file, output file, property file, or command output and use it later. To do that, you create an output property in one step and refer to that output property in later steps.

Here’s a simple generic process that has three steps. (This would work in a similar way in component processes, but application processes don’t use output properties like this.) I’m using Shell steps, but this technique works with a lot of other step types, particularly Groovy steps – more on that some other time.

Step 1: Write a value to a file.
Step 2: Retrieve a value from that file and store it in an output property.
Step 3: Print a message that uses the output property from step 2.

Step 1 is pretty simple: I’m using the Linux echo command to write this string to a file: myMessage=Hello!. I’m just writing this text so I’ll have info to read into a property in step 2.

Step 2 is where I create the output property. There are two parts to doing that: first I have to get the value I need out of the file, and then I have to put that value in the output property. There are lots of ways to get the info that I want to put into an output property. And again, you can use this technique to access values in log files, output files, property files, or command output in the same way. In this case, I’m using the Linux grep command to search for the string “myMessage” in the file I created in step 1.

The important part is that the value I want shows up in the step output log. That’s where I’ll grab the value and put it in an output property. To see the output log of a step after you run the process, find the process request and then click the Output Log icon.

Here’s what the step log looks like after I run the process. In this log, the grep command found the string in the file and printed out the line that it found:

That line after “command output:” is the output of the grep command. So I’ve got the info that I need.

Next, I have to put that value into an output property so later steps can access it. To do that I have to scan the command output for the value in a post-processing script. Post-processing scripts let you run JavaScript code after a step runs, including analyzing the log from the step. So I add the following post-processing script to step 2:

The scanner.register line creates a handler that scans the step output for the text “myMessage=”. Then, it removes the “myMessage=” characters, leaving just the message after the equals sign. Then, it uses properties.put() to store the message in an output property that is named “message.” The line scanner.scan() runs the handlers in the script, and the rest of the script is required code to set the success or failure status of the step. Here’s what that post-processing script looks like in the process editor:

That’s the hard part. Now, future steps in the process can access that output property with the usual code:${stepName/propertyName}. In this case, the code is ${p:Grab value from file/message}. You can use that code to use the property value in step properties and in other places like in shell script code. For example, here in step 3 I use the shell script echo ${p:Grab value from file/message} to print the property value to the command line: