Receive different IDOCs over one ReceiveLocation using ReceiveIdocFormat String with WCF-SAP Adapter from BizTalk Adapter Pack

Question

It is not possible to receive different IDOCs (e.g. MATMAS03 and DEBMAS03) with the WCF-SAP Adapter of the BizTalk Adapter Pack V.2.0 over one SAP “ProgramId” respectively one ReceiveLocation, when setting the ReceiveIdocFormat  property to “String”. In this case it is always mandatory to use a CustomPipeline with FlatFileDisassemblers for each IDOC. The problem is that the first FlatFileDisassembler in the CustomPipeline tries to disassemble all received IDOCs and we get an error like:

 

Unexpected data found while looking for: 'E2MARAM004'

The current definition being parsed is idocData. The stream offset where the error occured is 520. The line number where the error occured is 2. The column where the error occured is 0..

 

This did work in the “old” BizTalk Adapter “BizTalk Adapter v.2.0 for mySAP Bussiness Suite SP1” which is one of the LOB Adapters of BizTalk.

 

Reason: If you generate an IDOC schema with the property “GenerateFlatFileCompatibleIdocSchema” is set to “true” the schema file in the 15^th Line bottom-up in the file “IDoc.MATMAS03.46C.3.xsd” says:

<recordInfo structure="positional" sequence_number="1" tag_name="EDI_DC40" tag_offset="0" preserve_delimiter_for_empty_data="True" suppress_trailing_delimiters="False" xmlns="http://schemas.microsoft.com/BizTalk/2003">

</recordInfo>

 

But it should say, as the “old” Sap Adapter similar does:

<recordInfo structure="positional" sequence_number="1" tag_name="MATMAS03" tag_offset="39" preserve_delimiter_for_empty_data="True" suppress_trailing_delimiters="False" xmlns="http://schemas.microsoft.com/BizTalk/2003">

</recordInfo>

 

Please check if this issue is a bug, or how can we receive different IDOCs with ReceiveIdocFormat property “String” with one ProgramId respectively one ReceiveLocation in BizTalk.

Answer 1

Hi,

I think this is just he behavior of the FlatFileDissasembler. He will use probing to see if this message matches the schema.

So it could be that that probing "Fails". So it has a wrong match.

You could try to adjust you IDOC schema. Try looking at "Lookahead Depth" and "Parser Optimization" on the <Schema> node. Try with a Lookahead Depth of 0 and Parser Optimization set to "complexity".

Kind Regards

Tim D'haeyer

Answer 2

Hello Tim,

thank you very much for this information.

I have a problem to set this properties in the schema editor in visual studio. The flatfile extension properties are not shown in the properties dialog. In the Schemas from the "old" biztalk adapter I can modify this properties.

In the xsd itself I can see, that the Parser Optimization is set to "complexity" but the property "Lookahead Depth" is not defined.
So I defined the Property Schema Editor Extensions to FlatFile Extension, than I can set both parameters, which you said.
The problem is, that the FlatFile Extension is defined doubled in the xsd than.

(Notice: I have generated the schema with the property: GenerateFlatFileCompatibleIdocSchema = "true")

Thanks in advance
Harry Bergen

Answer 3

Hi Harry,

Have you tried manually adjusting the XSD and add the Lookahead Depth attribute? You could always give that a try.

If that doesn't do the trick, then it means that you have no control over this schema.

Is there a reason why you use the FF compatible IDOC schemas? Because I know that you can receive all IDOC types from SAP in one receive location if you use the "XML version" of the schemas.

If you really want to keep the FF schemas, you could write a custom pipelinecomponent that will call the FF Disassembler. Then at runtime you lookup the IDOC type and set the correct FF schema for the Disassembler to use. But if you can avoid this, I would go for a more standard way. If this is your only way out, I can provide some help for this since I have written something similar for a project.

Kind Regards

Tim

Answer 4

Hi Tim,

I will try to modify manually the xsd for the Lookahead Depth in the next week.

I would like to use the "Receive Idoc Format = Typed" that FF Schemas are not needed, the problem is discussed in the following thread:
http://social.msdn.microsoft.com/Forums/en-US/biztalkr2adapters/thread/28a5d89c-ad0d-4ce6-9c45-c35ecf9fe32b

I would like to go the standard way, so I found the workaround, which I have discribed in my first post, but I'am not surprised that I have to modified all generated schemas.

But it seems for me, that it is a bug, that the FF Properties are not shown in VS. But I don't now if it is a bug in VS or in the schema generator of the biztalk adapter pack V2 or WCF LOB Adapter SDK SP2. Do you use this adapter with BizTalk 2009? Does this "bug" exist when working with VS 2008 to?

Kind Regards
Harry

Answer 5

Hi Harry,

Maybe it's not really a bug. I think they don't want you to mess with the schemas. :)

Because you can off course change stuff that you shouldn't.

Or it could be something that has been overlooked when creating this. You'll see when you try it off course.

What the lookahead depth will do, is change the way that BizTalk probes the message. And zero means infinite.

This will off course affect performance! But in my experience it's not that your Disassembling will be very slow. It's still fast.

If the lookahead depth only doesn't help you, you can try setting the "Fixed" attribute on your MESTYP and IDOCTYP fields in the EDI_DC40 header. Maybe together with the lookahead depth. Maybe this can solve your problem without having to write a custom component.

Kind Regards

Tim

Answer 6

Hi Tim,

if that is not realy a bug in VS. Then it is a bug in the XSD Generator, isn't it? Because it should generated shemas, that receiving multiple idocs with one receivepipeline and one receivelocation is possible. Do you think so too?

Kind Regards
Harry

Answer 7

Hi Harry,

That's indeed something that they maybe forgot about. You could try to report it to Microsoft to see if there is a fix.

did you try to adjust the schema a bit?

Kind Regards

Tim

Answer 8

Hi Tim,

I have reported this to microsoft, now we will see what they will say.

Kind Regards
Harry