What is diffrence between Context-Based Routing and Content-Based Routing?
Context based routing is based on the Context of the message ie fields like Recieve Port Name,Message Type,etc which are populated by default by BizTalk.
Content Based routing is based on the field which one promotes and use it as a filter on any port for routing Purpose like you promote "EmpRegion" field in your XML Schema and use it as filter on any Send port for dropping files of region USA in USA Folder. The field should have a value "USA" to be dropped on to that folder.

what is the difference between promoted and distinguished property? Answer
# 2

There are two different ways in which you can

programmatically access an attribute or element in BizTalk,

they are called Distinguished Field(Show) and Promoted Property(Quick).

The main differences between them are summarized in the

table below.

Promoted properties can do everything and more than

distinguished fields, but this doesn't mean that

distinguished fields are less useful. Actually you should

prefer the use distinguished fields whenever possible:

Distinguished Field Promoted Property

Syntax:msgOrder.CustomerId msgOrder(BookShop.CustomerId)

Access method:Using XPath in runtime. Inserted in message context during

pipeline processing.

Can be accesses by:Only in code in orchestrations. Both in orchestration code and

in the messaging configuration

(e.g.filters on send ports).

Storage:Only run-time access A promoted property is stored in the

message context.

Constrained by message contents Yes,

only values within the message may be accessed (Quick)No, any type value can be promoted in a

pipeline (there is no need for the value to be

contained in the message).

Routable: No Yes, as they are attached to the message

Context they can be used for routing

Expensive (whatever that means): No Yes, even if they are never used they

are always read and inserted into the

message context. As the message is

passed through the MessageBox and

Orchestration the context needs to be

Copied and stored.

Visible in HAT : No Yes

Size limit: Unlimited Max 256 characters

XSD type support:More than prom.prop. Less than dist.fields

Which one of these two ways to access elements/attributes in a message should you choose?

The answer will present itself if you answer the following questions:

* Do you need to route on the information in the element/attribute?

* Do you need to track the element/attribute?

* Do you need to use information that can only be dynamically created, i.e., it is not directly accessible in the message.

If the answer to any of these questions is Yes, then you need to use a promoted property. If the answers to all questions are No, then you should use a distinguished field.

Depending on the type of solution you are creating you will find that you use one of these more than the other.Messaging solutions typically use promoted properties to route incoming messages to the correct destination, there is no need to use distinguished fields in messaging solutions as you no way of accessing the value.

If you are building a solution containing orchestrations that model business processes you will probably mainly use distinguished fields. The reason for this is that you will have less need for the routing capabilities of promoted properties, and as it is less expensive from a performance perspective to use distinguished fields you should prefer these. In orchestrations you can use distinguished fields in

a number of ways; conditions for looping and decisions shapes, expression shape and message assignment shape.

Basic rule for which to use would be: always use a distinguished field, unless you have to route, track, or

correlate on the source content, then use a property (i.e. promoted field).

Correlation is a Process of associating an incoming message with the appropriate instance of Orchestration.

why we are adding refference in the orchestrations?

why ur creating msgs in orchestrations?

what is quick promotion and show promotion?

what is content layer and context layer?

why ur selecting quick promotion and u r not selecting show promotions?

Property Schemas

In Microsoft BizTalk Server, promoted properties enable various BizTalk Server components to access key items of data, known in this context as distinguished fields and property fields that arrive within an instance message without needing to know how to look for them within the message itself. For different types of messages, you can determine which items of data require promotion to a more visible level. Depending on how you choose to promote such fields, you may need to create and define an associated property schema.

Note

Promoted properties are restricted to non-repeating elements/attributes.

Distinguished fields are accessible only within orchestrations and do not require the creation of a corresponding property schema. If you only need to access promoted message data from within an orchestration, you can promote the data as one or more distinguished fields.

Property fields are accessible from within various BizTalk Server components, including pipelines and orchestrations. Property fields can also be used for message routing. If you need to access promoted message data from contexts other than within orchestrations, you must create one or more property schemas to describe the data you are promoting.

A property schema is a special schema that you associate with a message schema. It is used for promoting specific values from within an instance message into the message context. Property promotion provides a centralized mechanism for pulling key pieces of information that you define from within an instance message and making it more easily accessible to BizTalk Server components that are handling the message as it passes through BizTalk Server.

