About EDI / Property Schemas and Validate instance

In the future we need to process EDI documents so I am currently looking at some EDI Samples.

  • I did some tutorials (from Pro EDI in BizTalk Server 2006 Apress) and I created my own EDI schema based on X12_00401_810 (Exercise 1.0 to 1.4)
  • Then I had to create my own PropertySchemas to promote some nodes (Exercise 1.5)
  • Then I had to validate an instance of the schema i had just created....(Exercise 1.6 to 1.7)

But no matter what I did, I kept getting the same error over and over again. The errors were :

Invoking component...
D:\XXX\Schemas\X12_BatchSchema.xsd: error BEC2004: Object reference not set to an instance of an object.
D:\XXX\Schemas\X12_BatchSchema.xsd: error BEC2004: Validate Schema failed for file: <file:///D:\XXX\Schemas\X12_BatchSchema.xsd>.
D:\XXX\Schemas\X12_BatchSchema.xsd: error BEC2004: Validate Instance failed for schema X12_BatchSchema.xsd, file: <file:///C:\Apress.Integration\Chapter 1\Test Documents\Valid-Input.txt>.
Component invocation succeeded.

So I googled around a bit and tried to create a new solution. This has helped somebody who whas experiencing the same problems. But it Didn't help me. The same rror keept popping up.

Only when I removed the property schema from my solution (created in 1.5) everything worked as expected. So since there is very little docuementation on this behaviour I hope this can help anybodu in the future.

 

 

 

Published Mon, May 11 2009 2:06 PM by Patrick Wellink
Filed under: ,

Comments

# re: About EDI / Property Schemas and Validate instance

Thursday, June 11, 2009 10:34 PM by Ashish Talati

Patrick -

Sorry for posting comment here, but I was interested in the solution you have created on limiting orchestration instance ( bloggingabout.net/.../limit-the-number-of-instances-of-any-biztalk-service.aspx ).   Seems that codeplex source code is no longer available.  Do you still happen to have source?

Thanks

Ashish

# re: About EDI / Property Schemas and Validate instance

Friday, June 12, 2009 12:43 PM by Patrick Wellink

No Sorry, this code is no longer available.

Although the solution worked quite well it still used sequential convoys. And using sequential convoys in a orchestrations will make them slow if has to handle too many messages. The state of the orchestration is persisted for every loop. So, 10 loops go fine, 100 loops tak ea little longer and with 1000 loops, the system is only persisting state and flodding the DB with it.

This was not a problem of my solution but is a problem of sequential convoys. Since my solution used seq convoys it also suffers from this problem. Making it not as robust as it should be.

The only way I kan think of to limit instances is by using a database.... Sorry

Leave a Comment

(required) 
(required) 
(optional)
(required) 
Please add 1 and 5 and type the answer here: