UrbanCode Deploy: Hidden properties and WebSphere Discovery

Having successfully gone through installing WebSphere and creating Base WepSphere profiles using Urbancode Deploy (UCD), the next logical step is to use the profile in some way. Here’s where the Application Deployment for WebSphere plug-in comes in. There are a bunch of steps in this plug-in that help with a whole range of WebSphere tasks.

Here’s a simple process that uses a couple of steps : Check Status  & Restart Serversimpleprocess

The documentation for each of the steps has a bunch of input properties, some of which need values set for the step to run: the Server Name, the WAS Administrative user name and password for example. As with other steps in other plug-ins – including the example plug-in I created in Urbancode Deploy metamorphosis: From process to plug-in –  these properties are surfaced in the Step UI. However a cursory glance at the UI for the Check Status UI shows that the properties detailed in  Check Status are nowhere to be seen.

nopropertiesThat’s where the “Show Hidden Properties” check box at the bottom of the dialog comes in and checking it reveals all the properties detailed in the Infocenter topic.

hiddenproperties

Assuming there is an agent already installed on the target server, running this process  on the resource doesn’t quite work:

execfailure

The Check Status step succeeds with the following output:

C:\ibm\websphere\bin\wsadmin.bat -lang jython -conntype SOAP -host WIN-7VN7MDUIA2T.freddy.jke.net -port 8880 -user **** -password **** -f temp.py
WASX7209I: Connected to process "server1" on node WIN-7VN7MDUIA2TNode01 using SOAP connector; The type of process is: UnManagedProcess
Object in running state

However the Restart Server step fails and the output shows:

AdminControl.invoke(AdminControl.queryNames('type=Cluster,name=${p:resource/websphere.cluster},*'), 'rippleStart', '')
${p:resource/websphere.commandPath}wsadmin.bat -lang jython -conntype ${p:resource/websphere.connType} -host ${p:resource/websphere.host} -port ${p:resource/websphere.port} -user ${p:resource/websphere.user} -password **** -f temp.py
Caught: java.io.IOException: Cannot run program "${p:resource/websphere.commandPath}wsadmin.bat": CreateProcess error=2, The system cannot find the file specified.
java.io.IOException: Cannot run program "${p:resource/websphere.commandPath}wsadmin.bat": CreateProcess error=2, The system cannot find the file specified.
at java_lang_ProcessBuilder$start.call(Unknown Source)
at restart_server.run(restart_server.groovy:76)
Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified.
... 2 more

To state what might seem to be the obvious: the values specified for the properties of the Check Status step need to be repeated for the Restart Server step.
Tedious to say the least,and my process only has 2 steps!

A clue to solving this lies in the output of the failed Restart Server command. Also note that  the default values for the step before I changed them look like this.

defaultstepprops

In both the screenshot above and the command output  notice the ${p:resource/<propertyname>}.The step is trying (and failing) to find values for the various properties in the configuration of the resource the process is run on. Now I like cats and never have or never will want to skin one but if this problem was a cat there are at least a couple of ways to skin it.

1) Manually define each of the properties in the Configuration of the resource on which the process is run. So in my case I could define the properties on the agent, for example:

agentproperties

This is less painful than editing each step but painful nonetheless.

2) I can use the WebSphere Topology Discovery and the WebSphere Discovery pseudo-steps to do the hard work for me. I call them “pseudo-steps” because as the Infocentre states: “Do not add this step to processes. This step is used to import information about resources on IBM® WebSphere® Application Server.

Assuming again that I have an agent installed on the same server that I have the WebSphere profile on, I simply follow the steps described in Importing resources from WebSphere Application Server. This process auto-magically figures out the WebSphere resources accessible via the agent and adds them as resources for me.

autodiscovered

autoprops

Since I specified some of the properties on the Cell prior to running the Auto Configure action and the Auto Configure figured out the server name. I can leave all the defaults in the step properties as-is i.e. as ${p:resource/<propertyname>}.

However (thanks to Kensie Sturdevant from the Development team for pointing this out to me) when I run the process I must select the WebSphere server (JVM) – server1 in my case – as the resource to run it on and all the property values will be appropriately filled in and used.

finalrun

Hopefully this post has provided some insight into not only the use of the the Application Deployment for WebSphere plug-in and UCD’s Discovery for WebSphere but also a little into how properties get used. For more details on properties for different UCD objects, see  IBM UrbanCode Deploy properties.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s