You can automatically create a default property schema by using the quick promotion feature of BizTalk Server. This is the easiest way to create the property schema required for property field promotion. For more information about how to perform quick promotions, see How to Copy Data to the Message Context as Property Fields.

You can also create new property schemas. When a BizTalk project is open, select the BizTalk project, right-click and select Add, click New Item, and then click Schema.

Note

If a property schema is associated with a message schema, then these two must be in the same BizTalk project. Separating property schema from its associated message schema in different BizTalk projects is not supported.

Note

If you have two property schemas that have the same namespace, even though they are defined in different assemblies, the schemas will not resolve properly at runtime. You will get a routing failure at runtime.

There are two types of property promotion: distinguished fields and property fields. The latter type uses property schemas. In BizTalk Editor, you manage both of these types of property promotion by using the Promote Properties dialog box, which you access by using the Promote Properties property of the Schema node.

Note

There are some restrictions on values that you can promote. For more information, see the table in Promoting Properties.

Note

Distinguished fields do not appear in filter expressions. Only property fields appear in filter expressions.

Property schemas are simple when compared to message schemas. In the schema tree, you are only allowed to insert Field Element nodes as immediate child nodes of the Schema node, creating a structure that is two levels deep. For the most part, you set the properties of the Field Element nodes as you would for Field Element nodes appearing in a message schema. You are limited to using only XSD simple types.

Important

You should not rename any schema that is being used by another schema. This includes property schemas for which promotions have already been established. If you do so, the schema that is being used will not be able to find the other schema because the name it contains will no longer be accurate.

The Property Schema Base property is unique to Field Element nodes as they appear in property schemas. This property is blank by default, but can be set to either MessageDataPropertyBase or MessageContextPropertyBase, resulting in a propSchFieldBase attribute being added to the fieldInfo annotation element with one or the other of these values.

When the propSchFieldBase attribute is set to MessageDataPropertyBase, it means that the value of the promoted property corresponds to data in the message, such as the value of some field. When the propSchFieldBase attribute is set to MessageContextPropertyBase, it means that the value of the promoted property may be from somewhere else, such as an envelope, or that it may be set by a pipeline component.

Field Element nodes in property schemas also have a property called Sensitive Information, which when set to Yes, will keep the corresponding value from being visible from within BizTalk Explorer and message event and service instance tracking, thereby preserving its sensitive nature.

The following XML Schema definition (XSD) language representation of a property schema contains an annotation associated with the schema element that identifies this schema as a property schema (schema_type="property"). It also contains three Field Element nodes below the Schema node. The first Field Element node, named PromProp1, does not have a value defined for its Property Schema Base property, but the latter two Field Element nodes have that property set to MessageDataPropertyBase and MessageContextPropertyBase, respectively.

<?xml version="1.0" encoding="utf-16" ?>

<xs:schema xmlns="http://BizTalk_Server_Project1.PropertySchema1"

xmlns:b="http://schemas.microsoft.com/BizTalk/2003"

targetNamespace="http://BizTalk_Server_Project1.PropertySchema1"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:annotation>

<xs:appinfo>

</xs:appinfo>

</xs:annotation>

<xs:element name="" type="xs:string">

<xs:annotation>

<xs:appinfo>

</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element name="" type="xs:string">

<xs:annotation>

<xs:appinfo>

</xs:appinfo>

</xs:annotation>

</xs:element>

<xs:element name="" type="xs:string">

<xs:annotation>

<xs:appinfo>

</xs:appinfo>

</xs:annotation>

</xs:element>

</xs:schema>

Different Types of BizTalk Schemas

BizTalk Server supports the following four types of schemas:

