Changing the webMethods JDBC Adapter Connection

Not sure how many people in software world look around for webMethods help on Internet. Actually, being a google fan, I am used search all the problems and all the knowledge on the Great Internet. Surely tried to search for some solutions on Internet, I got some of them, but not all of them. As we know everything is an node.ndf and/or flow.xml on file system in the little world of webMethods.
Considering the basic fact webMEthods does not support any version control tool integrated with "webMethods Developer". So we have to manage version control for multi developer shop on the basis understanding and coordination. (Offcourse lot of software consultants don;t have that). Then we have more than 3-4 environments and needs to have concurrent development practice. This compelled all around to ding in more and find some way of dynamically creating and destroying local development environments. This allows local development and then uploading that on servers
The compulsion gave rise for the need of using the scripts and or programs to get the automation in place. One of the biggest pain all the time was to modify the JDBC Connections, so that we can script the deployment on webMethods environments.

webMethods uses the JDBC adapter services to connect to databases. As we all know we need to use the JDBC connection defined. This means when we move the code from one environment to other, we have to manually, change connection properties. Scott Conely from ThoughtWorks introduced me to a new way of working with node.ndf files which reside for each service in webMethods.

Every node.ndf file is basically the XML file internally, which stores the information about the service is all about. If you open this with a any XML editor, we can definitely see the data that webMethods needs for its working. This serialized XML element is <value name="IRTNODE_PROPERTY"> which stores the whole serialized object which has information about the JDBC connection. If we could deserialize that object. We can see all the properties of the connection set up from the JDBC Adapters menu of IS Administrator UI. The idea of changing the adapter connection can allow connection manipulation task through scripting. If one can deserialize the data in that element, the changing the connection properties are easier. Then serialize it back and then put that back into node.ndf. Done ... we have modified the node.ndf of connection successfully.

Let see if we can do this. Use com.wm.util.coder.XMLCoder, offcourse gets installed with webMethods installation, to deserialize the element. Basically, this is how it would look loke after the object is deserialized.

>>>BasicData:connectionNodeVersion=1, adapterTypeName=JDBCAdapter, connectionFactoryTypeName= com.wm.adapter.wmjdbc.connection.JDBCConnectionFactory, connectionProperties= >>>BasicData:transactionType=NO_TRANSACTION, datasourceClass= com.microsoft.jdbcx.sqlserver.SQLServerDataSource, serverName=ohclests5337a, user=USER_NAME, password=O/EO8SEgPac=HnSdKdaf6Cs=, databaseName=kpiSchema6, portNumber=1433, networkProtocol=, otherProperties=<<<, connectionManagerProperties= >>>BasicData:poolable=true, minimumPoolSize=1, maximumPoolSize=10, poolIncrementSize=1, blockingTimeout=1000, expireTimeout=1000<<<, connectionEnabled=true, xflds=[0]password<<<

So if you can change these objects and its data elements, the modification is done. Beware when youa re doing it, rememebr that the the whole object you receive is nested IData. if you don't handle this carefully this will spoil the whole connection setup, but who care we can definitely recreate those connections when testing out the program. I did this in Java ... and when I checked with Scott, seems he also did the same way. Finally, Scott showed me something as the password which cannot be modified as it is encrypted in the IData object. Simple solution is change it to new encrypted value, instead of finding encryption. Smart guys ... know how to get the encrypted password before scripting.
Good Luck !!!