| Author |
Message
|
| mgm |
 Posted: Thu Jun 09, 2011 5:34 am Post subject: |
 |
|
Apprentice
Joined: 14 Dec 2007
Posts: 48
Location: anywhere
|
| Quote: |
Q1: Are you receiving a large stream of bytes, and splitting it into records using the Parsed Record Sequence option on the TCP/IP node? If so, then that is a good and valid reason for using a message set.
|
Yes, the sent/received payload contains several records. The full payload size is set in the the two bytes from the 5th to 6th location of the whole payload. So I need a way to tell the TCP client nodes how to parse the data or at least to know the data payload has been received or not
| Quote: |
| Q2: What is your message flow actually doing? Is it just passing on the payload of each 'record' to another TCP/IP node without doing anything to it ? |
The flow is intended to compose a set of records to be sent to TCP/IP server expecting input data in byte array sequence. or octet format and parse the input/output data to do other staff
| Quote: |
| Q3: Did you take the user trace that I asked for? If so, what did it say? |
I was not able to take it because I don't define the message set correctly and it fails to parse Text:CHARACTER:CPI Internal error from invalid operation on PWFData
Text:CHARACTER:ImbRecoverableException caught from worker when attempting to write out the bitstream. |
|
| Back to top |
|
 |
| mgm |
| Posted: Thu Jun 09, 2011 5:37 am Post subject: |
|
|
Apprentice
Joined: 14 Dec 2007
Posts: 48
Location: anywhere
|
| I have already worked with ISO8583 but the data has a delimiter which I used to set in the TCP/IP nodes to identify the end of payload |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 09, 2011 6:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mgm wrote: |
| I have already worked with ISO8583 but the data has a delimiter which I used to set in the TCP/IP nodes to identify the end of payload |
I didn't say that your data had any relationship to ISO8583.
I said the Pattern might have some techniques that you could apply to your data. |
|
| Back to top |
|
|
| mgm |
| Posted: Thu Jun 09, 2011 6:11 am Post subject: |
|
|
Apprentice
Joined: 14 Dec 2007
Posts: 48
Location: anywhere
|
| mqjeff wrote: |
| mgm wrote: |
| I have already worked with ISO8583 but the data has a delimiter which I used to set in the TCP/IP nodes to identify the end of payload |
I didn't say that your data had any relationship to ISO8583.
I said the Pattern might have some techniques that you could apply to your data. |
Sure, I understand that but I only tried to tell you that my case is different. even for the ISO8583 pattern, it relies on setting the expected length in the local environment which is not available in my case so I need to rely on the payload at receive time so the TCP/IP receive node would identify the runtime length of data. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 09, 2011 6:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I would think you would be able to use the TCPServerInput node to read the first 6 bytes, and parse that to find the length.
Then use the TCPServerReceive node to read the rest of the message, leaving the socket waiting for the next six bytes that start the next message. |
|
| Back to top |
|
|
| mgm |
| Posted: Thu Jun 09, 2011 6:35 am Post subject: |
|
|
Apprentice
Joined: 14 Dec 2007
Posts: 48
Location: anywhere
|
| mqjeff wrote: |
I would think you would be able to use the TCPServerInput node to read the first 6 bytes, and parse that to find the length.
Then use the TCPServerReceive node to read the rest of the message, leaving the socket waiting for the next six bytes that start the next message. |
Good idea, but how to apply the same technique if I am client where I send a request through TCPIP Client Output and wait for the response through TCPIP Client Receive ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 09, 2011 6:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mgm wrote: |
| mqjeff wrote: |
I would think you would be able to use the TCPServerInput node to read the first 6 bytes, and parse that to find the length.
Then use the TCPServerReceive node to read the rest of the message, leaving the socket waiting for the next six bytes that start the next message. |
Good idea, but how to apply the same technique if I am client where I send a request through TCPIP Client Output and wait for the response through TCPIP Client Receive ? |
In the same design pattern one would use to read multiple messages using an MQGet node. That is, call your TCPIP Client Output to send your request. Then call the TCPIP Client Receive 6 bytes. Then parse the length. Then call TCPIP Client Receive to read the rest of the message. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jun 09, 2011 7:28 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
| That is, call your TCPIP Client Output to send your request. Then call the TCPIP Client Receive 6 bytes. Then parse the length. Then call TCPIP Client Receive to read the rest of the message. |
That is spot on, top notch advice. We've used that very construct in a flow that does Domain Name renewals with Nominet.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mgm |
| Posted: Thu Jun 09, 2011 7:46 am Post subject: |
|
|
Apprentice
Joined: 14 Dec 2007
Posts: 48
Location: anywhere
|
one last question
What's the suitable ccsid value to pas this string as is 00000270012180211-7116511012575454535751565548484850
the server expects each byte as it. I mean it expects the same sequence in byte where the first byte is 0 hex not char '0' |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 09, 2011 8:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mgm wrote: |
one last question
What's the suitable ccsid value to pas this string as is 00000270012180211-7116511012575454535751565548484850
the server expects each byte as it. I mean it expects the same sequence in byte where the first byte is 0 hex not char '0' |
How are you constructing the message you are sending to TCPClientOutput? Using a BLOB? Using a logical message tree of some kind?
From data that is already parsed by Broker into a logical message tree or otherwise MbElements/fields?
Or from data that is read as raw data from something else and may not have been cleared by broker?
In general, when turning any kind of message data into a BLOB output, you need to correctly indicate the CCSID for the *target* data. that is, you need to know what CCSID/encoding the other end of your TCPIP socket is expecting. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Jun 10, 2011 3:42 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| I thought you said that you were treating this message a a series of bytes. So that means using the schema type 'xs:hexBinary' for all of the fields in your message definition. In which case, the CCSID is not relevant. |
|
| Back to top |
|
|
| mgm |
| Posted: Sun Jun 12, 2011 3:30 am Post subject: |
|
|
Apprentice
Joined: 14 Dec 2007
Posts: 48
Location: anywhere
|
| kimbert wrote: |
| I thought you said that you were treating this message a a series of bytes. So that means using the schema type 'xs:hexBinary' for all of the fields in your message definition. In which case, the CCSID is not relevant. |
I tried both BLOB and hexBinary types.
The issue now that server expects the byte stream as bytes in the sequences I described before. For example it expects 0000 to be 4 bytes each has hex value of 0 while using the above type send this 30303030 which coveted the 0 value to 30 and so on.
The server need to receive data as below
[0, 0, 0, 0, 0, 27, 0, 0, 1, 2, 18, 0, 2, 11, -71, 1, 65, 1, 1, 0, 12, 57, 54, 54, 53, 57, 51, 56, 55, 48, 48, 48, 50]
I used a java client to send this data in byte[] object and it was sent successfully but failed to do the same using the broker. Any ideas? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jun 12, 2011 8:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well, surprisingly enough it looks like you have to first parse your test to hex binary. 0x3030 is the representation of ASCII '00' character.
Casting a character field to binary is not the same a assigning it a binary value...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mgm |
| Posted: Sun Jun 12, 2011 9:07 am Post subject: |
|
|
Apprentice
Joined: 14 Dec 2007
Posts: 48
Location: anywhere
|
| fjb_saper wrote: |
Well, surprisingly enough it looks like you have to first parse your test to hex binary. 0x3030 is the representation of ASCII '00' character.
Casting a character field to binary is not the same a assigning it a binary value...
Have fun |
So how to get around this and achieve what I am looking for ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Jun 12, 2011 10:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mgm wrote: |
| So how to get around this and achieve what I am looking for ? |
There are two ways.
One, construct the BLOB string using binary values.
Two, construct the blob string using character values and then cast it as a blob string - this requires the correct encoding (at least).
Which one are you trying to use? |
|
| Back to top |
|
|
|
|
