I am publishing a byte message on MQ from Lisa Testcase. But in Tibco the received message is not the message which got published. please help
What exactly do you mean by "is not the same"? What is the format of the bytes message? Is the received content completely different, or something that's clearly the same content but corrupted somehow? Maybe it's text but in a different character set?
When you say 'MQ', are you talking about IBM MQ? If you're publishing to IBM MQ and then receiving from TIBCO then there must be some extra layer in there; those are two completely different messaging systems. Try finding an unused queue on the MQ side and building a "self publishing" step that publishes your message to that queue and receives it from the same queue, just to make sure connectivity is working and nothing is weird on the MQ side. With MQ are you using JMS Mode or Native Mode? Then, can try the same thing on the TIBCO side? If both sides work independently then the problem must be in whatever is transferring messages from MQ to TIBCO.
If 'MQ' doesn't mean IBM MQ and you're just talking about TIBCO, then can you start with the "self publishing" step I mentioned? Find an unused queue and try building a step that sends a message to itself just to make sure that works as expected.
Thanks a lot for the reply.
What I mean by "is not the same" is I am publishing the below message on to IBM MQ
(I am sharing you only some message)
Published message :
The above message I am trying to receive in Tibco by using "Websphere MQ Listner Activity " to receive that same byte message.
But The output of that activity is not that above published one. The above published messaged is completely modified , I am not sure whether it is corrupted or modified or encrypted.
Received Message in Tibco:
With IBM MQ , I am using Native Client.
Both TIbco and Lisa are working independently.
Within Tibco the message is not corrupted.
While testing that Tibco interface in Lisa, when I am sending that message from Lisa , the message is corrupted.
If you Base 64 decode "TURBd01EQXdNREF3TURBd01BQUFBQUFBQUFBQUFBQUF=",
then the result equals the following ASCII text:
If you are just pasting "MDAwMDAwMDAwMDAwMAAAAAAAAAAAAAAA..." into the
'Message Data' tab of the MQ step then you are not sending a binary
message. You are sending that as ASCII text. The MQ step will not
automatically base-64 decode whatever you paste in there. If I'm
interpreting your published message correctly, it looks like you want to
send something that starts with a string of '0' character bytes, then a
string of 0x00 bytes, then another string of '0' character bytes.
In order to send actual binary data with the MQ step, the easiest way is
to put the raw binary payload into a file. Then insert a 'Read from a
File' step before your MQ step and use it to read the contents of that
binary file and save it to the testExec in a byte array. Then, in
your MQ step, change Publisher Info -> Message to 'Bytes', and enter the
name of the property under which you're storing the byte array in the
Message Data tab.
FYI: If you are using 8.0.2 then there is a brand new experimental IBM
MQ Send Receive step that makes handling binary data much easier. It
still doesn't support pasting in Base 64, but it does support pasting in
Hex, and it doesn't look like Base 64 would be difficult to add.
Thank for the solution.I have followed the above steps but still issue has not been resolved.
I am new to LISA. So sorry to ask basic questions.
I have created the below testcase steps in LISA7.5.1
2. IBM Websphere MQ Step
BinaryData.txt file contains the below message which has to be published.
File f = new File("I:\\MyData\\ALTO-LIL\\BinaryData.txt");
File f =
FileInputStream fin = new FileInputStream(f);
FileInputStream fin = new FileInputStream(f)
byte fileContent = new byte[(int)f.length()];
 fileContent =
