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.
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
# 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.
<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.
A Expression shape is used to assign values to variables and also write 'if' conditions.
#. 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)
#. 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)
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
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
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.
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.
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.
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.
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?
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.
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.
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()
andGetNext()
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)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:
- Changes to Orchestrations, Receive Ports, and Receive Locations Do Not Appear
- Internal SOAP Processing Failure
- Unable to Overwrite Existing Web Service Project with BizTalk Web Services Publishing Wizard
- Problems Using BizTalk Web Services Publishing Wizard within a Windows 2000 Server Terminal Server Session
- Unable to Create BizTalk Receive Locations
- BizTalk Web Services Publishing Wizard Menu is Missing
- Deserialization Problems Caused by Duplicate Node Names
- BizTalk Web Services Publishing Wizard Fails When Schema Contains maxOccurs > 1 and Default Value
- Interoperability Problems with SOAP Toolkit
- Schema Details Lost in Web Service Description
- Publishing Internal Port Types Not Supported
- Republishing an Orchestration in the Same Virtual Directory
- Mapping Errors Encountered When Using Windows SharePoint Services and BizTalk Web Services Publishing Wizard
- Publishing Error on Windows Server 2003
- Errors When Trying to Publish a Web Service
- BizTalk Web Services Publishing Wizard Fails When Encountering an Undeployed Assembly
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.
- 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.
See Also
To download
updated BizTalk Server 2004 Help from www.microsoft.com, go to http://go.microsoft.com/fwlink/?linkid=20616.
Why ur selecting quick promotion and u r not selecting show
promotions
What are
correlation sets?
Correlation Sets
You can achieve this sort of
correlation of messages with orchestration instances by defining correlation
sets. A correlation set is a set of properties with specific values.
This is different from a correlation type, which is simply a list of
properties. If an incoming message does not have all of these properties, with
matching values for each, correlation will fail and the message will not be
received by the orchestration instance.
Correlation types define a set of
properties on which you will be correlating messages. These can be any
properties which were previously defined in a property schema and deployed with
some BizTalk Project including "system" properties deployed with the
GlobalPropertySchemas which is installed as part of the base BizTalk install. A
correlation set defines a set of properties and values for these properties
that a message must contain to be processed by a particular orchestration.
For example, a correlation type
could consist of the following properties:
Correlation
Type Property
|
Possible
XML Representation
|
Social Security number
|
<SSN></SSN>
|
Date of Birth
|
<DOB></DOB>
|
Gender
|
<Gender></Gender>
|
While a correlation set derived from
this correlation type could consist of the following properties and values:
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>
|
What is correlation type?
Each correlation set is based on a correlation type, which is simply a list of properties. These properties might be data properties, which are found in the message itself, or context properties, which describe details of the system or messages that are unrelated to the data being conveyed in the message.
Each correlation set is based on a correlation type, which is simply a list of properties. These properties might be data properties, which are found in the message itself, or context properties, which describe details of the system or messages that are unrelated to the data being conveyed in the message.
You can use a correlation type in
more than one correlation set. If you need to correlate on different values for
the properties in a correlation type, you must create a new correlation
set—each correlation set can be initialized only once.
You can promote properties in a
property schema to declare that certain properties in a message are accessible
to your orchestration. For more information, see Promoting
Properties.
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?