by stephen-w-thomas | Apr 4, 2005 | Stephen's BizTalk and Integration Blog
Microsoft has released 5 new White Papers today in a “Beta” mode. Full details on all 5 are available here.
They include the following:
– BizTalk Server 2004 Web Services (Brian Loesgen)
– BizTalk Server Internal Workings (Internal)
– SQL Adapter Deep Dive (Todd Uhl)
– Convoy Deep Dive (Stephen W. Thomas)
– Extending BizTalk Server with Host Integration Server (Jon Fancy)
They all look like great reading. I’m rather fond of the Convoy Deep Dive paper myself.
As always, feedback is welcome.
by community-syndication | Apr 2, 2005 | BizTalk Community Blogs via Syndication
We (Melbourne & Sydney BizTalk User Groups)have just set up a BizTalk mailing list, with the same idea in mind as the aus-dotnet & SQLdownunder list. You can subscribe to it by clicking here and pressing send.
by community-syndication | Apr 1, 2005 | BizTalk Community Blogs via Syndication
Originally BizTalk Server 2004 has the limitation of adding new EDI schemas. However SP1 now allows to add new schemas and the KB article 840113 describes how to implement EDI schemas for BizTalk. I had implemented new EDI schemas with the KB article. But I realized right away that some information is missing.
I summarized some additional information which the KB article doesn’t mention. I hope this would be helpful to someone who wants to implement EDI schemas, especially EDIFACT schemas.
by stephen-w-thomas | Apr 1, 2005 | Stephen's BizTalk and Integration Blog
In addition to all the other cool stuff available in BizTalk Server 2004 Service Pack 1 is the addition of the Additional Flat File Schema Properties to the schema properties window when working with Flat Files.
Now, properties like Allow Early Termination, Generate Empty Nodes, Lookahead Depth, Parse Optimization, and Suppress Empty Nodes can be set inside Visual Studios. This will eliminate the tedious and error prone manual editing of the schema using notepad. Error prone? Yep, I messed this one up once…
by community-syndication | Apr 1, 2005 | BizTalk Community Blogs via Syndication
I’ve been very busy for last two months. During that time, I made a converting tool for BizTalk Base EDI Adapter.
Originally, BizTalk Server 2004 had the limitation of adding new EDI schemas. However, BizTalk Server SP1 now allows to add new schemas. This tool generates XML schemas for Base EDI Adapter from some legacy artifacts. To be honest, this tool generates KEDIFACT XML schemas and KEDIFACT is a variation of EDIFACT. I uploaded 41 KEDIFACT schemas of 1911, 1921, 2911, and S93A directories. I guess you also can utilize these schemas for EDIFACT with same directories because KEDIFACT has very similar directories and message types as EDIFACT. I think it requires only small changes. If you have any problem to use them for EDIFACT, feel free to drop your message.
by stephen-w-thomas | Apr 1, 2005 | Downloads
Microsoft BizTalk Server 2004 supports the use of convoy message processing, a new messaging pattern. Convoys are a messaging pattern and not a feature of BizTalk Server 2004. A convoy is not something a customer can use, like the Rules Engine, but instead it is something that the business process dictates and requires.
This paper discusses examples of business scenarios that require convoy message processing. After establishing a business need through the scenarios, this paper explains basic convoy theory and the different types of convoy messaging patterns. This paper discusses a solution to each business scenario and reviews each included sample.
View this whitepaper online at: http://msdn2.microsoft.com/en-us/library/ms942189.aspx
by stephen-w-thomas | Mar 31, 2005 | Stephen's BizTalk and Integration Blog
Today I was working on some content for Tech Ed when I found a major error in a sample I posted about 4 months ago.
The error caused the CR-LF’s between records to be included in the positional character count during debatching and actually into the messages themselves. This through off the file layout but did not give any errors. In fact, the expected result of three files were received. They just did not have the right data in them.
I have seen similar problems in the past were the Flat File Disassembler does not behave in any way as I would expect.
Below is before and after screen shots of the schema.
Before: After:
The error is easily fixed by added an additional node into the schema that is Delimited, Post Fixed with CR-LF as the Hexadecimal delimiter. This fix was required in both the Header and SingleRecord schemas.
The updated sample is available for download.
Download: Flat File Disassembler Sample
Watch the video: Flat File Disassemblier Output Options Video
by stephen-w-thomas | Mar 30, 2005 | Downloads
The flat file disassembler can produce single record output or a single batch output. This sample shows how to accomplish each task when you need it. Make sure to read the blog content below for additional information.
This sample should work with BizTalk 2004 and BizTalk 2006.
Get more information from the original blog post on this topic: http://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/12/17/flat-file-disassembler-output-types-in-biztalk-server-2004.aspx
by stephen-w-thomas | Mar 29, 2005 | Stephen's BizTalk and Integration Blog
Recently I have seen a lot of talk about large message support in BizTalk 2004. The most interesting and depressing was on the BizTalk Core Engine WebLog. It seems that large messages do not work as well in BizTalk 2004 as I would have hoped.
I have had success with some types of large messages using the file adapter and mapping. I have gotten it to work with messages up to 500 MB but in a production environment this would not be a viable or supported solution.
During some recent testing, I discovered the follow condition that rather surprised me.
Scenario
I was returning an unpredictable amount of data out of an Oracle database using .net code. This data can be 1 MB or up to 250MB+ and needed to be processed in a single batch. This data is then converted into Xml, cast to a message, and mapped with the results written to disk using a Send Shape. Life was good until the extracted data returned was greater then 220 MB in size.
At this point, everything went downhill. BizTalk Server began to have serious problems. Receive functions were shutting down and I received the following Warning message in the Application Log:
A catastrophic failure occurred in the BizTalk service. The service will shutdown and auto-restart in 1 minute. If the database is still unavailable, this cycle will be repeated.
Error message: Exception of type System.OutOfMemoryException was thrown.
Error source:
BizTalk host name: BizTalkServerApplication Windows service name: BTSSvc{E93E7C4A-9E8B-40F6-AD7C-4F53B85F36C4}
For more information, see Help and Support Center at
All appears to be well and good since BizTalk seems to be handling the situation as expected… except for when the service actually starts again. Since the Orchestration that caused the fatal error is still Active (the Orchestration itself did not through any errors), BizTalk starts to process the Orchestration from the last persistence point. Thus, repeating the cycle in an endless loop.
Now, for the interesting behavior… If this is running in a multi server BizTalk environment at the point the 1st BizTalk Server fails the 2nd one picks up; like I would expect. I end up getting a completed Orchestration with no errors. Super! But, I only get a zero byte file as output. So, looking inside HAT everything would look like it completed successfully with no errors. Not good…
Overall, I found that an Orchestration seems to be able to handle about 440 MB of “stuff” before it crashes. Just make sure you know what makes a copy of the message (like mapping). Of course, processes with this amount of data would not be supported nor do I recommend actually doing it. But, it has been fun to play around with and see what fails.
The moral of this story is to be very mindful of your message size.
