Getting Started
Missed IBM TechXchange Dev Day: Virtual Agents? On-demand viewing is available here
Do you know all of the scope modifiers we can use to reference UCD properties?
IBM UrbanCode Deploy (now IBM DevOps Deploy) has a construct that we can use in many places to substitute the name of a property for its value. So we can use an expression like ${p:propertyName} or the alternate give me its value if there is such a property ${p?:propertyName}.
We can extend either form to allow us to say in what scope the property should be looked for. The expression then looks like ${p:scope/propertyName} or ${p?:scope/propertyName}.
The well-known scopes being:
There are some other perhaps less well-known:
There is also the special property allProperties that returns a comma-separated list of property name/values that you will probably have seen in steps such as Replace Tokens or Install Template.
But there are also other scopes. Step properties are often overlooked, they allow you to reference a property created by an earlier step in the current process. In this case, the scope is the name of the prior step.
Something like ${p:my step/myProperty}. Of course, you need a step that exposes properties in this way. You can see what properties a step reveals in the Input / Output Properties of a process step execution. The little white document icon. The plugin documentation on urbancode.com will also list these.
But there are more…
Did you know that a component that has a source code plugin associated with it also exposes its properties?
Yeah that’s right you can go through a scope called component/<<plugin>>/propertyName. The trick here is in discovering what the value of <<plugin>> is. An easy way to discover this edit a shell step or some other place that offers property name completion and type ${p:comp at this point a drop-down box should appear showing things like this:
You can now see the scope of the source plugin properties. In this case it’s the subversion plugin and its named SubversionComponentProperties. So, our property expression would now look something like: ${p:component/SubversionComponentProperties/<<pluginpropertyname>>
If you want to delve into the source code plugin itself, you can also find this information in the plugin.xml file.
The component scope also reveals a couple of other interesting sub-scopes:
To illustrate their use, I set up this little scenario:
echo "component all properties: ${p:component/allProperties}" echo "template allproperties: ${p:component/template/allProperties}" echo "custom all props: ${p:component/custom/allProperties}"
Now set up an application and a resource tree so that you can run this component process. You should see something like this:
command output: component all properties: template-comp-prop-def=a,template-property=b,comp-property=1 template all properties: template-comp-prop-def=a custom all props: template-property=b,comp-property=1
If we examine this output we can see that:
If I have a component property with the same name as a template component property definition (not to be recommended of course, but sometimes these things happen when perhaps the template is maintained by another person/group). My component definition would obscure the template property. But using ${p:component/template/allProperties} I would see the template property instead of the component one.
In this example, I’ve used allProperties to illustrate but you could also use the actual property names.
#UrbanCodeDeploy#10minutetip