ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Recive message without Set Length

Post new topic  Reply to topic Goto page 1, 2  Next
 Recive message without Set Length « View previous topic :: View next topic » 
Author Message
mona
PostPosted: Sun Jul 01, 2012 11:26 pm    Post subject: Recive message without Set Length Reply with quote

Novice

Joined: 14 Mar 2012
Posts: 19

who can recived bata(Hex)from TCP/IP input node without Set Length in record detection?(becase, I don't know length of message)
Code:

Tcpip input server--out---> Qoutput & Tcpip input server--failure---> Qfail
config TCPIP Input server:
record detection --> end of Stream
mesage domain--->BLOB

But, after send message,that message enter to Qfail and i get these error:

UserTrace
Code:
 BIP6063I: A parser of type ''Properties'' was created on behalf of node 'TCP_POSFlow.TCPIP Server Input' to handle the input stream, beginning at offset '0'.
UserTrace   BIP6069W: The broker is not capable of handling a message of data type ''BLOB''.
                                       The message broker received a message that requires the handling of data of type ''BLOB'', but the broker does not have the capability to handle data of this type.
                                       Check both the message being sent to the message broker and the configuration data for the node. References to the unsupported data type must be removed if the message is to be processed by the broker.
UserTrace   BIP6063I: A parser of type ''Properties'' was created on behalf of node 'TCP_POSFlow.TCPIP Server Input' to handle the input stream, beginning at offset '0'.
UserTrace   BIP6069W: The broker is not capable of handling a message of data type ''BLOB''.
                                       The message broker received a message that requires the handling of data of type ''BLOB'', but the broker does not have the capability to handle data of this type.
                                       Check both the message being sent to the message broker and the configuration data for the node. References to the unsupported data type must be removed if the message is to be processed by the broker.
UserTrace   BIP6064I: A parser of type ''BLOB'' was created on behalf of node 'TCP_POSFlow.TCPIP Server Input' to handle the input stream, beginning at offset '0'. The parser type was selected based on value ''NONE'' from the previous parser.
UserTrace   BIP2638I: The MQ output node 'TCP_POSFlow.failor' attempted to write a message to queue ''fail'' connected to queue manager ''QMB''. The MQCC was '0' and the MQRC was '0'.
UserTrace   BIP2622I: Message successfully output by output node 'TCP_POSFlow.failor' to queue ''fail'' on queue manager ''QMB''.
Back to top
View user's profile Send private message
smdavies99
PostPosted: Mon Jul 02, 2012 12:16 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

mona wrote:

UserTrace BIP6069W: The broker is not capable of handling a message of data type ''BLOB''.
The message broker received a message that requires the handling of data of type ''BLOB'', but the broker does not have the capability to handle data of this type.
Check both the message being sent to the message broker and the configuration data for the node. References to the unsupported data type must be removed if the message is to be processed by the broker.


This message is one of my pet gripes with Broker. BLOB is a supported Message domain so why does it output this message? I could go on at length about it but I won't.

When you receive TCP/IP messages there has to be a way for the receiver to detect when there is an end of the data in the stream. Back in the days of Telex, we had the good old STX/ETX characters.
Nowadays we have to be a good deal smarter.

If you don't know the length of the message(and it is variable length) in the stream then the sender has to indicate when the end of the message/record has been reached.
There are two common methods of doing this.
1) Adding a terminator to the stream. If the message is pure character XML and has no BASE64 sections then using a X'00' or similar as a terminator can work fine.
2) Send a fixed lenght block followed by the message itself. The length of the message is held in the fixed length block.

There are other ways but these are the ones I've seen most frequently.
_________________
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
View user's profile Send private message
kimbert
PostPosted: Mon Jul 02, 2012 12:53 am    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

smdavies99 said:
Quote:
1) Adding a terminator to the stream. If the message is pure character XML and has no BASE64 sections then using a X'00' or similar as a terminator can work fine.

The 'no base64' rule is not necessary. No XML message is ever allowed to contain the null character. If you want to represent binary data in XML then you have two choices
a) encode each byte as two characters ( xs:hexBinary )
b) encode each group of 3 bytes in 4 characters ( xs:base64binary )
In both cases, the 'characters' are legal XML characters, but base64 offers slightly better compression.
Back to top
View user's profile Send private message
mona
PostPosted: Mon Jul 02, 2012 2:11 am    Post subject: Reply with quote

Novice

Joined: 14 Mar 2012
Posts: 19

Hi
1- I send message from POS (it is variable length) to WMB and don't allow me to change length of the message ,do you know other way?
Back to top
View user's profile Send private message
McueMart
PostPosted: Mon Jul 02, 2012 3:53 am    Post subject: Reply with quote

Chevalier

Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere

Reread what smdavies99 wrote. They are the two preferred methods of handling variable length TCP data.

To expand on his point (2), this would be done by having a TCPInput node configured with a fixed length to receive the 'header' which contains the payload length - Followed by a TCPReceive node where you dynamically set the receive length (using LocalEnvironment), to read the payload.
Back to top
View user's profile Send private message
mona
PostPosted: Mon Jul 02, 2012 4:10 am    Post subject: Reply with quote

Novice

Joined: 14 Mar 2012
Posts: 19

I don't sure about fix length of header, because sometime 2 first byte of message include message length, and sometime no exist this 2 first byte.
i want write the function that, without accounting of length of message or header ,receiving this message.
Do possible it?
Back to top
View user's profile Send private message
smdavies99
PostPosted: Mon Jul 02, 2012 4:24 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