XML schema. An XML schema defines the structure of a class of XML instance messages. Because this type of schema uses XML Schema definition (XSD) language to define the structure of an XML instance message, and this is the intended purpose of XSD, such schemas use XSD in a straightforward way.
Flat file schema. A flat file schema defines the structure of a class of instance messages that use a flat file format, either delimited or positional or some combination thereof. Because the native semantic capabilities of XSD do not accommodate all of the requirements for defining the structure of flat file instance messages—such as the various types of delimiters that might be used for different records and fields within the flat file—BizTalk Server uses the annotation capabilities of XSD to store this extra information within an XSD schema. BizTalk Server defines a rich set of specific annotation tags that can be used to store all of the required additional information.
Envelope schema. An envelope schema is a special type of XML schema. Envelope schemas are used to define the structure of XML envelopes, which are used to wrap one or more XML business documents into a single XML instance message. When you define an XML schema to be an envelope schema, a couple of additional property settings are required, depending on such factors as whether there are more than one root record defined in the envelope schema.
Property schema. A property schema is used with one of the two mechanisms that exist within BizTalk Server for what is known as property promotion. Property promotion is the process of copying specific values from deep within an instance message to the message context. From the message context, these values are more easily accessed by various BizTalk Server components. These components use the values to perform actions such as message routing. Promoted property values can also be copied in the other direction, from the more easily accessible message context back into the depths of the instance message, just before the instance message is sent to its destination. A property schema is a simple version of a BizTalk schema that plays a role in the process of copying promoted properties back and forth between the instance message and the message context.
The remainder of section provides additional information about these four types of schemas in BizTalk Server.

Flat File Schemas

Flat file schemas serve two purposes. They define all of the same record and field characteristics (including structure) as XML schemas, and they provide a mechanism for defining all of the flat file characteristics that are required to translate a flat file instance message into an equivalent XML instance message (or vice versa). The former purpose is most useful when using the flat file schema within BizTalk Mapper to define a transformation of conforming flat file instance messages into a different, destination structure. The destination structure, defined by the destination schema in BizTalk Mapper, may or may not be governed by a flat file message schema (it could be an XML schema).
The latter purpose, that of translating between the flat file format of the document and its equivalent XML format, uses an extensive set of information that is added to the XML Schema definition (XSD) language schema using its annotation syntax. This information is superfluous from an XSD perspective, in terms of its usefulness in validating an XML instance message against the schema that governs its structure. Nevertheless, the XSD annotation syntax provides a convenient mechanism for storing flat file structure information within the XSD schema within a variety of different scopes, ranging from schema-wide information stored as annotations within the schema element, to information that is specific to a particular record or field, stored as annotations within the corresponding element or attribute element.
Another characteristic of flat file schemas that make them different than their XML counterparts is the fact that instance messages cannot be matched to their governing schemas based on their content. Instead, a static set of schemas must be specified for use by the flat file disassembler at runtime.
To see the additional node properties associated with the characteristics of flat files, you need to specify the Flat File Extension by using the Schema Editor Extensions property of the Schema node. They do not appear by default.
For detailed information about the node properties that are specific to flat file schemas, see Supplemental Node Properties for Flat File Schemas.

Envelope Schemas

You can create an envelope schema in all of the same ways that you can create an XML schema for a business document. You can create a schema from a well-formed XML envelope instance message, or from Document Type Definition (DTD) or XML-Data reduced (XDR) representations of the envelope schema. Or, you can create a new schema, either in conjunction with other schemas or not. Because envelope schemas are generally much smaller and less complicated than most business document schemas, creating new envelope schemas is usually a viable alternative.

To define a schema as an envelope schema, you need to set the Envelope property of the Schema node to the value Yes. When you define an envelope schema, you should point the envelope's Body XPath to the parent node that contains only the <any> child element. In order for the XML assembler to use the envelope, the parent node must not contain any other elements.

When you set Envelope property to Yes, it means that the actual message content of the XML instance message (called the body of the message) is present somewhere inside the root Record node of this schema, as specified by the Body XPath property of that node. Therefore, you must also set additional properties based on a variety of conditions:

If an envelope schema has a single root, you must set the Body XPath property for that root.
If an envelope schema has multiple roots and the Root Reference property is not set, you must set the Body XPath property for all roots.
If an envelope schema has multiple roots and the Root Reference property is set, you must set the Body XPath property of the corresponding root Record node. You can optionally set the Body XPath property for the remaining roots.
Regardless of whether an envelope schema has a single root or multiple roots, setting the Root Reference property is not required.

What is MessageType?

Messages in BizTalk are data, and each message must be of a selected message type. The most common message type in BizTalk is a schema, which is to say the message is based on an .XSD file that specifies the record and field structure in the message.

(OR)

BizTalk sets a message context property called BTS.MessageType. This is a concatenation of the document namespace and Root Node Name in other words Message Type is a BizTalk System property that is promoted inside a Pipeline. It is made up of Document Name Space and Root Node Name.

http://www.dotnetfunda.com/interview/exam512-what-is-messagetype-in-biztalk-server-.aspx

Please see msdn2.microsoft.com/en-us/library/ms942182.aspx for a full discussion of schemas and maps in BizTalk.

What is the difference between a "Message Assignment" shape and an "Expression" shape?

A "Message Assignment" shape is used to create a new message and assign values to it.

A Expression shape is used to assign values to variables and also write 'if' conditions.

List out some Artifacts of BizTalk Server?

#. HAT
#. BAM
#. Adapter
#. Pipeline
#. Orchestrations
#. Role Links
#. Send Ports and Send Port Groups
#. Receive Ports
#. Receive Locations
#. Policies
#. Schemas
#. Maps
#. Resources
#. BAS Artifacts (Business Activity Services)

What is the latest version of BizTalk Server?

The latest version of BizTalk is BizTalk Server 2009 and IDE to develop application is Visual Studio 2008 SP1.
Top New Features
BizTalk Server 2009 introduces enhancements and new featured in four main areas:
Updated Platform Support
Support for Visual Studio 2008 SP1
Support for .NET Framework 3.5 SP1
Support for Windows Server 2008
Virtualization support with Hyper-V
Support for SQL Server 2008

Developer & Team Productivity
New Application Lifecycle Management (ALM) experience - with Support for TFS - integrated source control, bug tracking, unit testing, MSBuild automation

Enhanced Developer Productivity with Visual Studio project system updates & Map Debugging

SOA and Web Services
ESB Guidance 2.0
New UDDI v3 Web Services Registry
New and enhanced LOB adapters (Oracle eBusiness Suite, SQL Server)
Enhanced host systems integration (WebSphere MQ, CICS, IMS)
Enhanced BAM support

Business to Business Integration
New Mobile RFID Platform
New RFID device management and industry standards support
Enhanced Support for EDI and AS2 Protocols and Drummond certification
Updated SWIFT Support and SWIFTReady Financial EAI Gold certification

Please refer to http://www.microsoft.com/biztalk/en/us/whats-new.aspx

What is the difference between Distinguished field and Promoted Property?

Promoted properties can be accessed in Orchestrations, ports, pipelines, schemas. They Use server resources.

Distingished fields are light weight and can be accessed only in Orchestrations.

For more details, please go through http://geekswithblogs.net/LeonidGaneline/archive/2008/07/09/biztalk-distinguished-fields-and-promoted-properties---additional-information.aspx

What is Correlation in context of BizTalk Server?

An Orchestration can have more than one instance running simultaneously. Even though each of those multiple instances perform the same action, it does it on different data contained within a message.

Correlation is a process of associating an incoming message with the appropriate instance of an orchestration.

For Example: If your orchestration issues a purchase order, receives an invoice, and sends a payment, the developer must make certain that the invoice message is received by the orchestration instance which corresponds to the orchestration that sent the Purchase Order. Without correlation, it would be possible to send out an invoice for thousands of items even though the purchase order is for one. And each correlation is based on a set of properties known as correlation types.

What is the difference between a Document Schema and a Property Schema?

A document schema is used to define a message. It is a definition on an Xml message with optional extensions for flat files, EDI file, etc that enable the parsers to convert the native format into Xml.

A property schema is used to define message context properties. These can be of type MessageDataPropertyBase (the property value is promoted or demoted from/to the message itself) or MessageContextPropertyBase(property value only exists within the message context and can be set by adapters, pipelines or within orchestrations).

If you wish to promote a field from a message into the message context then you need to define a document schema and property schema. In the document schema you promote the required field using the property schema to define the property type that will be used in the message context.

What is Biztalk Orchestrations Dehydration and Rehydration?

Dehydration:
When an orchestration has been idle for a while, the orchestration engine will save the state information of the instance and free up memory resources.

Rehydration:
When a message is received, or else when a timeout has expired, the orchestration engine can be automatically triggered to rehydrate the instance – it is at this point that the orchestration engine loads the saved instance of the orchestration into memory, restores the state, and runs its from the point it left off.

What is the default mapping for Auto Mapping?

The default mapping for Auto Mapping is is mapping by structure. This can be changed to by node name in the map properties.

