Jun 182010
 

A recent friend asked me why he would be getting this error, and while debugging a splitting process, I came across this same error: hence this blog entry.

(not all of the time, but most of the time) What is going on is that the EDI data is being parsed by the EDI pipeline and resolving to a party, and I wanted to take a copy of that message and drop it to a folder so I can look at the claim to see what is really going on.

However when I assigned the data to the new message I simply sent it to the EDI assembler and assumed that it would create the EDI document and I could pass it along to the BA and they could tell me what needs to happen, yada yada yada.

All of the sudden I started getting these messages: Invalid character in data element.

What is actually going on is that when data is coming in, it is resolving to a particular party, but when going out, it does not have a party associated with it, so it defaults to the global party. The global party does not have a lot of the configuration options that are available to a defined party. One of those options are to allow decimals in EDI documents.

Here is what is in a defined party to get decimals to go in:

PartyValidationSettings

However, for the global party, the setting is not available.

This means that all data for a global party must be implicit decimal.

Change the following property to allow outbound decimals:

OutboundPartyValidationSettings

And in the orchestration, when you create the new message, make sure your code looks like this:

NewEDIMsg.MessagePart=EDIMsg.MessagePart;
NewEDIMsg(EDI.DestinationPartyName)=EDIMsg(MessageTracking.PartyName);

Jun 032010
 

I wanted to enhance my previous blog entry about how to successfully split the EDI transactions into individual claims.

The one liner does not adequately do justice as to what is really going on, so I thought I would embellish on how to get it properly configured,  and how to make changes (if you really want to).

The first thing is to explain the fundamental difference between the the single and multiple schema:

The BizTalk EDI Pipeline implements splitting at two levels:

1.  An interchange with multiple transaction sets (ST) will be split at the transaction level

2.  Additional splitting is controlled by annotations in the schema

        subdocument_break=”yes” in an annotation at top of schema switches the additional splitting functionality ON.

        At the segment level where additional breaks should occur attribute, subdocument_creation_break=”yes” is used

With the introduction of BizTalk 2006 R2, the EDI pipeline applied a different splitting behavior to “Multiple” schemas than had been applied from previous versions of BizTalk Accelerator for HIPAA.  BizTalk 2006 R2 would split subdocuments as per the “subdocument_creation_break” attribute but it would also include extra/non-essential sibling subdocument data which caused the output XML to be bloated and the splitting of large EDI files extremely slow.

A design change (KB 967945) was created to address the errant BizTalk 2006 R2 splitting behavior.  This hot fix restored the original and expected splitting behavior enjoyed in previous versions of BizTalk Accelerator for HIPAA.  With the hot fix applied, one would have to edit the “Multiple” schema to add an additional splitting attribute at the top of the document.  The new attribute should appear just after the subdocument_break=”yes” attribute and read as:  Split_Without_Sibling_Data=”Yes”.  Split_Without_Sibling_Data=”Yes” enables the new and efficient splitting behavior for “Multiple” schemas.

This design change was also forwarded into BizTalk Server 2009, but was not present in the released product.  Rather it appeared as a hot fix rollup, KB973415.  The KB973415 BizTalk Server 2009 rollup fix contains the new HIPAA 005010 schemas and the fix for new splitting behavior.  Again after applying this rollup fix, one must still edit all desired “Multiple” schemas to add the attribute,  Split_Without_Sibling_Data=”Yes”.

The schemas are mostly the same, except for the subdocument_creation_break attribute in the annotation:

<!-- Multiple -->
<xs:element name="TS837Q3_2300_Loop">
<xs:annotation>
 <xs:appinfo>
   <b:recordInfo structure="delimited" delimiter_type="inherit_record" field_order="infix" count_ignore="yes" child_delimiter="default" subdocument_creation_break="yes" notes="Claim information" />
 </xs:appinfo>
</xs:annotation>

<!-- Single -->
<xs:element name="TS837Q3_2300_Loop">
<xs:annotation>
 <xs:appinfo>
   <b:recordInfo structure="delimited" delimiter_type="inherit_record" field_order="infix" count_ignore="yes" child_delimiter="default" notes="Claim information" />
 </xs:appinfo>
</xs:annotation>

One thing that is not documented (at least I could not find it), is that after you downloaded and applied the 5010 hot fix, you need to add the following attribute Split_Without_Sibling_Data to the root <xs:appinfo> element

<!-- Out of the box -->
<xs:appinfo>
 <schemaEditorExtension:schemaInfo namespaceAlias="btsedi" extensionClass="Microsoft.BizTalk.Edi.SchemaEditorExtension.EdiSchemaExtension" standardName="EDI" xmlns:schemaEditorExtension="http://schemas.microsoft.com/BizTalk/2003/SchemaEditorExtensions" />
 <b:schemaInfo subdocument_break="yes" BiztalkServerEditorTool_Version="1.5" root_reference="X12_00401_837_I" displayroot_reference="X12_00401_837_I" version="3.0" standard="EDI" standards_version="00401" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" X12ConditionDesignator_Check="Yes" />
</xs:appinfo>

<!-- After modification -->
<xs:appinfo>
 <schemaEditorExtension:schemaInfo namespaceAlias="btsedi" extensionClass="Microsoft.BizTalk.Edi.SchemaEditorExtension.EdiSchemaExtension" standardName="EDI" xmlns:schemaEditorExtension="http://schemas.microsoft.com/BizTalk/2003/SchemaEditorExtensions" />
 <b:schemaInfo subdocument_break="yes" Split_Without_Sibling_Data="yes" BiztalkServerEditorTool_Version="1.5" root_reference="X12_00401_837_I" displayroot_reference="X12_00401_837_I" version="3.0" standard="EDI" standards_version="00401" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" X12ConditionDesignator_Check="Yes" />
</xs:appinfo>

If you don’t manually modify the schema, you will end up with all of the members in the transaction with one claim in each message that is submitted to the message box. ‘Bloated XML’ as a friend of mine calls it.

This means that you are now empowered on how to make changes to the splitting behavior, you can take the subdocument_creation_break attribute and move it from the claim level (2300) and move it to the member level (2000) and BizTalk will split the claims by members with all of that members claims grouped together.