Messaging

How can you programmatic submit messages to BizTalk?
In previous versions of BizTalk you could easily submit messages to BizTalk using the IInterchange.Submit. In BizTalk Server 2004 there is no trivial way to submit messages.
However, you may use the Transport Proxy interfaces to submit messages. There is an SDK sample showing how to programmatically submit documents into the product if you don't want to write a full blown adapter: \Program Files\Microsoft BizTalk Server 2004\SDK\Samples\Adapters\SubmitDirect
Why can I specify multiple maps in a receive port?
To be able to specify multiple maps in a receive port allow you to create a receive port that accept several different types of incoming messages. The advantage with using this approach is that you reduce the number of receive ports that will have to be created and maintained, which reduce administrative effort.
The source schema needs to be different for each map, there will only be one map that matches per message, i.e. one message published regardless of the number of maps configured.
I do not wish to use Orchestrations, only port, schemas and maps. How do I do this?
This is a perfectly valid choice that exclusively uses the part of BizTalk called BizTalk Messaging. I do not think that it is not obvious how you go about implementing such a scenario, so here are some steps that you can follow (the last bullet is the step that is hard to figure out):
· Create your schemas and maps in VS, using a BizTalk Server Project.
· Create a Receive Port using the BizTalk Explorer in VS.
· Apply any maps you wish to perform on inbound documents using the Inbound Maps node in the Receive Port configuration.
· Create a Receive Location that pick up your information.
· Create a Send Port, specifying all necessary information.
· Navigate to Filters & Maps / Filters in the Send Port configuration. Enter the following expression: BTS.ReceivePortName == NameOfYourReceivePort
Does the pipeline executes again when a Send Port retries?
Yes, the pipeline is executed with each retry of a Send Port.
The reason for this is that when a Send Port fails it is the original messages that is put back in the MessageBox. When the retry occur the message is once again sent to the Send Port, which applies maps and executes the pipeline.
What is the difference between distinguished and promoted fields?
There are two different ways in which you can programmatically access an attribute or element in BizTalk, they are called Distinguished Field and Promoted Property. 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.
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).
How do I delete a message in the pipeline?
Say that you want to write a custom pipeline component that writes some data into a database and don't want to include further BizTalk processing. Once the database write is successful you do not need the message anymore. You do not want the engine to write any data into the message box, basically one message gets into the pipe and none goes out.
What you need to do to support this scenario is to return null from the IComponent.Execute, IDisassemblerComponent.GetNext or IAssemblerComponent.Assemble methods
Easy way to get XPath to element
If you need an XPath for a specific element in a document and you're not fluent in XPath (which I'm not) an easy solution can be to open the schema in BizTalk Schema Editor in Visual Studio. When you select a node in the schema you may look in the Instance XPath property (in the Property Window) to find an XPath statement for accessing that element.

Can a flat file message be processing without a pipeline?
A Pipeline's job is to convert any external format into XML, be it a flat file or EDI or anything else.

Can multiple messages be processed or batched without an envelope schema?
It is possible to process multiple messages, without an envelope.

What is property promotion, why is it required?
When a property is Promoted, it is exposed to the orchestration/send port filters etc.

In which scenarios would use a "promoted property" vs "distinguished fields"?
The rule here is, if you dont want the schema element to appear in send port filters/debugging information then make it a distinguished field.

In Biztalk, what does a message type consist of?
A message type consists of the TargetNamespace#RootElement name.

What are un-typed messages, how does one create them?
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.

What is the difference between static, dynamic and direct binding?
Refer to Binding models in BizTalk

How does one enable subscriptions in BizTalk?
A filter on the Send Port is the first step to enable subscriptions in BizTalk.