What is MessageType in BizTalk Server?

What is BizTalk Server?

Biztalk is a messaging based integration tool. It consists of several tools like Business Processes (Orchestrations), Business Activity Monitoring (BAM), HAT (Health and Activity Tracking), Rules Engines, BizTalk Server Administrative Console etc.

BizTalk Server 2006 R2 builds upon the Business Process Management and SOA/ESB capabilities and address core challenges found in key vertical industries such as manufacturing and retail. Native capabilities of BTS R2 include support for Electronic Data Interchange (EDI) and AS2 ,Windows Workflow Foundation, WCF as well as RFID.

BizTalk server 2006 R2 application can be created using Visual Studio 2005 provided BizTalk Server SDK is installed into the system. A standard BizTalk Server application consists of Schema, Mapping, and Orchestrations. The heart of the BizTalk Server application is schema that is used to define the message format of source and destination data.

BizTalk Server has capability to talk with any kind of legacy system as it only understand the plain text data (in the form of xml), in order to talk with different systems it has several inbuilt adapter like SQL Adapter, MSMQ Adapter, SMTP Adapter, File Adapter, SOAP Adapter etc.

What is Debatching?

Integration projects mostly require splitting the large messages into chunk of small messages in the receive pipeline or in the orchestration. This process is so called De-batching. De-batching messages using biztalk can be achieved in many ways as follows:
(Available in many Geek blogs)

Envelope Message debatching: In general two schemas are configured in receive pipeline and called either from Adapter or Orchestration (BizTalk 2006 only).
Orchestration debatching: Orchestration is designed to loop through until end of messages and splits by calling custom .NET component or using the xpath function in the orchestration expression editor.
Custom Pipeline debatching: Disassemble() and GetNext() methods of Pipeline disassembler component will be overridden to debatch the input messages.

Introduction

A typical orchestration in BizTalk deals with several kinds of messages. A message in BizTalk is always strongly typed. It is usually associated to some schema defined in the project. A Receive/Send shape in an orchestration is tied to a message declared in the Orchestration View. In the case of an un-typed message, the message type is set to 'System.Xml.XmlDocument', instead of a schema type. The class "XmlDocument" is a super class for all XML messages, and hence it can hold any type of XML message and subsequently any type of orchestration message. To summarize, an un-typed message is one whose message type is set to "XmlDocument" in an orchestration.

Example - processing un-typed messages

Consider that we are integrating several small messages into a StoreFront application. This application deals with several kinds of messages like "Car", "Music" and "Book". These messages need to be integrated into a "StoreFront" message. So, a designed orchestration would receive several different types of messages. The orchestration in the article is shown below:

In the above orchestration, the "Send" and "Receive" shapes can handle any type of message. It is because the "Receive" shape is associated with a message which is of type "XmlDocument".
The Decision shape separates out the different kinds of messages.

// Message Type consists of TargetNamespace#SchemaRootElementName

InputMessage(BTS.MessageType) ==

       "http://UntypedMessages.Book#BookMessage"

Collapse

// Message Type consists of TargetNamespace#SchemaRootElementName

InputMessage(BTS.MessageType) ==

       "http://UntypedMessages.Car#CarMessage"

Collapse

// Message Type consists of TargetNamespace#SchemaRootElementName

InputMessage(BTS.MessageType) ==

       "http://UntypedMessages.Music#MusicMessage"

Notice the commonality in the above schemas. A quick explanation of one of the schemas is as follows:
The schema "Car.xsd" has the following properties:

RegID - The registration ID.
Make - The make of the car.
Model - The year of manufacture.
Operation - Can be either "BUY" or "SELL".
ExpectedPrice - The expected price.

The "InputMessage" message is specified in the Receive shape:

The "OutputMessage" message is specified in the Send shape:

The Message Assignment shape has the following lines of code:

Collapse

BookMsg = InputMessage;

regId = BookMsg.RegID;

category = "BOOK";

operation = BookMsg.Operation;

dataItem1 = BookMsg.Author;

dataItem2 = BookMsg.Pages;

expectedPrice = BookMsg.ExpectedPrice;

xmlDocument = new System.Xml.XmlDocument();

