PNG Images

[Jacques B]

Hi,

I’m trying to pass PNG images.  The problem is I’m receiving sometimes a x0b  which means new message.  Since the message is defined this way in the pdl:  

define phrase basic-msg;

   ;

   field data = variable-array( not( ) );

   ; ;

end phrase;

I have this kind of problem:

32 33 7c 46  7c 89 50 4e  |23|F|.PN|

47 0d 0a 1a  0a           |G….|

03/06/2006 11:04:30

[pdl :PDL :ERR /0:conn_Radimage] no-match: no more phrases to try

–> Data received does not match MLP phrase (2 bytes):

0b 12                     |..|

03/06/2006 11:04:30

[pdl :PDL :ERR /0:conn_Radimage] no-match: no more phrases to try

–> Data received does not match MLP phrase (7 bytes):

0b 12 01 d2  dd 7e fc     |…..~.|

So I thought about some solutions:

1)   Hoping I won’t have an image with “MSH|”

define phrase basic-msg;

   ; “MSH|”;

   field data = variable-array( not( ) );

   ; ;

end phrase;

and since I want to have the field data with the MSH I add this to

hci_pd_msg_style acknak phrase:basic-msg

field:”MSH|” data

resync:\xb

instead of :

hci_pd_msg_style basic phrase:basic-msg

field:data

resync:\xb

2) never use image in interfaces.  Use ftp instead.

3) ask my provider to change by something else.

Any other idea?  Which solution I should use?

Topic

[Jim Kosloskey]

Jacques,

If the sending system is agreeable you could change from HL/7 mlp encapsulation to length encoded TCP/IP.

However, your receiving systems will all need to change as well.

There is a construct defined in the HL/7 standard which references the passing of images. Perhaps you can gain some insight there – I have never had an occasion to use it.

Even if you clear the vt hurdle, you need to be aware of the ending encapsulation fs cr as that combination can occur within images as well.

If the vendor changes the encapsulation characters (hopefully using the escape technique described in the HL/7 standard – Chapter 2 Section 9), the receiving systems must be able to convert them back properly or you need to do it in the engine prior to delivery.

Images can be quite large and that may pose a performance and/or capacity issue for you.

Many simply pass a URL or directory/file name in the HL/7 message and the receiving systems fetch the images independently of the message.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Scott Folley]

Can you have them use base64 encoding on the image data before they send it to you?  If so you can get executables that will decode the image on your side and avoid the problem completely.  Base64 encoding is a fairly common method for transferring image data so you may find that the systems that you are sending to will be able to handle the decoding on their end.

[Jacques B]

Scott,

that’s exactly what we are trying to do!  We’ll encode the image in Base64.  They suppose to do it by tomorrow and I was waiting to see if this solution was working before to send it…

Thank you.

[Jacques B]

But not the best idea…

With base64, we pass images (PNG and JPeG).  I needed to do it but I don’t recommend it.  Send a the place where the file is, a URL instead.

[Anonymous]

Jacques,

Another option, if you have some influence over the the sending system, is to switch from encapsulation to length encoding.  Then the individual bytes won’t matter.

Your transmission would go from:

<0b>hello <0b>world<0d>

To:

<00><00><00><10>hello <0b>world

(This is 4 byte, binary, length encoding.  There are a total of 16 characters in the transmission including the length field, the <10> in hex is ascii 16)

In Cloverleaf, this would be a configuration change and not a PDL.

cheers,

[Author]

Replies