//convert file into array of bytes
//convert file into array of bytes
//ALTOmsg is initialised first in proj.config file of LISA
} catch (Exception e)
System.out.println("Exception : ", e);
System.out.println("Exception : ", e
After this step is executed the ALTOmsg value is set to [B@176cd45.
2. In the IBM MQ step
Publisher Info -> Message is set to 'Bytes', and
In 'Send Message Data tab -> name of the 'property that holds the object' is set to ALTOmsg
After this step is executed the message that it is publishing is
But again Tibco is receiving "TURBd01EQXdNREF3TURBd01BQUFBQUFBQUFBQUFBQUF" message but not "MDAwMDAwMDAwMDAwMAAAAAAAAAAAAAAA" .
Tibco should receive "MDAwMDAwMDAwMDAwMAAAAAAAAAAAAAAA" message only otherwise the Tibco interface will fail.
Does your .txt file contain the *literal text* "MDAwMDAwMDAwMDAwMAAAAAAAAAAAAAAA...", or does it contain the binary data corresponding to that Base64 encoded data? Judging by the fact that you gave it a .txt extension, I'm guessing that it contains the literal text "MDAw...".
You're trying to send a message containing binary data. The text you keep providing, "MDAw...", is the *Base64 encoded version* of that binary data. Every four characters in the text "MDAw..." represents three bytes in the original binary data. You have to Base64 *decode* it to obtain the original binary data.
Because you are *not* Base64 decoding your message data, the MQ step is taking the text "MDAw..." and sending it as is, encoding that exact text into bytes using ASCII encoding. Then somewhere between IBM MQ and whatever you're using to receive the TIBCO message, something is taking those bytes and Base64 encoding them *again*, leading to the different-looking message data. What you're seeing with "TURB..." is your original binary data, Base64 encoded *twice*.
Is this making sense? I'm not sure how much clearer I can make it. You need to Base64 decode your message data before sending it.
You can do this with an external tool, save the resulting bytes to a file, and then use your Java Script step to read that file (or just use the Read from a File step, which does literally the same thing you're doing with a script step). Note that you will *not* be able to view that file with a text editor; your binary data contains bytes that do not map to any printable character under ASCII.
Or, you can add a few lines to your script step that Base64 decodes fileContent:
byte originalBytes = new sun.misc.BASE64Decoder().decodeBuffer(new String(fileContent, "ASCII"));
Thanks a lot Kevin.
I had same problem with Base 64 encoded binary data in a xml file.
I had to decode it separately --> store that original(decoded) binary data in a file --> read file and load original binary data into a property --> pass that property as byte message in JMS step.
It worked but I need to send a lot of messages and doing this exercise for all messages itself will eat up so much time. Ended up using HermesJMS which has direct option of sending encoded message which decoded and sent to TIBCO.
Would appreciate if an option can be added in new version of LISA, not sure if this decoding option is added already.
I'm a little confused on exactly what you're doing. What are your "input" and "output" payload formats? Can you point me to some documentation of the HermesJMS feature you're using?
sorry for the confusion...here is my requirement : Need to publish a message which has base64 encoded data(it's another encoded xml, here in the attached file I have replaced actual encoded xml message with dummy encoded message). This encoded data needs to be published to TIBCO JMS queue in byte format.
TIBCO is expecting decoded data in byte format.
I don't have documentation but there is an out of the box feature in HermesJMS which says "Send XML Encoded Message" under Menu-->Messages where I will select SampleData.xml and send...dont know what that does but TIBCO receiver is accepting it directly and processing it.
But in LISA I need to first read SampleData.xml file --> Extract message with in <bytes> tag -->decode the message-->load it into byte-->send this in TIBCO Direct JMS step as byte message
I'm pretty sure the XML file you have attached was originally exported *from* HermesJMS, using its 'Save As XML...' feature. In addition to the message payload, it contains the message header and a handful of custom message properties. In HermesJMS, the 'Send XML Encoded Message' feature is designed to be used along with 'Save As XML...' in order to send an exact copy of a previously saved message, including all of its data and meta-data.
It's a custom file format from another program, so DevTest is not going to be able to read it out of the box. Fortunately you should be able to combine a 'Read a File' step with a Script step to do what you want.
Add a 'Read a File' step to read your file and make sure it's saving as a text. Then add a Script step:
// Disclaimer: I have not actually tested this
// Get the file XML
xml = testExec.getStateObject("LASTRESPONSE");
// Easy way: Use a RegEx to pull out the text between <bytes> and </bytes>
// I'm not 100% sure on the HermesJMS file format, this is assuming that the base64 data is not broken up onto multiple lines.
matcher = java.util.regex.Pattern.compile("<bytes>(.*)</bytes>").matcher(xml);
base64 = matcher.group(1);
// Use a built-in Java class to do the Base64 decoding
bytes = new sun.misc.BASE64Decoder().decodeBuffer(base64);
// Set a property that ca be used in the JMS Send Receive step
Then, in your JMS Send Receive step, make sure you have 'Bytes Message' selected on the left, then use the gear icon at the top right of the bottom panel to select 'DevTest Property Reference'. Enter 'payload_bytes' for the name of the property. If you're using the old JMS step then it basically works the same way
You could be right....fortunately I was able to use read file with my own custom JS step and got it working....
your JS script is better than mine....I just tested your script with actual data and it worked like a charm....Thanks Kevin
Retrieving data ...