xmlDocument.LoadXml("<ns0:StoreFront " +

     "xmlns:ns0='http://UntypedMessages.StoreFront'><RegID>"+

 regId +"</RegID><Category>"+

 category +"</Category><ExpectedPrice>"+

 expectedPrice +"</ExpectedPrice><DataItem1>"+

 dataItem1 +"</DataItem1><DataItem2>"+

 dataItem2 +"</DataItem2><Operation>"+

 operation +"</Operation></ns0:StoreFront>");

OutputMessage = xmlDocument;

Line 1: The InputMessage is assigned to BookMsg, so as to retrieve its promoted properties.
Line 2-7: Retrieving the promoted properties of the BookMsg.
Line 8: Creating an instance of 'xmlDocument' and loading the XML for output.
Line 10: Assigning 'xmlDocument' variable to OutputMessage. This OutputMessage shall be sent through the "Send" port.

Strong name and deployment!!

Create a key file, using the "sn -k Untyped.snk", in the Visual Studio .NET command prompt.
In the Solution Explorer, right-click on the "UntypedMessages" project properties and select "Assembly" and specify the key file name.
In the Solution Explorer, right-click on the "UntypedMessages" project properties and select "Deploy".

Download and test the solution

Download the zip file and extract the source code provided into any directory of your choice. Look into the folder "InputFiles" for sample input XML files. Place the input file in the receive location. Check the response in the "Out" folder based on the input message.
In the BizTalk Explorer, right-click on the listed orchestration under the "Orchestration" folder and select "Bind...". Create a receive port and a receive location:

In the BizTalk Explorer, right-click on the listed orchestration under the "Orchestration" folder and select "Start". The orchestration icon must turn to blue.

Quick takeaways

Always set the Activate property to "true" for the first Receive shape in the orchestration.
The "Terminate" shape is required in the orchestration, without which the project will not compile, since that particular branch does not generate any outgoing message.
A BizTalk service needs to be re-started every time a deployment is done.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Ø http://www.nsoftware.com/products/biztalk/?gclid=CMv-_JjvuqkCFYZ66wodKD1m9A

Ø http://www.careerride.com/BizTalk-direct-binding.aspx

What are un-typed messages, how does one create them?

When a message created in BizTalk Orchestration is bound to a schema, this is a typed message. In un-typed messages, the message is bound to System.Xml.XmlDocument instead of a schema. Thus, an un-typed message is one whose message type is set to "XmlDocument" in an orchestration

Biztalk - Explain the difference between BizTalk Server and Web Services. - Jan 07, 2010 at 11:50 am by Vidya Sagar

What are un-typed messages, how does one create them?

A typed message is bounded to a schema which is created in BizTalk Orchestration.

An un-typed message is bound to xml document instead of a schema – System.Xml.XmlDocument.

What is direct binding?

Sending messages from one orchestration to another is done by using Direct Binding technique. It is also being used for sending messages directly into the message box. It is used in publish and subscribe system in BizTalk for sending messages among orchestrations.

Biztalk - What is BAM? What is the purpose of BAM? - August 27, 2008 at 17:10 pm by Amit Satpute

What is BAM? What is the purpose of BAM?

Microsoft documentation describes BAM as “Business Activity Monitoring (BAM) It is a collection of tools that allow us to manage aggregations, alerts, and profiles to monitor relevant business metrics.

It provides full visibility of your business processes with accurate information about the status and results of various transactions to enable you to determine the problem areas and resolve issues regarding the business.

Biztalk - What is BAM? What is the purpose of BAM? - Jan 07, 2010 at 11:50 am by Vidya Sagar

What is BAM? What is the purpose of BAM?

Business data and process milestones are captured by Business Activity Monitoring(BAM), which is a module in BizTalk . Business decisions makers are allowed by BAM for gaining insight for their in-flight process. For the purpose of deriving up-to-date metrics and key performance indicators from the BAM databases, Business Integration tools are used. The forecasting of process trends by uses and monitoring processes in real time scenarios is done by using BI tools. Users get alerts for situations which need their intervention for preventing undesirable outcome for encouraging beneficial results, a mechanism is provided by BAM.

http://msdn.microsoft.com/en-us/library/ee268124%28v=bts.10%29.aspx for publishing web services

Troubleshooting Published Web Services

This section has information about troubleshooting published Web services.

