activeVOS webinar

participated in a webinar on Wednesday giving the overview (sales) presentation of activeVOS.  neat product, neat concepts.  the core focus is to map business process through WebService Business Process Execution Language (WS-BPEL) and Human-BPEL through Business Process Markup Notation (BPMN).  

I thought it brought some very interesting things to light but was curious why it isn't bigger in the market place.  I have to be honest, I've been in and around business process automation for a while now and had never heard of them.  

I think for Autonomics to be successful in a business, BPEL is a key foundation for it.  Machines and applications should be able to self-heal, but the self healing and self awareness still needs to map to that process.  

Getting back to activeVOS, it wasn't a bad Webinar if you have a free hour...

random TPM thoughts

Well, it's been a long time, but I'm still at it.  TPM and I can't seem to get away from each other.  It's not a bad thing.  Over the years I have been personally evolving in alignment with this product.  

Is it the best one out there?  Not sure.  

Does it work?  Yep, it can.  

The biggest thing I currently see and have seen is that the product is not positioned properly.  I continue to hear the sales pitch and see the demonstrations, but at the root of the problem is the solution selling.  The pain of the customer isn't properly identified and end up getting bombarded by a slew of products that are very much cool in their own right...but don't satisfy the business requirement.  Whatever that requirement may be.  There will always be one.  

What needs to be sold right now to customers is the entire concept of Business Process automation.  Maximo helps you deliver this.  There are other products too.  TPM in the end is just a tool that enables you to automatically perform actions.  If those actions aren't performed in alignment with business process, then what's the point?  

the build.xml

here's my next favorite hack. the build.xml that is used to create the automation package (tcdriver) for TIO / TPM can provide quite a bit of goodness. with one of my customers, i modified the contents of the tcdriverdevelopment.jar file so that each and every automation package that is created has a super-duper action packed build.xml.

1. take the current tcdriverdevelopment.jar file and extract it using jar -xf to a directory of your choice
2. navigate to com/ibm/tivoli/orchestrator/tcdriverdevelopment/resources
3. modify build.xml
a. you could also modify xml-template.xml so that it fits company standards (or in the case here, adding cvs tags so that non-developers that write workflows don't forget)
b. tc-driver-template.xml which is converted to TC-INF/tc-driver.xml when the automation package project is created
4. when finished making changes, simply rebuild the jar file with: jar -cf and copy it back into your apde / plugins directory (from where you originally retrieved it).
5. restart APDE and create a new automation project

What have i added to the build.xml you ask?

Incremental build number for every build that updates the tc-driver.xml direct and uses a build.properties file to store the information.

Add custom properties to the tc-driver.xml for use when automation package is imported into TIO.

Output directory of automation package after packaging was modified to automation project home instead of APDE home.

Just little things to make the lives of developers easier (and my life too!)

-sd

tc-driver.xml and device driver properties

Where to start. How about a description. What is "tc-driver.xml"?

The tc-driver.xml file is a manifest file for an automation package. It contains the name and the version number of the automation package and the version number of the automation package template, and describes all of the device driver dependencies on other automation packages.

Read more about it at: Setting up the manifest file

In addition to any helpful information you find at the link above, you can also have the manifest file set dcm properties when it is imported. You may or may not know that you can have variables associated against device drivers. I find that these variables can be better stored here rather then as global variables (that is, if the variable is not needed globally). When you update a tcdriver it will remove all of the variables loaded against the device drivers that it is updating. Most companies implement this product to facilitate some sort of automation ... so, unless you want to manually re-add the variable(s) every time, you can try the following within the <device-model></device-model> stanza:

<dcm-property component="DEPLOYMENT ENGINE" name="your variable name" value="the value" />

Now, each and every time your automation package is updated, the variable with name "your variable name" will be available by DCMQuery.

somewhere new

I've been working with TIO/TPM (IBM Tivoli Intelligent Orchestrator & IBM Tivoli Provisioning Manager) for the better part of forever. Some time ago, I had a forum under autonomics.ca where I had posted lots of great information related to TIO 3.1.

By "great information", I mean, information that I found useful. I have no idea if anyone else ever did. The only comments and posts that I received were from spambots telling me how to make my penis bigger.

So here I am on blogger. A place for me to post my rants and tips and hope that google can help filter out penis spam.

-sd