v1.0 is a Visual Studio .NET 2008 add-in that provides the following features:

· A WSDL Wizard that allows the developer to step through the creation of a WSDL from one or more XSDs.

· A Data Contract Generator (similar to XSD.exe, XSDObjectGen.exe and SvcUtil.exe) that generates the .NET equivalent classes of the XSD types.

· A Service/Endpoint Stub (support for self-hosted and web-hosted) Generator and

· A Client Proxy Generator.

· A Generate Data Contract Code feature that supports the selection of multiple XSD/WSDL source files.

· A Paste XML as Schema option that generates a schema for a block of XML in the clipboard.

· Support for C# and VB.NET code generation.

· You can choose if operation methods on your service class will throw a NotImplementedException, call an implementation method in a partial class, or will be defined as abstract methods.

· Force the SOAP actions (Action and ReplyAction) applied to each operation contract follow the standard WCF format

· Errors found while processing the WSDL are reported in a pane in the Visual Studio Output window.

Please verify that the receive location exists....

Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases.

This error occurs because the web service is running on the application pool which security account user is not a member of the BizTalk Isolated Host Users group. in order to solve this error, you need to add the user that runs the web-service into the BizTalk Isolated Host Users group. Or change the application pool to the pool which user is already a member of the BizTalk Isolated Host Users Group. :)

COM+ was unable to talk to the Microsoft Distributed Transaction Coordinator (Exception from HRESULT: 0x8004E00F)

I've received this error while deploying a MSI application; although, I've found a solution of this error, which is:

"when you run a 32-bit program on a 64-bit Windows Server 2003-based computer"

however, I've deployed this application before. :| :|.
and Suddenly, I've check the services, and I found the Distributed Transaction Coordinator service is stopped !!!

after starting it, the error is gone. :)

Happy BizTalk to you – the Final

Welcome to machine again.

In this section we will discuss some of EAI patterns, and how these could be implemented in BizTalk.

  • Aggregator:

    Aggregator is the pattern of receiving information from multiple sources and consolidating it into a single message

  • Splitter:

    How can we process a message if it contains multiple elements, each of which may have to be processed in a different way?

    Use a Splitter to break out the composite message into a series of individual messages, each containing data related to one item

    In BizTalk, there is a concept known as Envelope splitting. This is a useful feature in BizTalk for splitting messages.

    The Splitter pattern takes a single message and splits it into multiple messages

  • Parallel Convoy:

    A parallel convoy enables multiple single messages to join together to achieve a required result. The set of related messages can arrive in any order, but BizTalk Server must receive all of them before starting the process.

  • Sequential Convoy:

    The Sequential Convoy pattern enables multiple single items to ‎join together to achieve something that an individual item cannot ‎accomplish by itself. A sequential convoy is a set of related items ‎that have a predefined order. Although the items do not have to ‎be exactly the same, BizTalk Server must receive the items in a ‎sequential order.‎

In order to understand better what business requirements require convoy messaging, consider the three business scenarios outlined in the following section.

Scenario 1: Hospital Admits a New Patient

Business Overview: A hospital admits a new patient. The hospital requires several pieces of information from the new patient including insurance information, past medical history, and contact information. Several different people collect this information including an insurance specialist, a nurse, and a receptionist. Several different systems process this information. The order in which collection and submission of this information occurs is not guaranteed. This is because some information collectors may be busy with other patients, the medical records department may be behind in their schedule, or the insurance system may be not functioning correctly. Assembling this information for the patient in an organized manner must occur throughout the time the patient spends at the hospital. This guarantees that the patient receives accurate care and correct billing.

Technical Overview: This process involves receiving several different pieces of information about a new patient in any order. All the pieces of information are required before the business process continues and admits the patient. This reduces the number of non-payments by guaranteeing the admission of only those patients with all the requirements. This also creates a race condition in which any one of the various messages can be the first to arrive and start the business process for the new patient. Because this is a new patient, no patient number is available for correlation or reference. Accomplishing correlation in this case occurs by using date of birth, social security number, or a combination of other demographics. Any one of the three messages may be required to start a new orchestration; this creates a race condition inside the message box.

Scenario 2: Standardized Test Taking and Grading

Business Overview: A student is getting ready to take a standardized test. As part of the testing process, the student registers for the test. After registered the student checks in at the testing center on the correct date and takes the test. Upon check out, checking the student's identity occurs again and the student leaves the testing center. Finally, the student's test arrives at the grading center. Only after the completions of all these steps in order, can the student's test be graded and a score recorded.

Technical Overview: Completion of this business process requires receipt of several different types of messages. In this case, there is a predefined order to follow in which to process these messages. After receipt of the four single messages, sending a single notice occurs to allow the student's test to be graded.

Convoy ‎ means multiple single items must be related together in order to achieve something that the individual item cannot accomplish by itself

Convoy processing can be additionally broken out into two separate categories as shown in the following list:

  • Sequential convoy - Sequential convoys are a set of related items that have a predefined order. The items do not have to be exactly the same. Grouping together requires that all they have to have is a purpose to group.
  • A real world example of a sequential convoy is a group of friends headed to a party traveling in separate vehicles. The overall goal is for all of them to reach to the party but in this case, only the first person has the directions. It is up to the lead vehicle to make sure they drive to the correct location and that all the other vehicles following are not lost. In order to make sure they all stay together, the leader instructs each following vehicle to put a blue flag on the vehicle's antenna. There are many other vehicles on the road going home, to work, or to another party but only the vehicles going to this party in this group have the blue flag.
  • Parallel convoy - Items that are in any order, but must all be present before something occurs, Parallel convoys are a set of related items that can be in any order. BizTalk Server 2004 must receive all the items before achieving the final goal. Shown here is this basic pattern. Another way of thinking of parallel convoys is like a door with many locks. The locks can be unlocked in any order. Only when the last key is turned will the door open. The key ring may have many different keys on it, but only one set matches this combination of locks.

  • Message Broker:

    Message Broker is the pattern of determining the destination of a message and still maintaining control over the message flow the goal of our generic message broker will be to dispatch any type of message to its destination decided at runtime. So, by avoiding type dependency and early routing binding (basically, hard-coding) we would get single very flexible orchestration which can easily handle requirement changes - one of the top goals of good application design.

    So, the question is how to implement these patterns in BizTalk?

    The answer is very simple, check this link J

    And enjoy BizTalking