Important Prior to running the BizTalk Web Services Publishing Wizard, you must enable BizTalk Web services. For more information about enabling BizTalk Web services for your system, see Enabling Web Services.

This section contains:

Using the BizTalk Web Services Publishing Wizard to Publish an Orchestration as a Web Service

You use the BizTalk Web Services Publishing Wizard to publish an orchestration as a Web service.

Note You must build your BizTalk projects prior to running the BizTalk Web Services Publishing Wizard.

To publish an orchestration as a Web service

Click Start, point to All Programs, point to Microsoft BizTalk 2004, and then click BizTalk Web Services Publishing Wizard.
On the Welcome to the BizTalk Web Services Publishing Wizard page, click Next.
On the Create Web Service page, select Publish BizTalk orchestrations as web services, and then click Next.
On the BizTalk Assembly page, in the BizTalk assembly file (*.dll) text box, type the name of the BizTalk assembly file or click Browse to browse to the assembly containing the orchestration(s) to publish, and then click Next.

Note If you have an orchestration open in Visual Studio .NET, the BizTalk assembly file populates with the assembly containing the orchestration.

Note Paths over 260 characters may get an error message that the path is too long.

On the Orchestrations and Ports page, expand the tree nodes for each assembly and orchestration by clicking the plus sign. Select orchestrations and ports to publish by checking the corresponding tree node check boxes, and then click Next.
The following figure shows the BizTalk Web Services Publishing Wizard Orchestrations and Ports page with the tree nodes for the assembly expanded.

Figure showing the BizTalk Web Services Publishing Wizard Orchestrations and Ports page.

On the Web Service Properties page, in the Target namespace of the web service box, type a target namespace for the Web service, select the appropriate boxes to specify how the wizard should handle SOAP headers and SharePoint Portal Server 2003 Single Sign-On (SSO) support for the Web service, and then click Next.

Note The selection any of the SOAP header options are applied globally to all Web services and Web methods that are created when running this instance of the wizard.

Note Selecting the Add SharePoint Portal Server 2003 Single Sign-On Support option, allows Windows SharePoint Portal Server 2004 to pass its Single Sign-On (SSO) tickets to BizTalk Server inside a SOAP header. For more information about support SSO support in Windows SharePoint Portal and BizTalk Enterprise SSO support in BizTalk Server, see SOAP Adapter.

If you selected Add additional SOAP headers option, the Request SOAP Headers and Response SOAP Headers pages appear. You can add and remove request and response SOAP headers using the Add and Remove buttons in the following dialog boxes:

To add a SOAP header, click Add. In the BizTalk assembly file (*.dll) text box, type or browse for the assembly containing the SOAP header schema. The Available schema types list view displays each root element of the schema. Select a root node to add as a request or response SOAP header. To select multiple items, hold the CTRL key and click OK.
To remove a SOAP header from the list, select it from the list of added SOAP headers, and then click Remove.
Click Next on each SOAP Header page to continue the wizard.

Note A target namespace and root element name define a SOAP header.

Note If the same combination of target namespace/root element name is added as a request and response SOAP header, it will not be treated as and in/out header. You must manually copy the incoming header to the outgoing header inside of an orchestration.

Note The same combination of target namespace/root element name can only be added once as a request SOAP header and once as a response SOAP header.

