RE: [***SPAM***] RE: [BizTalker] Character set of a part

[Mick Badran]

Gregory – there should be a ‘content-type’ property on the actual message part itself to help you also.

 

Reading a part stream into a string is not a big one – provided you know the encoding with a BOM (ideally).

 

You mentioned that you have *no BOM* sometimes (which usually comes from ‘older’ systems where they have no knowledge of this) – without a BOM, you’ve got to make some assumptions really.

 

There may be a message context property – or as you say, you could write/use a custom function that derives the encoding, but either which way it’s tough.

 

My suggestion would be to put a ‘default preference’ on the pipeline component – something like ‘if there’s no BOM’ then apply X encoding (the most common for what you’re doing).

You could then have different instances (or a DB lookup table) and explicitly set the ‘if all else fails try this..’ value.

This is the approach I’ve taken in the past.

Good luck.

 

Mick Badran (MVP - BizTalk)

Training & Integration Specialist | Microsoft Readiness Instructor

BreezeTraining | mb: + 61 404 842 833 | fx: +61 2 3962 4898

IM: mickb@xxxxxxxxxxxxxxxxxxxxx | http://blogs.breezetraining.com.au/mickb

 

From: biztalkerlist@xxxxxxxxxxxxxxxxxxxxxx [mailto:biztalkerlist@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of gregory.vandewiele
Sent: Friday, 21 September 2007 10:53 PM
To: BizTalker@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [***SPAM***] RE: [BizTalker] Character set of a part

 

Poison message handling of raw flatfile content (of readable characters). The parsing is done inside an orchestration.

 

If the pipeline that does the parsing fails my solution sends out an xml containing the failing string in an element. Therefore I need to translate the part stream into a string.

 

An administrator can formulate a response xml, change the string-content and make the orchestration retry the parsing with the updated content.

 

The messages come into the orchestration from different RL’s where the encoding type is set on the part per RL by a ‘FixEncoding’ component (see Tomas Restrepo).

 

Anyway, I can make it work with a custom function that finds out the encoding. When there is no BOM it is hard if not impossible to find out the codepage though for variable or single byte char sets (UTF8 or local)…

 

That is the reason why getting it from the XLANG message would be a lot easier.

 

I could try to read the property ReceivePipelineConfig from the incoming message in orchestration and try to parse out the property value out of the xml.

 

Any other ideas?

 

Gregory

 

From: biztalkerlist@xxxxxxxxxxxxxxxxxxxxxx [mailto:biztalkerlist@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Bill Chesnut
Sent: vrijdag 21 september 2007 14:23
To: BizTalker@xxxxxxxxxxxxxxxxxxxxxx
Subject: [***SPAM***] RE: [BizTalker] Character set of a part

 

Gregory,

 

Just curious of why you need to know what the character set of the message is, BizTalk will handle mapping with knowing this?

 

Is it an XML message or a flat file?

 

I think you would need a decoding pipeline component to read the stream, specifically the BOM at the front of the stream to determine this.

 

You might try the sample fix message component and set a breakpoint of the 1^st buffer read and see what characters are in the buffer.

 

Bill Chesnut

BizTalk Server MVP

 

---

From: biztalkerlist@xxxxxxxxxxxxxxxxxxxxxx [mailto:biztalkerlist@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of gregory.vandewiele
Sent: Friday, 21 September 2007 6:15 PM
To: BizTalker@xxxxxxxxxxxxxxxxxxxxxx
Subject: [BizTalker] Character set of a part

 

Hi Fellow Biztalkers,

 

Does anybody of you know how to find-out the character set of a raw message part from Orchestration? The XLANGPart class doesn’t seem to have this property…

 

If you look at the message-part in the BizTalk Administration mmc you can clearly see it (UTF-8 or UTF-16 etc…).

 

The only solution I can think of right now is to execute a pipeline with this raw incoming message in XLANG and read it in a custom pipeline component…

 

Thanks!

 

Cheers,

Gregory Van de Wiele

 

to unsubscribe to this list, please send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by http://www.readify.net to unsubscribe to this list, please send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by http://www.readify.net

to unsubscribe to this list, please send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by http://www.readify.net

to unsubscribe to this list, please send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by http://www.readify.net