Sunday, March 11, 2012

Strange issue on JAR???

Wondering if anyone out there experience this before.

I have this program calling a external web service. So i built the client classes to consume it.

After some time the web service contract/schema had changed, i needed to either change the content of the classes or rebuild the client classes again. Usually i prefer a rebuild as this will be done by the generator with very minimum effort.

So i rebuilt the client classes. Everything worked fine in the Staging/Testing environment until the production rollout day.

Exactly the same JAR, but not working. I drilled down into which line that caused the havoc. Strange thing is that the program was not able to read the particular web service client classes. I then checked if the client classes were included in the JAR and they were there! Their were at the right path too! What happened?

No choice i needed to get this done asap. I moved these classes from one folder to another folder, ofcuz by using the refactor function. This was just a blind hit and guess what, it works!!!

This may give you an idea the next time you are facing exactly the same weird issue!

Best way to remove MQRFH Header (WMB)

I have tried many approaches just to achieve this. My goodness each approach is so unstable. It may work in environment A but then somehow does not work in environment B.

With the help from a more experienced colleague, the optimum solution for that seems to be:

1) Set the Message Domain as XMLNSC for MQInput Node.
2) Create a Compute Node then write your ESQL as follows:
CALL CopyEntireMessage();
SET OutputRoot.MQRFH2 = null;

Done! It's never been so easy. Fuck i wasted much time in this! Should have known this colleague long time back.

Tuesday, March 1, 2011

WMB It's best to set BLOB as the parser for message containing MQRFH2 header

I was struggling with this message(XML) with MQRFH2 Header.

I have tried the MRM Header, the drawback is that you got to choose a schema, which makes it less flexible. Also the parsers being selected at runtime (printed in the mqsitrace log) are not consistent! Still puzzling.

Setting parser as BLOB in the MQInput node solved my issue. Without making any further message format conversion, you can read the xml using XMLNSC parser anytime anywhere.

Monday, September 27, 2010

Transfer message with RFH header from one queue to another queue

I have this simple java program transferring message with RFH header from one queue to another queue in bulk.

First time it failed due to the program failed to maintain the RFH header during the transfer. It read the message in STRING format and then put the message back in the destination queue.

After that i changed this by sending the MQMessage directly to the destination queue. This works.

Thursday, September 9, 2010

java.sql.Date not working on WPS 6.2?

I had this program reading database table column as java.sql.Data type. Well it failed to read this when running from the WPS AIX server. Funny thing is it was fine when i was testing this program from my local WPS server runtime. In application log the column data type is recognized as java.sql.Timestamp. So i have to change to program to read Timestamp instead of Date.

Thursday, June 3, 2010

MQ-related CRON job setting

Recently my colleague was faced with the crontab issue. Below is the description:

1. CRON Tab

We developed a JAR where it connects to the Queue Manger and puts message into the Queue to kick start the WMB flow. We have created a Shell script to send message to the queue. It is successful by executing the Shell script manually where it connects to the Queue Manager and successfully put the message into the Queue.

Unfortunately, the CRON job failed to execute this script. After a few rounds of investigation we found out that this is due to the AIX Environment Setting. We need to set the environment variables at our Shell script as below before connecting to MQ:
. /opt/IBM/mqsi/6.1/bin/mqsiprofile

The default environment setting for CRON does not have the MQ Specific environment.
Therefore, when we are using server binding, we need in include this into our Shell script.
If the Shell is running externally as client, we do not need to include this.

Wednesday, May 26, 2010

Modify WSDL to get the java client generated right

I have to generate java client for this WSDL. However the bean generated is not what i expect. The reason is the SOAP response format actually looks like this:

<data>
<field id="field1"><field>
<field id="field2"><field>
...
</data>


The bean generated is like this:

public Class Response{
Field[] data;
....
}

I failed to get the value of each . The Field class does not provide a getValue method. Instead it provides getId method which returns the field id.

I had 2 solutions:

1) Modify the generated java web-service client code. (Those serializer, deserializer etc)
2) Modify the WSDL to get the code generated as according to what i want.

I chose the second option.

I commented this segment of the WSDL:

<xsd:element maxOccurs="unbounded" name="field">
<xsd:complexType>
<xsd:sequence maxOccurs="1" minOccurs="1" />
<xsd:attribute name="id" type="xsd:string" />
</xsd:complexType>
</xsd:element>


I replace the above segment with:

<maxoccurs="unbounded" minoccurs="0" name="field" nillable="true" type="xsd:string"/>

Done!