On the Web Service Project page, in the Project name text box, type the name for the project. You can accept the default location (http://localhost/<project_name>), type a location for the project in the Project location text box, or click Browse and select a Web directory. Select any of the following options:

Overwrite existing project. This option is only available if the project location already exists. You will only be able to publish to the same location if you select this option. Otherwise, you must enter a different project location.
Allow anonymous access to web service. This option adds anonymous access to the created virtual directory. By default, the virtual directory inherits the access privileges from its parent virtual directory or the Web site (if it is a top-level virtual directory).
Create BizTalk receive locations. This option automatically creates the SOAP adapter receive ports and locations that correspond to each generated .asmx file. If a receive location already exists, it is not replaced. Receive locations for the SOAP adapter are resolved using the format /<virtual directory name>/<orchestration namespace_typename_portname>.asmx.

Note The project location can exist on a different server. To publish a Web service to a different server, type the project name as http://<servername>/<project_name>.

Note The project location can exist on a non-default Web site. When publishing to a non-default Web site, include the port number of the Web site in the URL. For example, http://localhost:8080/<project_name>.

Note When using the wizard to create receive locations, the wizard creates the receive locations using the default values. The default values for receive and send pipelines are the Microsoft.BizTalk.DefaultPipelines.PassThruReceive and Microsoft.BizTalk.DefaultPipelines.PassThruTransmit. If messages received through the published Web service require any special pipeline processing (for example, validation, correlation, or inbound/outbound maps) then you should set the send and receive pipelines to Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines.XMLSend, or to a custom pipeline.

Click Next to review your settings for the ASP.NET Web service project.
Click Create to create the ASP.NET Web service.
Click Finish to complete the BizTalk Web Services Publishing Wizard.

NOTE:Validating Message Correlation on Send Actions

You can validate the properties of a message that you send from your orchestration to ensure that it reflects the properties in its correlation set. By default, this validation is disabled. For information on how to enable it, see Runtime Validation for the Orchestration Engine.

Why We Are Add Reference?

We are creating individual projects in real time. If u access the schemas in Orchestration project we should be adding that references in the Orchestration Project. Without reference of Schemas how to use the schemas in process of creating messages.(schemas assign in message type of message in Orchestration properties window)

Add Reference

Schemas: No(start of project with Schemas.so, no need bother to Reference)

Orchestration: Yes(Reference of Schemas, if it will have Maps)

Note:we use mapping inside transform of the Orchestration. So, we add reference of map into Orchestation project.

Map: Yes(add Reference of Schemas.no need to Orchestration reference to

Inside of Map project)

Class Assembly: No.(But we add class assembly reference to other projects like

schemas,Orchestr,map,pipelines etc.)

Note:whenever u add reference of 1 appl. Compulsary rebuild the individual project & Total Solution.Otherwise that changes are not reflected.

for more details read http://geekswithblogs.net/LeonidGaneline/archive/2008/07/10/biztalk-interview-skill-measurment.aspx

QUERIES

1) In 2006R2: adding new adapter pack2.0

2) Read about wcf-sql adapter: below

http://geekswithblogs.net/martinabbott/archive/2009/06/03/biztalk-server-2009-and-wcf-sql-adapter.aspx

3) Do u know what SDK is?

A software development kit (SDK or "devkit") is typically a set of development tools that allows for the creation of applications for a certain software package,

Software framework, hardware platform, computer system, video game console, operating system, or similar platform.

SDKs may have attached licenses that make them unsuitable for building software intended to be developed under an incompatible license.

For example, a proprietary SDK will probably be incompatible with free software development, while a GPL-licensed SDK could be incompatible with proprietary software development.

LGPL SDKs are typically safe for proprietary development.

How to create a functiods in BizTalk server?

Creating own functiods;http://www.codeproject.com/KB/biztalk/CustomFunctoid.aspx

Q) How many interfaces u used in our previous project?

Correlation Type Property	Possible XML Representation
Social Security number	<SSN></SSN>
Date of Birth	<DOB></DOB>
Gender	<Gender></Gender>

Correlation Set Property/Value	Possible XML representation
Social Security number = 222112222	<SSN>222112222</SSN>
Date of Birth = “1/1/1995”	<DOB>”1/1/1995”</DOB>
Gender = Male	<Gender>M</Gender>

for BizTalk people

Friday, 9 September 2011

Basic concepts of BizTalk

Flat File Schemas

What is the difference between a "Message Assignment" shape and an "Expression" shape?

What is the difference between Distinguished field and Promoted Property?

What is Correlation in context of BizTalk Server?

What is the difference between a Document Schema and a Property Schema?

What is the default mapping for Auto Mapping?

What is MessageType in BizTalk Server?

What is BizTalk Server?

What is Debatching?

Introduction

Example - processing un-typed messages

Strong name and deployment!!

Download and test the solution

Quick takeaways

License

What are un-typed messages, how does one create them?

What are un-typed messages, how does one create them?

What is direct binding?

Biztalk - What is BAM? What is the purpose of BAM? - August 27, 2008 at 17:10 pm by Amit Satpute

What is BAM? What is the purpose of BAM?

What is BAM? What is the purpose of BAM?

Using the BizTalk Web Services Publishing Wizard to Publish an Orchestration as a Web Service

See Also

NOTE:Validating Message Correlation on Send Actions