We get many requests regarding proper Error Handling within an Orchestration. How to catch and handle certain errors would be a great example. Another request is proper use of transactions....both Long Running and Atomic. The previous release had a good compensating transaction example, but nothing regarding an Atomic Scope. It would be great to include an Atomic Scope example that used a .Net Serviced Component.

Scott,
Actually this is about adapters/tools rather than samples. Any chance of incorporating some of the GDN adapters and other little tools that the community has contributed and polishing them up to bring them in line with BTS component standards so we can get them all out of the box next time instead of having to search round various sites for free components?

- benjy

I would like to see atleast one sample that includes orchestration and business process for health insurance industry.

Since you plan to remove HWS (correct me if I am wrong) please provide some alternatives for it or some samples to a replacing technology. <br> <br>Keep up the good work, <br>Angelo

I'd love to see samples showing integration with the Patterns and Practice group's Enterprise Library; in particular the Exception handling, logging, and configuration blocks. I'm finding a lot of customers are planning to use this in regular .NET projects and would like to reuse the same techniques with BizTalk.

Scott, <br>I would like to see examples around the extensibility of the BizTalk Tools, such as the editor. For example perhaps the source code of the Flat File Extensions.

Hi Scott,

Based around Orchestrations.
(1) Using Config properties in an Orch. e.g. from an equivalent 'Web.Config' file (c.f. for Web Based Apps)

(2) Throttling - Orchs that process msgs One a time to send onto a legacy system that dies if it has more than one msg fed to it at once.

(3) An sample App using the BTS API (or WMI) that determines whether your (long running Orch) is still running + possibly how many there are waiting.

(4) Lastly, Rules Engine rules that get asserted in response to a certain time.
e.g. Govt. poilicy changes are enforced midnight, discount is now 10%. How can we be certain that the very next request at 12.01 uses the new rule policy??

Would be coool!

Scott,

1. Several additional content based routing examples (message broker pattern).

2. Several additional orchestration patterns including logical message splitter (not just debatching).

3. A bunch more rules engine examples with better documentation. This is a huge topic that takes alot to get your hands around.

4. Migration examples & scenarios from BTS2002. You still have alot of customers on BTS2002 that really need to move to BTS2006 (or BTS2004).

Hi, <br>Regarding the EDI Adapter. Small organizations that send EDI to larger trading partners are typically assigned Sender IDs by their larger trading partners. The current Covast EDI Adapter allows for configuring ONE sender address, in the adapter's send handler. This is great for IBM or Microsoft or Medicare, but not for the little guys who can't dictate their own sender IDs. You need a sample showing how to work around this if you want your product to be marketable for smaller organizations using it for EDI purposes. This is especially true of the HIPAA EDI Accelerator 3.0. At least BTS 2002 could handle this scenario by allowing for specific application_sender_code values in the document definition for a particular channel, and multiple 'aliases' for the Home Organization. Thanks. <br>JT

This sounds like fun!

1. A more complete coverage of orchestration scopes - the most important part in BTS for handling compensation.

2. Deployment. This seems to be a 'lost' topic today, but belive you me - we do have to deploy things to get the machine rolling.

3. Versioning (unsure about the spelling :-) ), no good samples and/or help topics about this. Very important for evolving projects.

4. Good architecture - I just love the party handling and orchs with canonical messages but the lack of good samples is big.

5. A BTS2006-version of the upcoming BTS2004 EDRI would be ass-kicking!

/andreas

The thing I miss the most, apart from some of the things already mentioned, is in error handling. Exception handling and compensation are simple and covered in the documentation, but most examples are way too simple (or omiss) in what concerns error handling. I would like to see the (classic) PO example with some (recomended) error handling in it, and others.