decode <IRTNODE_PROPERTY>

, ,
1

Hi,

I am working on a utility to decode the property in node.ndf <IRTNODE_PROPERTY>. This is for changing the JDBC Property before I mgrate the code from DEV environment to QA. Settings in both these environment for JDBC Connection is different, and I would like to change those programatically.
I tried using a java code:

FileInputStream istream = new FileInputStream(“\node.ndf”); //Please change this to your path of node.ndf where you created the JBDC Connection
XMLCoder coder = new XMLCoder();
Values values = new Values();
values = coder.decode(istream);
java.util.Enumeration eNum = values.sortedKeys();

while(eNum.hasMoreElements()){
String decodedJDBCProperties = (String)eNum.nextElement();
String decodedJDBCProperty = values.getString(“IRTNODE_PROPERTY”);
System.out.println(decodedJDBCProperties +“—”+decodedJDBCProperty);
}

Above didn’t work

Even I tried using the flow steps:
pub.file:getFile() //Read the file node.ndf
pub.string:bytesToString() //converto to String
pub.document:XMLValuesToDocument //convert the string into XML Document
pub.string:base64Decode//decode
pub.string:bytesToString//convert decoded string into String

This works, but not 100%, it adds some special character between ASCII chars of the properties decoded.

Please help, if anyone has tried this.

Thanks in Advance

2

The data you’re trying to read is not a string. It is a serialized object. The class of the object can vary. You’d need to do some reverse engineering to figure out what it is and how to manipulate it–though that likely violates the license agreement and would not be officially supported.

Might I suggest that this is more work than it is worth? For most environments adapter connections are usually easily managed via IS Administrator–the time savings of automating the work is fairly minimal. Should one spend many hours developing an automated solution to save a few minutes a year?

In addition, tools such as Deployer and CrossVista TEAM can do this sort of configuration value substitution. When a tool such as these cannot be used, I’ve tended to follow these guidelines:

  1. Adapter connections are never copied from one environment to another–particularly to production.

  2. Define/update the connection in an IS using IS Administrator. It takes only minutes to do so. It avoids the risk of test/QA data from invading production environments. An adapter pointing to the wrong resource can have a devastating impact if active even only for a few minutes.

3

Thanks Rob!
Appreciate your quick response.