mona wrote:
I don't sure about fix length of header, because sometime 2 first byte of message include message length, and sometime no exist this 2 first byte.
i want write the function that, without accounting of length of message or header ,receiving this message.
Do possible it?


Using the first two bytes of a message to contain the length is a fixed length part. (Just like how Non Ansi strings are defined in Pascal...)
Using just two bytes does limit you to 64K (approx) max message length. This may be suitable for your application needs.
I've often seen 5byte 'headers'

To re-iterate,

1) set up a Receive node to read the fixed length part of the stream. In your case, two bytes
2) wire up a computeNode to the out terminal of A SECOND Receive node.
3) write some ESQL to extract the length if the data and put it in the right place in the LocalEnvironment for the next node to use
4) Wire up the out terminal of the ComputeNode to the In terminal of the Receive node. This will take length supplied and read that nymber of bytes from the input stream.

Obviously there is more to it than the steps above but it is a good start. The rest is mainly down to configuration.

Edited to emphasise the point made by mqjeff
_________________
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.


Last edited by smdavies99 on Mon Jul 02, 2012 4:56 am; edited 1 time in total
Back to top
View user's profile Send private message
mqjeff
PostPosted: Mon Jul 02, 2012 4:37 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

smdavies99 wrote:
4) Wire up the out terminal of the ComputeNode to the In terminal of the Receive node.

Please make sure this is a new Receive node, not the same receive node from Step 1.

Do not wire your flow in a loop. Use propagate and return false.
Back to top
View user's profile Send private message
kimbert
PostPosted: Mon Jul 02, 2012 4:45 am    Post subject: Reply with quote

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Quote:
sometime 2 first byte of message include message length, and sometime no exist this 2 first byte

Are you sure? How do you find out which type of message you have received?
Back to top
View user's profile Send private message
mona
PostPosted: Mon Jul 02, 2012 8:36 am    Post subject: Reply with quote

Novice

Joined: 14 Mar 2012
Posts: 19

Thank's form all friends for support me.
Quote:

1) set up a Receive node to read the fixed length part of the stream. In your case, two bytes
2) wire up a computeNode to the out terminal of A SECOND Receive node.
3) write some ESQL to extract the length if the data and put it in the right place in the LocalEnvironment for the next node to use
4) Wire up the out terminal of the ComputeNode to the In terminal of the Receive node. This will take length supplied and read that nymber of bytes from the input stream.


I think that way for this case : first 2 byte of message is length of message(length+header+app) .is easy (resolved)
but ,my problem is, if this length no exist (header+app)
Quote:

Are you sure? How do you find out which type of message you have received?

yes, I'm very very sure!!
i will using protocol iso8583
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Jul 02, 2012 8:46 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

mona wrote:
i will using protocol iso8583


That's something you could have mentioned up front. Pedantically that's not a protocol in the way TCP/IP is a protocol but a standard which describes the message layout.

It doesn't preclude having a header at the TCP/IP level which describes payload length, and I would question if there's a better reason for some messages having a length and some not aside from "we sort of forgot to add one". A useful answer from your point of view would be that whoever's sending messages without a header is using the fixed length versions of the fields to generate a message of known length.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
smdavies99
PostPosted: Mon Jul 02, 2012 8:46 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

mona wrote:


i will using protocol iso8583


I really do hope that your data is encrypted.

If someone is sending you data that has no indication of its length then it is BAD Data and should be consigned to the great bit heap in the sky.

Being realistic, you MUST isist on a standardised way for the data to be sent. This includes the way that the length of the data is sent to the receiver.
_________________
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
View user's profile Send private message
lancelotlinc
PostPosted: Mon Jul 02, 2012 8:49 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Vitor wrote:
mona wrote:
i will using protocol iso8583


Pedantically


Wow... what a great word.

Code:
Characterized by a narrow, often ostentatious concern for book learning and formal rules: a pedantic attention to details.


I learned something today, Sir Vitor. Thank you.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Mon Jul 02, 2012 8:56 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

lancelotlinc wrote:
Vitor wrote:
mona wrote:
i will using protocol iso8583


Pedantically


Wow... what a great word.


The benefits of an English grammar school education.

lancelotlinc wrote:
Code:
Characterized by a narrow, often ostentatious concern for book learning and formal rules: a pedantic attention to details.


Most thesauri legitimately suggest "nit-picking" as an alternative. I felt it was necessary to prevent someone asking if there was a ISO node as well as a TCP node, but only just necessary.

lancelotlinc wrote:
I learned something today, Sir Vitor.


And I learned you can be taught. Thank you.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mona
PostPosted: Sat Jul 07, 2012 12:26 am    Post subject: Reply with quote

Novice

Joined: 14 Mar 2012
Posts: 19

Hi
I send data with any size to WMB with below config, but only first 80 byte(defult) save in QOUT and other of data save in QFail(len 130 = 80 in Qout & 50 in Qfail)

TCP/IP input server ----open---> compute----out---> TCPIP server Receive----out--->QOUT
TCP/IP input server ----Failure--->Qfail
-----------------
TCPIP input:
Close input Stream after a record ... is checked.
message domain : BLOB
Record detection : End of Stream
-----------------
compute node :
SET len = LENGTH(InputRoot.BLOB.BLOB) ;
SET sub = CAST(len as CHARACTER);
SET sub = CAST('0x'||sub as INTEGER);
SET OutputLocalEnvironment.TCPIP.Receive.Length = sub;
----------------
TCPIP receive :
Record detection : Fixed Length (byte = 0)
---------------

can you help me?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Recive message without Set Length
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.