No Disassemble stage components can recognize the data

[Redd]

I have a HIPAA solution that processes inbound 271 messages. It has
been working for a while now. All of a sudden, I get suspended
instances with the following errors logged in the event log:

A message received by adapter "FILE" on receive location "<rloc name>"
with URI "<path>*.xml" is suspended.
Error details: There was a failure executing the receive pipeline:
"Microsoft.BizTalk.DefaultPipelines.XMLReceive,
Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Receive
Port: "<port name>" URI: "<path>*.xml" Reason: No Disassemble stage
components can recognize the data.

Looking at the 271 message itself, I don't see any funny characters.

In fact, this error happenned on a file I had tested a few days ago,
and at that time, the file was processed successfully! I don't
understand why the same file would suddenly fail with the above error.

Any ideas as to what could be causing this?

Thanks for your help,
Redd

[Eric Stott]

Make sure that you have your schemas deployed, that they are still in the
GAC. I would recommend using the assembly viewer to make sure.
http://msdn2.microsoft.com/en-us/library/aa560741.aspx

Eric
http://blog.biztalk-info.com

"Redd" <redb...@yahoo.com> wrote in message
news:1177104315.1...@b75g2000hsg.googlegroups.com...

[Redd]

Thanks for the reply!

I installed and ran that tool--it is really cool! Thanks for pointing
that out to me.

Unfortunately, all my assemblies were indeed present when I ran the
viewer.

I've tweaked some of the maps and re-GACed them; I didn't want to
undeploy everything just to update a map. This worked fine in Biztalk
2004, and seems to be the same in 2006. Could doing this somehow
"corrupt" something?

I could try to uninstall everything and redeploy from scratch. But
that would not be a luxury I would have if this were in production.
So, I'd like to try to find out why this is happenning before
resorting to such a drastic measure.

Can you offer any other suggestions?

Thanks,
Redd

[Eric Stott]

Change both send & receive pipelines to passthru, run the file again, take
the resulting xml file again and validtate it against the schema.

Eric
http://blog.biztalk-info.com

"Redd" <redb...@yahoo.com> wrote in message

news:1177107090.4...@e65g2000hsc.googlegroups.com...

[Redd]

I did that and ran 2 files through the ports. One fails and writes
out the original EDI content to the output folder, while the second
works fine and writes out valid XML.

I examined both files closely but could not find anything wrong with
the file that failed.

I went to the EDIFECS website and uploaded the file that failed and
had it tested to see if there was anything wrong with it that I could
not spot, but it passed all validation with flying colors.

The two files are the same request and only differ in the time and
date of the request. Otherwise, all the other data is the same.

This is the error that appeared in the event log for the file that
failed when I ran it through the test you suggested (Note, I've 9'd
out the sender IDs):

Status report details: SRH mybox
20070423100948 2
DEFAULT
SRM 00000000 00010380 1 5
00401 HB09translate
failed
000000000000000000000000010163
SRE 001041check_grphdr 00000
000
0
(msgnr:0 segnr:0)(line:0 pos:147 filepos:147)sender: [][] [9999999999]
[30][9999999999]\r\nsender: [][] 9999999999][30][9999999999]

I see "HB09translate failed"... But I cannot find any HB09 items in
the 271 specifications.

Also, file position 147 coincides with element GS08, but the value of
"004010X092A1" looks just fine to me.

The file that works--that XML validates fine, btw.

The only other thing I can think of is maybe unicode vs ASCII... is
that a potential source of contention with the accelerator?

Any other ideas?

[Eric Stott]

If it is UNICODE and not ASCII, it will cause a problem. If you look at the
WPC IG it states what is allowed:
The basic character set of this standard, shown in figure A2, Basic
Character Set,

includes those selected from the uppercase letters, digits, space, and
special

characters as specified below.

A...Z 0...9 ! " & ' ( ) * +

'

- . / : ; ? = " " (space)

An extended character set may be used by negotiation between the two parties

and includes the lowercase letters and other special characters as specified
in figure

A3, Extended Character Set.

a..z % ~ @ [ ] _ {

} \ | < > # $

Figure A3. Extended Character Set

"Redd" <redb...@yahoo.com> wrote in message

news:1177343459....@o5g2000hsb.googlegroups.com...

[Chris Miller]

HB is the GS01 code that the parser uses to recognize the transmission as a
271. (its HS for the 270) - as they both use the same GS08 value.

Perhaps the parser is trying to use the 270 schema?

"Redd" <redb...@yahoo.com> wrote in message

news:1177343459....@o5g2000hsb.googlegroups.com...