1. What is a Message Type (i.e. BTS.MessageType) and how is it used in BizTalk?
• Message Type is a BizTalk System property that is promoted inside a Pipeline. It is made up of Document Name Space # Root Node Name.
2. How do you call a Non-Serializable .Net helper class inside an Expression Shape?
• Add a reference to that class.
• Make sure your Orchestration is Long Running transactional.
• Add an Atomic scope.
• Create an Orchestration variable of that class inside the scope.
• Create an instance on that object inside the scope.
• Call the method.
• Bonus: Mention the class must be strongly signed and in the GAC.
3. What is the difference between a Distinguished field and a Promoted Property?
• Distinguished fields are light weight and can only be used inside an Orchestration.
• Promoted Properties are defined inside a property schema, are tracking in SQL, can be tracked in HAT, and can be used for content based routing.
4. How do you achieve First-In-First-Out message processing of messages received from multiple sources using an Orchestration?
• Use a Sequential Convoy to process the messages in the order they are received into the Message Box.
• Make sure Ordered Delivery is set to True inside the Orchestration Receive Port.
5. When working with Schemas, Maps, Pipelines, and Orchestrations how should the projects be structured?
• Schemas and Maps in its own project
• Or Schemas and Maps together in its own project
• Orchestrations in its own project
• Pipelines in it own project
6. What is direct binding?
• Direct binding has three types: direct to message box, self correlating, and partner ports.
• Used to route message between the message box and Orchestrations without using bindings or from one Orchestration to another Orchestration.
7. What is BAM used for?
• BAM is used to monitor business milestones and key metrics in near real-time throughout a process in BizTalk.
8. What is the Rules Engine?
• Rules are used to provide highly efficient, easily changeable business rules evaluation to Business Processes. This allows rules to be changed without rebuilding and redeploying .net assemblies. The Business Rules Engine (BRE) can also be called from any .net component through the API’s.
9. What are Persistence Points and what causes them?
• Persistence is when the state of a running Orchestration is stored into SQL.
• It is good enough to know various shape and actions cause persistence. More specifically, it occurs: end of a transactional scope, at a send shape, at a start Orchestration shape, during dehydration, if the system shuts down expectedly or unexpectedly, or the business process suspends or ends.
10. What group does a user need to belong to in order to submit messages to the message box?
• The user needs to be a member of the hot group or isolated host group (assuming a default installation).
11. What user rights to you need to perform most actions in HAT?
• BizTalk Server Administrator
12. When installing Biztalk in a multi-server configuration with a remote SQL and Analysis Services, what SQL components do you need on the Biztalk Server?
• SQL Analysis Services Client Tools
13. When installing Biztalk and SQL on a Windows XP SP2 Desktop, what pre-requests are required?
• Correct answer: A Lot. The best answer something like I have a custom written installation document I use or I always referrer to the most current updated installation guide from Microsoft.
14. Can an Envelope schema consist of more than one schema type?
Yes. Technically it is possible.
Different Types of BizTalk Schemas
BizTalk Server 2004 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.
15. What is the difference between a Document Schema and a Property Schema?
Answer: 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.
16. Does BizTalk 2004/2006 support Synchronous communication?
BizTalk is essentially Asynchronous. It can exhibit some synchronous behavior, if an Orchestration is converted into a web service.
What are Persistence Points? Persistence points in Biztalk is the key issue in dealing with Orchestration Performance. The SQL Server does bulk of the job at the backend to keep the BizTalk server running. BizTalk has this inherent behavior of saving the orchestration state to the SQL Server so as to quickly and easily recover from any failures. Persistence points are those points in the orchestration that save the orchestration state to the database. Persistence Points induces latency in Biztalk Orchestrations, though you cannot avoid them, but understanding them would help in using them efficiently
What causes Persistence?
In normal cases Persistence in Orchestration occurs at the following points:
1. End of a transactional scope (atomic or long running)
2. At the Send shape (except in an atomic transaction)
3. At the end of the orchestration
4. At the of other orchestrations through the Start Orchestration shape
Other than that, Persistence at the Biztalk Engine level occurs in following scenarios:
1. When an Orchestration Instance is suspended
2. When the engine determines it wants to dehydrate
3. When an orchestration instance is finished
4. When the system shutdowns in a controlled manner
And also Persistence can also occur at debugging breakpoints when the orchestration debugger is being run.
20. What group does a user need to belong to in order to submit messages to the message box?
• The user needs to be a member of the host group or isolated host group (assuming a default installation).
Bindings
Introduction
First, a little background. BizTalk orchestration ports have two major properties. The Communication Pattern property configures ports as either one-way or request-response ports. In addition, ports have a Communication Direction property. In XLANG/s the communication direction, or polarity, of a port is represented by the keywords 'implements' and 'uses'. The idea is that orchestrations implement ports to receive messages from the Message Box, and use ports provided, conceptually, by the orchestration infrastructure, to send messages to the Message Box. For 'implements' ports, you configure the Communication Direction property to 'Receive' (One-Way) or 'Receive-Send' (Request-Response), whilst 'uses' ports are configured as 'Send' (One-Way) or 'Send-Receive' (Request-Response).
Orchestration ports manage the delivery of messages to and from the BizTalk Message Box. Request-Response ports, of course, manage message delivery in both directions, but it is natural to think primarily in terms of the direction of the initial message. Ports obtain messages from the Message Box through subscription. Subscription is primarily a matter of matching rules, composed of predicates, to a set of 'facts' associated with messages. These 'facts' are expressed in terms of a sub-set of the message context properties. Each message has a collection of metadata property values which represent the context of that message. Subscription only matches rules against those context properties which are marked with a 'promoted' flag. Orchestration ports manage the creation of subscriptions for messages to be received and 'promoted' context properties for message which are sent.
Binding
In BizTalk, the term 'binding' refers to the configuration of orchestration ports in order to control the creation of subscriptions and/or 'promoted' properties. Binding is used to control how messages will be routed to or from orchestration ports by the subscription mechanism. Hence, binding often involves additional creation and configuration of messaging Send and Receive ports so that these messaging ports can be bound to orchestration ports. Orchestration ports can also be bound to other orchestration ports.
Messaging Receive ports are bound to orchestration ports by generating subscriptions that select messages based on the value of a message context property called BTS.ReceivePortID. Using features such as filters, correlation sets and role links, it is possible to extend the subscription rules with additional predicates.
BizTalk supports two types of binding on messaging Send ports. Send ports can either be static or dynamic. A static port is configured at deployment to use a ‘transport’ to deliver messages to a specific external end point. Transports are defined by a ‘transport type’, which selects an adapter, and a URI address specifying the location of the external end point. When an orchestration port is bound to a static Send port, the orchestration port is responsible for ensuring that each message is provided with a context property called BTS.SPID which indicates bound Send port. The Send port subscribes to messages whose BTS.SPID is set to a specific Guid value.
In contrast to static Send ports, dynamic ports select transport types and locations dynamically by inspecting various context properties contained on each message delivered to the port by the subscription mechanism. In this way the one Send port can dynamically route messages to different locations via different adapters. When an orchestration port is bound to a dynamic Send port, the orchestration port is responsible for ensuring that the required properties are created within the message context. As well as the BTS.SPID property, these include the BTS.OutboundTransportType, BTS.OutboundTransportLocation and BTS.OutboundTransportCLSID properties.
'Promoted' properties
Subscription works only with message context properties that are marked as 'promoted'. The term 'promotion' can be rather confusing because BizTalk has more than one promotion mechanism. BizTalk developers are used to thinking in terms of promoting field values contained within a message into the message context as property values. However, we are specifically talking here about a second, related, mechanism where a subset of context properties, marked internally as 'promoted' are automatically copied into a database table when a message is delivered to the Message Box. Once 'asserted' in this fashion, BizTalk subscription can then do its matching work. These two mechanisms are typically conflated. When a 'property field' is promoted using a schema (or an attribute, if you are using a .NET class as the type definition for message content), the resulting context property will also be marked as 'promoted' automatically by Microsoft-supplied disassembler components and also by BizTalk maps. This conflation is very useful, but is also a source of some confusion, because BizTalk developers often don't understand that there are really two levels of promotion behind the scenes. Using your own code, you can exploit the two mechanisms quite separately in pipeline components, and also, in a rather indirect fashion, within your orchestration code through a combination of 'direct binding' and the use of so-called 'correlation sets'. I say 'so-called', because correlation sets really offer a more fundamental facility that can, and often is, used for correlation, but which can be used for other purposes as well.
Binding Configuration
BizTalk supports a facility which allows binding configuration to be changed and amended after initial deployment, without the need to re-compile and re-deploy BizTalk assemblies. Binding configuration can be applied programmatically using the ExplorerOM class library or, with some limitations, the BizTalk WMI classes. The WMI MSBTS_DeploymentService class provides an Import function which allows XML configuration files, called 'binding' files to be applied to deployed BizTalk assemblies. Binding files provide a simple way in which bindings for orchestrations within a given assembly can be changed. In addition, binding files can be used to create and configure messaging Receive and Send ports and other BizTalk entities.
Binding Models
BizTalk offers four binding models, each with different characteristics. Each model is really a set of higher level abstractions of the basic BizTalk subscription mechanisms. One of these models is called 'Direct Binding'. The term 'direct binding' is used to suggest that the techniques involved are all about binding one orchestration port directly to another. In fact, this is just one possibility when using this model. I find the term confusing, myself, as other binding models are used to 'directly' bind orchestration ports to messaging Send ports. Binding models are really differentiated by the following characteristics:
• support for external binding configuration
• use of static and dynamic messaging Send ports. NB., Receive ports do not support a dynamic model.
• auto-generation of configured messaging ports at deployment time
The four models are:
• 'Direct' binding
In this model, orchestration ports do not automatically use or exploit BTS.SPID, BTS.ReceivePortID or other related properties. BizTalk therefore does not manage the binding of orchestration ports to messaging Receive and Send ports. Instead, it is entirely up to developers to control subscriptions and message context in order to route messages. Developers are free, if they wish, to route messages to other orchestration ports. External binding configuration cannot be used with directly bound orchestration ports. Direct binding is the most flexible model, but at a cost. You cannot configure your orchestration ports using binding files, and you generally need to do more programming in order to fully exploit the flexibility on offer.
• 'Specify later' binding
In this model, orchestration ports are bound to messaging ports using BTS.SPID, BTS.ReceivePortID or other related properties. Outgoing messages are always routed through static Send ports. Binding configuration can be managed in deployed solutions using binding files or by writing WMI/ExplorerOM code. This is probably the most common model, but is significantly less flexible than direct binding. You have much less control over subscription and 'promoted' properties, and can only use this approach to bind orchestration ports to messaging ports.
• 'Specify now' binding
This model is similar to the 'Specify later' model. However, BizTalk collects transport information at design time, together with pipeline information, and uses this to auto-generate messaging Receive and static Send ports at deployment time. Orchestration ports are then bound to these ports. Binding files can be used, if required, to amend binding configuration on a live system.
• 'Dynamic' binding
This model has similarities to the 'Specify now' model in that BizTalk collects pipeline information at design time and auto-generates messaging Send ports. Receive ports are not generated, as there is no concept of a 'dynamic' Receive port. However, transport information is not configured in the same way. Instead, developers create expressions in orchestrations to assign transport location URIs using the 'address' property of orchestration ports. The auto-generated messaging Send ports are dynamic, rather than static. Messages passing from an orchestration through dynamic Send and Send-Receive ports are routed solely on the basis of the orchestration port's address property which is used to create BTS.OutboundTransportType and BTS.OutboundTransportLocation 'promoted' context properties. When a dynamic messaging Send port is enlisted, it creates a set of subscriptions, with one subscription for each adapter. Each subscription tests that the BTS.OutboundTransportLocation property exists, and that the BTS.OutboundTransportType property contains a value identifying the adapter. Hence, not only can dynamic binding route messages to any location based on the address, but also via any registered adapter.
We can summarise the differences between the different binding models as follows:
Messaging Send Ports External Binding Configuration Auto-Generated Messaging Ports
Static Dynamic
Direct Yes Yes
Specify Later Yes Yes
Specify Now Yes Yes Yes
Dynamic Yes Yes Yes
Let’s now turn our attention more specifically to direct binding, which is the least well understood of the binding models.
Binding Ports Directly
When you select direct binding, you also configure the Partner Orchestration Port property. The very name of this property suggests, as discussed above, that direct binding is all about binding between orchestration ports. However, this really does not do justice to the flexibility available when you select this model. It is perfectly possible to use this model to bind messages to messaging Send ports. The Partner Orchestration Port property always offers at least two options:
• Message Box
This setting provides the greatest flexibility of all. It allows developers full freedom to manage message routing as they please. Orchestration ports do not automatically create 'promoted' properties on outgoing messages in order to route those messages to a messaging Send port, and no longer create subscription predicates for received messages based on messaging Receive port identifiers. It should be noted, however, that orchestration ports will still subscribe to specific message types and create a 'promoted' MessageType property on sent messages. You can, however, suppress this behaviour easily by using System.Xml.XmlDocument or Microsoft.XLANG.BaseTypes.Any as your message type for incoming or outgoing messages.
• Self Correlated
This option is similar to the Message Box option, but additionally configures an orchestration port to create a CorrelationToken property on outgoing messages, and to subscribe to this property in order to receive the response.
This option is used in two distinct scenarios. In the first, it is used in conjunction with a Send-Receive orchestration port to send a message to the Message Box. The CorrelationToken property is not marked as promoted on the outgoing message. If it was, the message would be immediately returned from the Message Box to the port as the response message, without any further processing. You need to subscribe to the sent message and then, at some future time, return a message to the Message Box with the same CorrelationToken property value, ensuring this time that the CorrelationToken property is marked as 'promoted'. There are several ways to do this, but we will specifically discuss a general technique later in this article which you might exploit in a second orchestration to generate and return a message with a 'promoted' CorrelationToken property.
The second scenario is specific to the Start Orchestration shape. Unlike the Call Orchestration shape, the Start Orchestration shape uses the Message Box to 'invoke' another orchestration. A special RPC-type message is generated by the shape and subscribed to by the second orchestration using a special 'GetObject' subscription. Parameters are passed to the second orchestration using message parts.
You can create a self-correlated port in an orchestration and then send it as a parameter to a second orchestration using the Start shape. The important thing to understand here is that although the one port appears to be shared across the two orchestrations, the second orchestration will in fact be using a distinct port of the same type. This is in sharp contrast to the behaviour of the Call Orchestration shape. If you pass a port as a parameter to a Call Orchestration shape, you are passing a reference to the one port. In this case the one port is truly shared. You can think of this difference as similar to passing by value (Start Orchestration) and passing by reference (Call orchestration).
Self-correlated ports are typically used with Start Orchestration shapes to implement call-back patterns. An orchestration starts a second orchestration, passing to it a self-correlated port. The port is configured as a Receive port in the first orchestration, and as a Send port in the second orchestration. As we have stated, these are really two distinct ports. The second orchestration can then send messages back to the Message Box via its port. These messages are subscribed to by the original port in the first orchestration.
You cannot use this approach with the Call orchestration shape. Because ports are passed 'by reference', the polarity of the port must be same in both orchestrations. The BizTalk compiler will not allow you to pass an 'implements' port to a 'uses' port parameter, or vice versa. Hence the communication direction of the port you pass in from one orchestration must be the same as the direction of the port reference in the called orchestration. Logically, this prevents any hope of using orchestration port parameters to do 'call-backs'. The very nature of a call-back means that the communication direction of the port would have to be different in the master and child orchestrations. You might hope that you could create a Send-Receive port in the master orchestration and use the Send part in the child to receive a call-back in the master. This does not work. You won't be able to compile your code unless you do both the send and the receive in the same orchestration. At an even more fundamental level, orchestration ports always transfer messages to or from the Message Box. They are not endpoints in themselves, and you cannot, somehow, use a single port to directly transfer messages directly to itself!
There is some confusion about the purpose of orchestration port parameters, especially when used with Call Orchestration shapes. When calling child orchestrations, the purpose of port parameters is to simplify and rationalise the application of external binding configuration. When your orchestration design expresses the idea of master and child orchestrations using the Call Orchestration shape, you generally want to think of the message flow through these multiple orchestrations as a single activity. You can create all the required orchestration ports on the master orchestration, and then hand them off to child orchestrations as required. This means that when you manage binding configuration using binding files or programmatically via ExplorerOM or WMI, your bindings can all applied at the master orchestration level alone.
• Partner Ports
In addition to the two settings above, BizTalk supports binding using partner orchestration ports. A partner port is a single port used to bind two orchestrations ports of the same type. Every orchestration port has a specific type, and you can create multiple ports of the same type across different orchestrations. The Partner Orchestration Port property will list all available ports of the same type as the port you are configuring. This includes ports of the same type in your current projects, and any other ports of the same type on public orchestrations in referenced BizTalk assemblies.
Partner ports are used to bind one-way send ports to receive ports or send-receive ports to receive-send ports. The two ports must be of the same type. In almost all cases, they will be in different orchestrations, and the receiving port will be connected to an 'Activate' receive shape. To configure the use of partner ports, configure all participating send and receive ports to use direct binding, and then set the Partner Orchestration Port property of each participating port to reference the same partner port. Once configured, Send ports will create three 'promoted' properties on each outgoing message. These are the BTS.Operation, BTS.PartnerPort and BTS.PartnerService properties. The values assigned to these properties represent the selected partner port. Each Receive port will subscribe to messages that provide these three properties with the same values.
Partner ports provide an easy-to-configure mechanism for connecting ports in situations where the sent message will always result in instantiation of a new instance of an orchestration. It is very common to use one of the ports involved in message exchange as the partner port. However, ‘third-party’ partner ports can also be used. This approach provides a powerful mechanism for implementing design patterns that require one-to-one, one-to-many, many-to-one or even many-to-many message-exchange relationships between multiple orchestration instances.
Controlling Direct Binding
When using direct binding with the ‘Message Box’ option, you can take full control of which message context properties are marked as 'promoted' by orchestration send ports. You must ensure that you have a property definition for each property. BizTalk supplies a large number of pre-defined property definitions, and you can add new property definitions by creating property schemas. If your custom properties are not linked to any message content, remember to select the MessageContextPropertyBase setting for the Property Schema Base property of your definition. In your orchestration code, add message assignment expressions to create and initialise the message context properties using the special XLANG/s syntax for this purpose:
myMessage(MyPropertSchema.MyCustomProperty) = "Purchase Order";
Now create a correlation type that includes the properties you want to mark as 'promoted'. Correlation types specify a list of defined property definitions. Create a correlation set over the correlation type and assign it to the 'Initialising correlation set' property of the send port that will send the message on which you have created the required properties.
When a message arrives at the orchestration send port, the correlation set will be initialised using the property values you assigned to the message context. The correlation set will then be used by the send port to decide which properties should be marked as 'promoted'. Without the correlation set, the properties would not be marked as 'promoted' and so could not be used to route the message via subscription.
Although the above approach uses correlation sets, but is not really an example of correlation! Instead, we are simply using the correlation type as the nearest equivalent in orchestrations to the concept of promoting 'property fields' in schemas. This mechanism allows you to fully control the routing of message sent from orchestrations.
To control subscription predicates created by receive ports, use filters and correlation sets. Filters can only be used on ports linked to 'Activate' Receive shapes. The use of correlation sets (or self-correlation) to control subscription for non-activation Receive shapes can seem very restrictive. However, it is logical. BizTalk routes messages to specific instances of an orchestration. That instance is either created to handle a message using an activation subscription, or the message is routed to an already running instance of an orchestration. BizTalk insists that instance-specific subscriptions are created for every non-activation Receive shape. The Receive shape must ‘follow’ an already initialised correlation set created either in the same orchestration or in a master orchestration which called or started the current orchestration instance.
I'll finish be dispelling a couple of misconceptions which I recently come across, and which prompted this article.
• "Direct Binding bypasses the Message Box".
This is simply not true. In fact, almost by definition, an orchestration port is a port to/from the Message Box. The only mechanism I know of in BizTalk where messages bypass the Message Box is where the Call Orchestration shape is used to directly invoke a sub-orchestration, and messages are passed via parameters. Even the apparently similar Start Orchestration shape uses the Message Box.
• "Direct Binding is only ever used to exchange messages between orchestration ports."
Not true at all. As we have seen, direct binding allows you to take fuller control over your subscriptions and 'promoted' context properties, and therefore over routing within BizTalk. Whilst it is true that you will most typically use this model to bind one orchestration port to another, and while the ‘partner ports’ functionality only supports orchestration ports, you can nevertheless also use direct binding to bind to messaging Send ports.
17. What are un-typed messages, how does one create them?
an un-typed message is one whose message type is set to "XmlDocument" in an orchestration.
18. Distinguished Fields vs. Promoted Properties
BizTalk provides two types of property promotions: Distinguished Fields and Property Fields.
In a simplified manner, distinguished fields can only be used within orchestration whereas promoted property fields can be accessed through all phases of the BizTalk message processing, either in orchestrations or from custom code, routing and pipelines
Distinguished Fields Promoted Properties
(Property Fields)
Are only accessed within orchestration, and they are not available to other BizTalk Server objects, such as receive locations, send ports, send port groups, and tracking utilities. Accessed through all phases of the BizTalk message processing, either in orchestrations or custom code, routing (receive and send ports) and pipelines.
Do not participate in routing
IsPromoted = false Used for routing (subscription mechanism)
IsPromoted = true
Not used for tracking Used for tracking
They are not persisted to the MessageBox database.
Instead, they are essentially XPath aliases, which simply point to the appropriate XML data field. Are persisted to the Message box database.
Do not have a size limitation maximum 256-character length limitation
Accessed through a reference to the name of the message, the name of the record structure containing the distinguished field, and the name of the distinguished field, with each named item separated by periods:
MessageName.RecordName.ChildRecordName. Accessed through a reference to the name of the message, the name of the property schema, and a name of the promoted property, via the following format:
MessageName(PropertySchemaName.PromotedPropertyName)
Do not require the creation of a corresponding property schema Require the creation of a corresponding property schema
Cannot be used to promote values in a record Can only be used on records with Simple Content type
Both can be used to promote elements and attributes
Cost less Have the additional overhead of being written in both to the Message Box context tables and the subscription tables
Notes:
• In short, use distinguished fields unless you have to access the field when routing the message. And use it frugally to incur less performance penalties.
• Certain scenarios will call for sensitive information, such as a bank account number, to be used as a promoted property. To allow for enhanced troubleshooting and detailed reporting, promoted properties can be viewed in tools such as Health and Activity Tracking (HAT) and Business Activity Monitor (BAM). Based on privacy regulations, these data fields may need to be hidden from these tools, which can be accomplished by setting the promoted property’s Sensitive Information property to True (this configuration is applied on the property schema).
What are Promoted Properties and How to promote properties??
Promoted Properties are Message Context Properties that are flagged as promoted.
Being promoted it allows the Message Engine to route messages based on their value, and being in the message context allows doing so without having to look at the message payload (which would be an expensive operation).
They are the most common way to enable content-based routing.
There are 2 ways to promote a message element:
• Quick promotion: Quick promotion is the simplest way to create a promoted property. Simply right click on the element’s node and choose Quick Promotion. When choosing this option, Visual Studio will create a property schema called PropertySchema.xsd and add in the message’s schema a reference to the generated property schema.
• Manual Promotion: To manually promote a property, a property schema must be created with the elements that will hold the promoted property values. To create a property schema, you need to add a new item in your BizTalk solution, and chose Property Schema as the type of file. Once all the elements are created in the property schema, you associate the property schema with the message’s schema
What are distinguished fields and how to create a distinguished field??
Distinguished fields are message elements that are written into the message context.
The main source of confusion between distinguished fields and promoted properties is that they are both created in Visual Studio’s Schema Editor through the Promote -> Show Promotions contextual menu option of a message schema’s element.
Once the dialog box is open, make sure that you are on the Distinguished Field tab, select the message elements and click the Add>> and <
How do you call a Non-Serializable .Net helper class inside an Expression Shape?
1. Add a reference of that dll (class). The class must be strongly signed and in the GAC.
Make sure your transaction type of Orchestration is Long Running transactional.
Add an Atomic scope.
Create an Orchestration variable of that class inside the scope.
Create an instance on that object inside the scope.
Call the method
2. What is BizTalk?
A middle ware that sits in the middle of any two software who wish to communicate with each other and agree on some specified communication pattern. It uses SQL Server as back end database.
3. How do you use Auto Mapping in the BizTalk 2004 mapper?
1. Does orchestration support parallel activation?
m
2. Can you connect BizTalk with Sql 2000?
Yes but it should fulfil the minimum criteria of SP4.
6. What is correlation?
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
7. What if the class is Serializable?
8. What is 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.
9. 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.
1. 10. What does the Value Mapping Functoid do?
1. 11. What is the default mapping for Auto Mapping?
2. 12. What is a Message Type (i.e. BTS.MessageType) and how is it used in BizTalk?
It is a combination of root node and namespace.
1. 13. Can an Envelope schema consist of more than one schema type?
1. Yes. Technically it is possible.
2. 14. What is the difference between a Document Schema and a Property Schema?
Property schema consist of elements which are promoted
1. 15. Enumerate the new functoids added BizTalk 2006?
2. What is property Promotion and why is it required?
Biztalk provides you with a really smart routing feature that allows the engine to decide where to send which message. For example, If you receive a message with the EmployeePaySlip schema, and it has the approved flag to true, it should be redirected to the Finance system Orchestration for making the payments and to the HR system Orchestration for keeping the records. This built in intelligence for the Biztalk engine allows it to route the messages simply based on some content within the messages.
In order to achieve this, the Biztalk engine obviously needs to understand the fields based on which the routing decisions can be taken. To simplify and optimize this working, Biztalk has introduced the notion of “promoted properties”. The Biztalk engine can get easy access to the promoted properties without knowing the entire message and hence it can save loads of time and complexity when dealing with routing. To route a message, the Biztalk engine simply reads its promoted properties and does not care about other contents in the message.
1. 17. Does BizTalk 2004/2006 support Synchronous communication?
2. 18. What is atomic Transaction?
It follows full ACID properties Atomicity, Consistency, Isolation and Durability.
If you require full ACID properties on the data—for example, when the data must be isolated from other transactions—you must use atomic transactions exclusively.
When an atomic transaction fails, all states are reset as if the orchestration instance never entered the scope.
1. 19. How does one enable subscriptions in BizTalk?
2. 20. What is long running transaction?
Long running transaction support CD properties of ACID. It is not practical to lock transaction for a long time. This transaction can run indefinitely and can be dehydrated also.
3. What is the difference between static, dynamic and direct binding?
static binding specifies particular port address ;
dynamic gives address of the port at runtime
direct binding sends messages to messagebox
1. What are un-typed messages, how does one create them?
2. 23. In Biztalk, what does a message type consist of?
A message type consists of the TargetNamespace#RootElement name
1. 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.
2. 25. What is property promotion, why is it required?
When a property is Promoted, it is exposed to the orchestration/send port filters etc.
1. 26. Can multiple messages be processed or batched without an envelope schema?
By using custom .Net component
1. 27. Can a flat file message be processing without a pipeline?
Nopes, job of a pipeline is to convert an incoming message in to an XML the format which biztalk understands.
1. 28. What is the difference between a Distinguished field and a Promoted Property?
2. How do you achieve First-In-First-Out message processing of messages received from multiple sources using an Orchestration?
you need to build a resequencer pattern. As with ordered delivery there are some limitations such as it expects the all the message to be in order. Secondly your throughput decreases drastically.
3. At high level, what do Receive Ports and Orchestration Send Port really do in terms of messaging? What about Send Ports and Orchestration Receive Ports?
4. 31. When working with Schemas, Maps, Pipelines, and Orchestrations how should the projects be structured?
Some books say all orchestrations should be in one project, all maps should be in one place etc.
A drawback of this comes when u have large projects. u have 20 orchestrations in one project if u need to change in one every thing gets recompiled. So we bifurcated in projects every thing related should be in one project
1. 32. What is direct binding (All About binding)
When a binding is specified at design time, the physical port that matches the parameters configured in the orchestration is created when the orchestration is deployed. When the binding is configured at deployment time, any port that matches the requirements of the logical port can be bound to the orchestration port. For dynamic binding, a physical port is created just as with the Specify Now option, but the port is a dynamic send port that has no address information configured.
A confusing concept for many developers is that while a send port in an orchestration is bound to a physical send port, this does not preclude that message from getting delivered to other subscribers. That is, if another send port happens to have a subscription, through its filters, for the message being sent to the bound port, both send ports receive the message. Binding simply creates the subscription such that the message sent from the orchestration always matches the criteria for the bound send port. Likewise, the orchestration port bound to a receive port creates the appropriate subscription based on message type and receive port ID. The subscriptions guarantee that the messages going in and out of the orchestration get delivered to the bound ports, but the messages still go through the same publish and subscribe mechanism described earlier.
Probably the most misunderstood, and misused or underused binding option is the Direct binding option. Direct binding allows an orchestration to publish messages to the MessageBox database with varying routing properties much like messages are published by receive locations. In simple direct messaging, the message is published to the MessageBox with its promoted properties to be routed like any other published message received into BizTalk Server. This enables any subscriber to receive this message, but requires that at least one subscriber exist or the orchestration will receive a routing failure error.
Another option for direct binding is to use self-correlating ports. Self-correlating ports are ports that create a unique correlation token and use that token alone in correlating messages between instances. The most common use of a self-correlating port is to call or start an orchestration passing in a port parameter. In the called orchestration, the port can be used to send a message, while in the calling orchestration the same port can be used to receive a message. Because the port has a unique correlation token, the message is routed back to the calling orchestration. Self-correlation ports act as private communication channels between orchestration instances.
The final option is to use a partner orchestration in which, in both the calling orchestration and the called orchestration, the port is configured using the same shared port type and in the port configuration, the same port is selected. For example, in both Orch1 and Orch2, Orch2.MyDirectPort is selected. This type of binding sets up a subscription for the receiving orchestration based on the sending orchestration type, the port name, and the operation name. This again ensures that the messages get routed to the correct instance.
All of the direct messaging options use the underlying publish and subscribe model. The difference between these options is in the properties that are used for creating subscriptions and routing, and in the use cases they help solve.
One common problem encountered when using direct bound ports in orchestrations is that an orchestration may publish a message that it is also subscribed to. For example, an orchestration is configured to be activated by a PurchaseOrder message. This orchestration uses a direct port to publish the PurchaseOrder message to the MessageBox. However, in addition to receiving the message as expected, another instance of an orchestration is started because it too had a subscription for PurchaseOrder messages. The processing gets into an endless loop and it may take some time for a developer to figure out what has happened
What is Coorelation?
Correlation in orchestrations is the mechanism for receiving related messages into the same running orchestration instance. In the Orchestration Designer a developer follows these general steps to use a correlation:
• Defines a correlation type that includes the promoted properties that are used to relate messages.
• Defines a correlation set that is an instance of the correlation type just defined.
• For the send and receive ports, specifies whether they initiate or follow a given correlation set.
Instance subscriptions come into play when a correlation set is initiated, as this is when subscriptions are created for all of those ports that follow this correlation set to receive messages. Because the correlation type defines the properties to be used for correlation, the orchestration engine can extract these properties from the message being sent or received by the initiating action. These values are then used to define subscriptions for all of the remaining actions which follow this correlation set.
It is important that messages received into BizTalk Server and intended for use in a correlation have their promoted properties correctly defined and promoted to the message context. Most properties get promoted when a disassembler component in a pipeline extracts the values when the message is initially received. For this reason, it is not possible to use the PassThrough receive pipeline to receive messages that must be correlated to a running instance of an orchestration. This issue arises when you use the SOAP receive adapter to receive correlated messages, because the PassThrough pipeline is the default value for the receive pipeline when using the Web Services Publishing Wizard.
1. What are Persistence Points and what causes them?
Persistence is when the state of a running Orchestration is stored into SQL.
It is good enough to know various shape and actions cause persistence. More specifically, it occurs: end of a transactional scope, at a send shape, at a start Orchestration shape, during dehydration, if the system shuts down expectedly or unexpectedly, or the business process suspends or ends
1. 34. What is the Rules Engine?
The Run-Time Rule Engine performs the following functions:
• Processes rules created as declarative statements without procedural instructions
• Groups all the rules that apply to a business process together (a policy) without having to arrange them in order of, or define them in terms of, relationships, contingencies, or dependencies
• Resolves rule conflicts arising from the simultaneous presence of multiple facts and conditions
• Supports forward chaining of rules that involves reevaluating rules in the executing policy based on changes to the fact base (addition/removal of facts or changes in state/data of existing facts). Forward chaining does not inherently span policies
1. 35. What is BAM used for?
2. 36. What group does a user need to belong to in order to submit messages to the message box?
The user needs to be a member of the hot group or isolated host group (assuming a default installation).
1. When installing Biztalk in a multi-server configuration with a remote SQL and Analysis Services, what SQL components do you need on the Biztalk Server?
SQL client
1. What user rights to you need to perform most actions in HAT?
You must manually grant permissions to BizTalk administrators group to access the Analysis Services Tracking database; by default, only OLAP administrators have permissions to it
1. When installing Biztalk and SQL on a Windows XP SP2 Desktop, what pre-requests are required?
IIS, .NET framework
2.
3. How does one enable Correlations in BizTalk?
First create a Correlation type and then create an instance of it.
• Does BizTalk automatically compensate a unsuccessful transaction?
A Compensation section is generally written, in order to UNDO the effect of a transaction.
• The Compensation section for a scope gets activated only when the scope terminates normally or the scope completes its execution.
• Unlike exceptions, a compensation section can be written for a “Atomic” as well as a “L-R” transaction.
• A Compensation section needs to be explicitly invoked, using the Compensation Shape in order for it to execute.
• A Compensation section for a scope does NOT automatically undo the effect of a transaction. The compensation section must have the undo logic in place in order to have such an effect.
• A Compensation shape can be used to invoke/execute a compensation section. The control returns to the next operation after compensation shape, once the execution of the compensation section is complete.
1. Is it possible to share variables across two branches in a Parallel shape
yes it is possible you just need to set the “Synchronized” property to true.
Transaction types
The classical definition of a transaction is – an atomic unit of work which results in moving the system from one consistent state to a new consistent and durable state. A transaction can either be “committed” or “rolled back” depending on various conditions. Note that a transaction which cannot be rolled back needs to be “compensated”. This means that if an operation ‘f(x)’ has been performed on some data, in order to revert it back we need to perform an operation ‘f(y)’, which essentially performs an undo operation, this is known as “compensation” in simple terms.
• A non-transactional orchestration cannot have ’scope’ shapes set to either “Atomic” or “Long Running”.
• If an orchestration’s transaction type is set to “Atomic”, then the orchestration cannot have any other transactions within its ’scope’ shapes.
• Atomic transactions cannot contain nested transactions or catch exception blocks. However, they can have compensation blocks.
• Long running transactions cannot be isolated from other transactions. However they can contain other atomic transactions and can have catch exception and compensation blocks.
• Batch: A boolean value that determines if this transaction can be batched with other transactions across multiple instances of the orchestration. The default value is “true”. It may improve performance with the possibility of losing isolation data.
• Isolation level: This property defines the degree of isolation between the state changes performed by different atomic transactions. This is not applicable for Long-Running transactions. BizTalk supports three isolation levels. These are ‘Read Committed’, ‘Repeatable Read’ and ‘Serializable’. The last one being the default value.
• Retry: A boolean value which specifies that the atomic transaction can be retried in the event of a failure. Perform the following for Retry-”throw an instance of Microsoft.XLANGs.BaseTypes.RetryTransactionException” within the transaction boundary.
• Transaction type: Can be either “Atomic” or “Long Running” or “None”.
1. Is it possible to have a exception block for an Atomic scope? if not why?
Nopes
1. What is the difference between an Exception block and a Compensation block? is it the equivalent of try-catch-finally?
Exception block can be termed as a catch block. But compensation is different. Its like reversal of a committed transaction.
1. When do we need set the property “Synchronized” = true for a scope?
Incase we want to share a variable between parallel scopes.
2. Is it necessary for all .NET components being called from an Orchestration be Serializable?
Nopes we can also call non serialized objects within orchestration.
3. Can an orchestration Start without an Activatable receive?
Only if it is called from another orchestration
1. What is the purpose of the property “Activate” in a Receive shape?
A Receive shape can be used to start an orchestration. If you set the Activate property to True, the runtime engine will test an incoming message to see whether it is of the right type and, if a filter has been applied, whether the filter expression is satisfied. If the criteria for receipt of the message are met, the runtime engine creates and runs a new orchestration instance, and the Receive shape receives the message
1. Does BizTalk Orchestrations support recursion?
Nopes
1. 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
1. When you use Call Orchestration shape vs Start Orchestration shape?
A Call Orchestration returns the control back to the caller. A Start Ochestration shape starts the orchestration in a non-deterministic way
2. What is the difference between a delay shape vs a listen shape?
‘Delay’ is very much similar to a sleep on the current thread. A ‘Listen’ shape is used to wait for an incoming resource, with a timeout period.
3. How do you prevent occuring of zombies in a Parallel Convoy?
1. Enumerate the steps required to deploy an BizTalk solution from one machine to another machine.
MSI, Bindings, DLLS, BRE Values, IIS folder (incase you have webservices).
1. List out the three important things to consider while designing a BizTalk orchestration!
The Incoming data format, The Business process and The Outgoing data format
1. In an Orchestration design, Orchestration “A” calls another Orchestration “B”, and vice versa. Is it possible to implement this design?
It is NOT possible, since it forms a cyclic dependency
2. Can we get messages to Orchestration without using schema?
If you use XML object, then you can get any *.xml messages
into orchestration
1. How to version your schema?
1. Side by side versioning in BizTalk 2004
Configure any pipeline components to use a specific version of the schema.
If the schema is redeployed under a different version and this is not done it will fail because it looks up by target name space / root element not by assembly.
Deploy the new version
Bind the orchestrations.
The Manual steps are below
1.
1. Disable the receive location
2. Unenlist the old version using the Explorer (do not stop it), this will prevent new instances from starting while allowing old ones to finish
3. Enlist the new version and start it, all new instances will be created using this one.
4. Enable the receive location
1. How to transfer files without using Orchestration?
Content Based Routing
2. What is Message routing and Content routing?
When A message is passed through biztalk without being processed then it is called Message Routing. When A message is passed based on certain field value of schema, it is called content routing.
1. What are Host and Host Instance? Did you deploy BizTalk more than one machine?
Host is nothing but the logical container of host instance. from which we can create host instance. Host instance is a Win-NT service.
A BizTalk Server Host is a logical set of zero or more BizTalk Server run-time processes in which you deploy items such as adapter handlers, receive locations (including pipelines), and orchestrations.
A host instance is the process where the message processing, receiving, and transmitting occurs You install a host instance on each server running BizTalk Server 2006 that has one or more hosts mapped to that server.
1. 62. On which level you have worked in BizTalk development 1-Orchestration, 2-Ports & Adapters?
All Levels
1. How and why you have to use Active Directory in BizTalk development?
to verify the account on domain or if I want to send an email I wud need to verify if the account exist. Or if I would like to right a file on a network drive.
1. 64. How did you connect InfoPath with WebServices?
I didn’t use it.
1. In BizTalk development where and how you have to use custom developed .NET components?
a lot of times. Getting records from SP esp where cursors are involved.
1. 66. Where and how did you use WebServices in Orchestration?
We can use webservices where we need to get data from multiple sources in one go. For e.g. getting price quote from 10 different vendors. You make one orchestration and use WS inside it.
1. 67. How to use custom developed adapters?
2. What is convoy and correlation sets?
Correlation is the process of matching an incoming message with the appropriate instance of
an orchestration. You can create any number of instances of a given orchestration, and while
each of them will perform the same actions, they will do so on different data.
1. How to create dynamic ports?
2. 70. How to put data using SQL/Oracle Adapter?
1. 71. Source schema has nodes First Name, Last Name and destination schema has node Name. How we can get data at destination so that we can have two instance of Name (without using orchestration).
Create a MAP in Biz talk and add first name and last name strings with space in
between and map to destination schema node. Use that map in port to port
binding either in receive port or in send port.
1. 72. What is Binding files?
Binding files in BizTalk is an XML file that contains information of receive send ports there locations. It is usually used when you make a deployment. We make MSI separately without bindings.
1. Did You work BAS and Share Point Services? What the types of Share Point Services Setup?
Well it stands for Business Activity Services, and basically it is a series of services that are hosted on Windows SharePoint Services
1. In a BizTalk project how to consume an external web service?About Consuming Web Services
Adding Web References
Constructing Web Messages
Creating Web Ports
Considerations When Consuming Web Services
Solution1
You can consume (call) a Web service from your orchestration by using Web ports. To consume a Web service from an orchestration, you create a Web port and construct Web messages.
You can use SOAP headers with the consumed Web service, change the URI of a consumed Web service, and dynamically set the URI for a consumed Web service.
Important An orchestration is required to consume a Web service. You cannot use the SOAP send port in scenarios that only use messaging. SOAP send ports must be used with an orchestration.
Solution2
Add configuration port and on port type select web service port type it will automatic create appropriate request and response port.
Here you need to assign input message value to Web service request message
1. 75. What is BAM?
2. Difference between message types and web message type?
Web message types are identical to a normal message type, except you cannot modify, rename or delete them. To delete a Web message type, you must remove the Web reference from your BizTalk project.
3. 77. What is BAS?
4. 78. What are adapters? What do we need it?
Adapters can simply be termed as medium with which BizTalk communicates with other softwares. connect your people, processes, and information together.
1. How to debug an Orchestration?
You can apply break points in HAT (Health Activity Monitoring).
1. In the Orchestration what is the difference between Exception and Compensation? Give an example of its usage scenario.
Exception is simple the try catch block in .net. Lets say you have an expression a = b/c where c=0 it will raise an exception and will be caught in catch block.
Compensation is like you made a transaction where u debited customers account. Now you will do exact opposite meaning crediting with the same amount and the same account.
1. Can we do messaging in BizTalk without Orchestration? If yes how?
2. What is a Convoy? Why do we need it? Give usage scenario for each Convoy.
3. Explain the Publisher – Subscriber of BizTalk
Publishers include receive ports that publish messages that arrive in their receive locations, orchestrations that publish messages when sending messages or starting another orchestration asynchronously, and solicit/response send ports that publish messages when they receive a response from the target application or transport.
In BizTalk Server, there are two main types of subscriptions: activation and instance. An activation subscription is one specifying that a message that fulfills the subscription should activate, or create, a new instance of the subscriber when it is received. Examples of things that create activation subscriptions include send ports with filters or send ports that are bound to orchestrations, and orchestration receive shapes that have their Activate property set to true. An instance subscription indicates that messages that fulfill the subscription should be routed to an already-running instance of the subscriber. Examples of things that create instance subscriptions are orchestrations with correlated receives and request/response-style receive ports waiting for a response from BizTalk Server.
Subscriptions are created by service classes in BizTalk Server
A subscription is a collection of comparison statements, known as predicates, involving message context properties and the values specific to the subscription. For example, Message Type is a context property of messages and many subscriptions specify the message type in their subscription.
When a send port is enlisted, the port creates, at a minimum, a subscription for any message with that send port’s transport ID in the context. This allows the send port to always receive messages intended specifically for it. When an orchestration port is bound to a particular send port, the information about that binding is stored in the BizTalk Management database. When messages are sent from the orchestration through the port bound to the physical send port, the Transport ID is included in the context so that the message gets routed to that send port. However, it is important to note that this send port is not the only send port that can receive messages sent from the orchestration. When an orchestration sends a message, that message is published to the MessageBox with all of the relevant promoted properties. The bound send port is guaranteed to receive a copy of the message because the transport ID is in the context, but any other send port, or orchestration, can have a subscription that also matches the message properties. It is very important to understand that any time a message is published directly to the MessageBox, all subscribers with matching subscriptions will receive a copy of the message.
1. 84. What is a Message Box? And messaging engine?
2. 85. Publish Subscribe architecture simplified?
Fundamental to BizTalk is the Publish / Subscribe Architecture. This architecture basically comprises of 2 main components. First of all, a publisher, who would be responsible to publish the message in the message store. And secondly, a subscriber, who will subscribe to messages of a particular format so that he gets them whenever they are published.
Publishing refers to the process of inserting the messages in the message box database. Normally, a receive port, an orchestration or solicit send port would be involved in publishing any message to the message box. A receive port would receive the message from the pipeline and publish it to the message box for an orchestration or a send port to pick up. An orchestration would publish the message usually while sending it using the send shape. A solicit response port would actually publish the message when it receives a response from the end system.
The subscribers would indicate the message they would like to receive by a set of criteria or filters. Thereby, whenever a message is posted or published to the message box database, a subscriber will be able to get the message based on the filters or criteria mentioned while subscribing. The filters can be specified only on the promoted fields on the message.
1. 86.
2. What is the difference between MSMQ and MSMQT? Why do we need MSMQT?
From a network perspective, BizTalk Message Queuing works the same as Message Queuing (also known as MSMQ). The main difference between the two components is that MSMQT sends messages to a receive location instead of sending messages directly to a queue. This receive location, which is tied directly to the BizTalk Server MessageBox database, is a virtual representation of a Message Queuing queue.
The MSMQT adapter ensures end-to-end ordered delivery of messages.
if an MSMQ application sends messages 1, 2, and 3 to a receive location bound to the MSMQT adapter, then these messages are delivered to an orchestration or send port in BizTalk Server in the same order: 1, 2, 3.
With regard to transaction usage, there is a key difference between how the MSMQT and MSMQ adapters process messages.
When using the MSMQT adapter, the processes of receiving a message from the network and processing it with BizTalk Server are handled under a single transaction. When using the MSMQT adapter, ACK messages generated for the sender indicate that the message has been received and has been successfully processed by BizTalk Server.
Note
An acknowledgment (or “ACK”) is a type of message sent to indicate that a block of data arrived at its destination without error.
High Availability (Transactional, in Order)
To provide high availability for the MSMQT adapter, you can either add multiple computers to the receive host and configure Network Load Balancing (NLB) for fault tolerance or, in BizTalk Server 2006, you can cluster the default BizTalk Host.
If you are running the MSMQT adapter in conjunction with NLB, if one server goes down, the other servers handle the load. If you are running the MSMQT adapter handlers on a clustered host in BizTalk Server 2006, if one host node fails, cluster software fails over the clustered host to the other node.
When using the MSMQ adapter, NLB does not work if you need transactional processing with no data loss, because the MSMQ adapter uses local MSMQ queues for intermediate storage. In this scenario, if a message has been delivered to the local MSMQ queue but has not been consumed by the MSMQ adapter, the message is lost if the computer fails
1. 88. What are the security groups created by BizTalk?
SSO Administrators
SSO Affiliate Administrators
BizTalk Server Administrators
BizTalk Server Operators
BizTalk Application Users
BizTalk Isolated Host Users
Create the BizTalk Windows Service Accounts (Windows Users)
Full Name User logon name
Enterprise Single Sign-On Service SSOService
BizTalk Administrator BTSAdmin
BizTalk Host Instance Account BTSAppHost
BizTalk Isolated Host Instance Account BTSIsolatedHost
Business Rule Engine Update Service Account ReuService
Add the Windows Service Accounts to their respective Groups.
Windows Group Windows User
Server Administrators biztalk\BTSAdmin
SSO Administrators biztalk\BTSAdmin and biztalk\SSOService
BizTalk Application Users biztalk\BTSAppHost
BizTalk Isolated Host Users biztalk\BTSIsolatedHost
1. What is the difference between Windows Workflow and BizTalk server? Explain the scenarios
I want to put a definition around BizTalk to make it easier to compare to Windows Workflow. BizTalk Server is an enterprise level workflow and message processing environment. This environment is tried and tested (extremely rigorously over the last many years). BizTalk also includes many adapters to connect to a variety of back end system. Out of the box, BizTalk provides scalability, manageability, tracking, logging & administration tools.
Windows Workflow is an SDK for creating workflow based applications. The tools are there to build a host and to render a graphical workflow environment. Scalability is possible with Windows Workflow but it is up to the developer to create a truly scalable solution. In addition, there are administrative functions through runtime and tracking visibility but there is not an out of the box administration tool as this is also up to the host developer to create.
The message that I tell people is to use BizTalk when you want to target users/clients that want to span multiple applications whereas Windows Workflow would be used when you want to target users/clients that want workflow within an application.
So, to summarize, Windows Workflow is great for workflow within an application whereas BizTalk is great for workflow across applications
2. How to deploy BizTalk in a multicomputer scenario. Assume there would be DMZ and Corpnet?
3. What is the need to create MSMQT by BizTalk team when MSMQ is already available?
4. Architect a solution that would receive 100 messages of 50 – 100 MB in size and process them in 3 mins?
5. How to deploy BizTalk in a highly available scenario?
Clustered Environment
6. 94. What is the future direction of BizTalk?
7. 95. Why do we need convoy?
When a group of correlated messages could potentially be received at the same time, a race condition could occur in which a correlation set in a particular orchestration instance must be initialized by one of the messages before the other messages can be correlated to that orchestration instance. To ensure that all of the correlated messages will be received by the same orchestration instance, BizTalk detects the potential for such a race condition and treats these messages as a convoy.
Convoy is a term which we use to describe a class of application protocols, specifically it is a set of application protocols which have a race condition as described above. Let’s take an example. Say you are a hospital and want to have a service which handles all information about each patient. For a given patient you have three types of messages, an admittance message, status messages, and a discharge message. If you look at your protocol, you will have built a service which just receives. Now let’s think about what could happen. Let’s say you send the patient admittance message and it goes through the system using maybe a synchronous protocol like HTTP. That means when you get the 202 back, you know the message has been delivered. But what if the BizTalkServer host which is actually supposed to process the message hasn’t started yet (ie the nt service is stopped). Maybe you had a power outage, maybe some intern decided to “hit this button”, who knows. So the orchestration instance which is supposed to handle all messages for patient X has not physically started. The message is in the database (MessageBox) and if you look in HAT you will see the orchestration is marked as ready to run, but it can’t start cause there is no where for it to start.
1. 96. How to resubmit a suspended message? What is possible and what is not possible?
2. How will you create an Error handling framework in BizTalk?
3. 98. Have you ever used BizTalk server in a scenario other than in a typical messaging environment?
4. 99. What are the draw-backs of BizTalk?
Not a very good support with legacy system. Like we faced tons of issue which we had to solve it someway or the other but Microsoft could not come up with a very good answer.
1. What has been your most difficult challenge in implementing Biztalk applications in the real world?
I think with biztalk things were not THAT challenging but with legacy systems things were. Like calling a webservice from oracle, or getting a LARGE object from orchestration into a oracle. And things like that.
1. What are the challenges you have faced using Soap Adapter?
twenty minutes timeout issue. You have to host webservices in the same machine. There is a way I heard but I didn’t do much reading on it.
1. What are persistence points?
2. 103. What are the adapters you have used?
SOAP, TCP, FILE adapter, Oracle adapter
3. Can you use excel file in File Adapter?
umm havnt tried it
4. 105. How will you specify delimiters for Flat File?
there are properties in Flat File schema which u need to set. There you specify delimiters, records specifier etc.
5. 106. What is debatching in BizTalk?
Recently I end up in a scenario where I need to debatch a message inside the orchestration to produce multiple messages based on XPATH
6. 107. What are the communication patterns available in BizTalk?
Each port type has a communication pattern. The communication pattern determines whether one-way or two-way (request-response) transmissions can take place on ports of the given type. For more information
What is XPath? Benefits?
XPath is designed for XML documents. It provides a single syntax that you can use for queries, addressing, and patterns. XPath is concise, simple, and powerful. XPath has many benefits, as follows:
Queries are compact.
Queries are easy to type and read.
Syntax is simple for the simple and common cases.
Query strings are easily embedded in programs, scripts, and XML or HTML attributes.
Queries are easily parsed.
You can specify any path that can occur in an XML document and any set of conditions for the nodes in the path.
You can uniquely identify any node in an XML document.
Queries return any number of results, including zero.
Query conditions can be evaluated at any level of a document and are not expected to navigate from the top node of a document.
Queries do not return repeated nodes.
For programmers, queries are declarative, not procedural. They say what should be found, not how it should be found. This is important because a query optimizer must be free to use indexes or other structures to find results efficiently.
XPath is designed to be used in many contexts. It is applicable to providing links to nodes, for searching repositories, and for many other applications.
1. What are the available message types?
.net type, Multipart message type, schemas and web message type
2. Where can I find more information on BizTalk RFID
3. What specific functionality will be supported with BizTalk RFID?
1. 111. What is RFID?
Radio frequency Identification. But what is RFID? RFID is the reading of physical tags on single products, cases, pallets, or re-usable containers that emit radio signals to be picked up by reader devices. These devices and software must be supported by a sophisticated software architecture that enables the collection and distribution of location-based information in near real time. The complete RFID picture combines the technology of the tags and readers with access to global standardized databases, ensuring real time access to up-to-date information about relevant products at any point in the supply chain. A key component to this RFID vision is the EPC Global Network.
Tags contain a unique identification number called an Electronic Product Code (EPC), and potentially additional information of interest to manufacturers, healthcare organizations, military organizations, logistics providers, and retailers, or others that need to track the physical location of goods or equipment. All information stored on RFID tags accompanies items as they travel through a supply chain or other business process. All information on RFID tags, such as product attributes, physical dimensions, prices, or laundering requirements, can be scanned wirelessly by a reader at high speed and from a distance of several meters.
1. What is an ESB and how can Microsoft help me?
2. 113. Are there different editions of BizTalk Server?
Yeah 2002, 2004 2006 R2 and now R3 or 2009.
1. What is the difference between accelerators and adapters, and how do we know if our company needs them
BizTalk adapters extend the functionality of BizTalk Server, enabling it to connect to other servers, applications and Web services. Specifically, they remove the need to develop infrastructure components such as network protocol support and translation, data conversion, data transformation, in the development of business process automation solutions. BizTalk Server adapters are “no-code” connectivity solutions, and are provided in-box with BizTalk Server 2006 R2.
BizTalk accelerators provide developers with tools, data schemas, and processes to help significantly reduce the time required to develop a custom business solution in specific industries, such as health care, financial services, and supply-chain management and are provided in-box with BizTalk Server 2006 R2. If you are required to comply with specific industry standards, you will likely require an accelerator.
2. What advantages does BizTalk Server 2006 R2 offer over the 2006 release?
WCF
1. SSO Questions
2. How many types of Single Sign-On services are available?
Enterprise Single Sign-On (SSO) provides services to store and transmit encrypted user credentials across local and network boundaries, including domain boundaries. SSO stores the credentials in the SSO database. Because SSO provides a generic single sign-on solution, middleware applications and custom adapters can leverage SSO to securely store and transmit user credentials across the environment. End users do not have to remember different credentials for different applications.
Convoys
What is a host
A BizTalk host is a logical container within a BizTalk Server group that can house BizTalk Server items such as adapter handlers, receive locations (including pipelines), and orchestrations. You typically group items that have similar scale properties into a particular host.
Host Instances
After you create a host (a logical container), you can add physical BizTalk Server computers (host instances) to the host. A host instance runs as an NT Service on the designated BizTalk Server. For each host, you can have only one instance of a particular BizTalk Server computer. However, you can have instances of a particular host on one or more computers, and you can have instances of different hosts on a particular computer
• Receiving. These items do the initial processing of messages after they are picked up in a receive location. When a host contains a receiving item, such as a receive location or pipeline, it acts as a security boundary, and the message decoding and decrypting occurs in a pipeline within the host.
• Sending. These items do the final processing of messages before they are sent out to the send port. When a host contains a sending item, such as a send port or pipeline, the host acts as a security boundary, and the message signing and encryption occurs in a pipeline within the host.
• Processing. These items process messages based on the instructions in an orchestration
Isolated and In Process Host
BizTalk hosts are one of two types, In-process or Isolated. In-process hosts run inside of the BizTalk Server runtime process and Isolated hosts do not run in the BizTalk Server runtime process. The following table lists the items that each of these host types may contain.
In-Process • Orchestrations
• Adapter Send Handlers
• Adapter Receive Handlers other than HTTP and SOAP
Isolated HTTP and SOAP Receive Handlers
Maps
installing an msi
WSE enhancements
Learn how to secure Web services without writing code, how to author security policies, and how to leverage the WSE programming model to secure your Web services.
role in ubl
I played quite variety of roles at UBL. My role included development, analysis, business requirement meetings, task delegation, and since 2 months it was hiring as well.
Business rules engine
we used business rule engine to store connection strings mostly. Or if we needed to maintain some other parameters. But mostly it was for connection strings. We used to encrypt the string and store them in BRE and retrieve it in our component.
Business activity monitoring
Business Activity Monitoring (BAM) is a collection of tools that allow you to manage aggregations, alerts, and profiles to monitor relevant business metrics (called Key Performance Indicators, or KPIs). It gives you end-to-end visibility into your business processes, providing accurate information about the status and results of various operations, processes, and transactions so you can address problem areas and resolve issues within your business.
Why use BAM
The typical enterprise today uses a variety of business applications, such as customer relationship management (CRM), SAP, and order management, purchased or developed internally over time. BAM can be used as a monitoring solution by IT managers who want to cut the cost of their distributed IT environments while improving service quality. It also generates business alerts
What is BAM Definition
A BAM definition is an XML representation of a BAM observation model, which is a high-level definition a business process that you want to monitor. The main parts of the observation model, and therefore the BAM definition, are the milestone and data events to collect (the BAM activity); a description of any data aggregations; and how to present the information to users (the BAM view).
BAM definitions can contain the following items:
• Business activities – A valid BAM definition must contain a business activity (also referred to as a BAM activity). All other items in the definition are optional. For information about adding a business activity to a definition,
• Views – Views define the set of users that can access the data defined by the business activity. Views consist of filtered data, aggregations of the filtered data, and ways of presenting the filtered data, such as a PivotChart report. BAM supports the definition of one or more views per activity.
In a view you can define the following business processes:
• Aliased business data – Aliasing allows you to apply friendly names to data items. For example, a developer may define a data item called “LName.” You can create an alias so that the “LName” is displayed as “Last Name” when viewing the BAM live data. For more information about aliasing
• Duration – The time period over which the activity is monitored.
• Milestone groups – Sets of business milestones. You can use a group as either the starting or ending business milestone of a duration.
• Aggregations – These can be either real-time aggregations (RTAs) or scheduled aggregations (also referred to as online analytical processing (OLAP)), and consist of the following items:
• Measures – A set of numeric values in an Analysis Services (OLAP) cube based on a column in the fact table of the cube.
• Progress dimension – Represents the creation of aggregations with respect to the progress of activities that are still in process.
• Data dimension – Used to categorize an aggregation. Data dimensions are based on the value of string formatted data items in the BAM activity.
• Time dimension – Used to create aggregations across defined time segments.
• Numeric range dimension – Used to categorize aggregations based on friendly names of given numeric ranges.
BAM definitions can contain alert definitions that are defined in the views. BAM definitions can also contain PivotTable layouts. Once the BAM definition is deployed, the PivotTable reports containing the live business data that can be viewed using the Excel livedata workbook or through the BAM portal.
What is the BAM portal?
The BAM portal in BizTalk Server 2006 provides real-time, end-to-end visibility into a business process. It is a Web-based feature that consists of a collection of ASP.NET 2.0 pages. You can customize BAM to enhance the performance and experience for your users.
Why use the BAM portal?
The BAM portal allows you to perform searches, aggregate data, and set alerts on a BAM view, which is a perspective on your business data. This visibility can provide the necessary KPI information for your business, or it can be used as proof of concept before you implement another solution such as extending a Microsoft Office Excel 2003 spreadsheet, using SQL Reporting, or building a custom user interface (UI).
BAM portal components
Following is a brief description of the BAM portal components. For a more detailed description, see the topics in See Also.
Activity searches
You use the BAM portal to perform searches against BAM data to find a specific BAM activity. You create queries by adding and removing search clauses that allow you to display those activities that match criteria for which you want to be alerted.
Queries can be saved and reused. They can also be the basis for an alert, such as a notification when a purchase order arrives from a specific customer.
Aggregations
The portal allows you to capture a snapshot of data and display it in the form of a graphical chart and accompanying PivotTable chart. This data gives you visibility into the health of that process or the overall business. For example, a user may wish to see a simple pie chart that shows a breakdown of the 1,000 invoices received in a day in terms of what stage of processing has been reached by each invoice (400 still in “evaluation,” 400 rejected, 100 paid, and 100 still in “fund allocation”).
The data presented can be the basis for creating an alert, such as “Notify me if there are ever more than 500 invoices in the ‘evaluation’ stage of the process.”
Alert Manager
The portal provides a user interface for the creation of alerts and the editing of existing alerts. Alerts take the conditions that are to be monitored from either the Activity Search or Aggregations page. The Alert Manager is where you fill in the relevant parts of an alert, such as who to notify, how (for example, through e-mail), and whether others can see and subscribe to the alert.
Zombie message
1. Terminate control messages – The orchestration engine allows the use of control messages to cancel all currently running work in a specific orchestration instance. Since the control message immediately halts the running orchestration, zombie instances are not unexpected. A number of Human Workflow related designs tend to use this mechanism as well as some other designs.
2. Parallel listen receives – In this scenario the service instance waits for 1 of n messages and when it receives certain messages it does some work and terminates. If messages are received on a parallel branch just as the service instance is terminating, zombies are created.
3. Sequential convoys with non-deterministic endpoints – In this scenario, a master orchestration schedule is designed to handle all messages of a certain type in order to meet some type of system design requirement. These design requirements may include ordered delivery, resource dispenser, and batching. For this scenario, the tendency is to define a while loop surrounding a listen with one branch having a receive and the other having a delay shape followed by some construct which sets some variable to indicate that the while loop should stop. This is non-deterministic since the delay could be triggered, but a message could still be delivered. Non-deterministic endpoints like this are prone to generating zombies
Convoys Schema Versioning
Zombies Deployment Versioning
coorelataion Persistence Points
NACK TPE
BAM BAM
HM Search PipeLine (Passthru, XML)
finalize questions Solicit send port/send port groups
XML Schemas
An XML schema describes a business document that is represented in XML. Because Microsoft BizTalk Server 2004 uses XML as its canonical representation for business documents, inbound and outbound documents do not require any translation. XML schemas can be created in BizTalk Editor using only the basic set of properties that are available within all schemas, and do not require any schema editor extensions to be enabled.
There are several ways in which you can create XML schemas in BizTalk Server 2004. These include:
• Creating a new schema. This method of schema creation involves adding a new schema to a BizTalk project by using the Add New Item command from the File menu, and then building up the structure of the schema by adding various nodes in the schema tree view.
• Creating a new schema, in conjunction with other schemas. For complex schemas in the real world, you are more likely to build the schemas for your messages by using types provided in other existing schemas. By using the XML Schema definition (XSD) language concepts of importing, including, and redefining schemas, you can take advantage of types already defined in other schemas. For more information about using multiple schemas together, see Schemas That Use Other Schemas.
• Generating a schema from an instance message. You can generate an XML schema that corresponds to a particular instance message as long as that instance message consists of well-formed XML. Use the Add Generated Items –
dialog box, accessed by clicking Add Generated Items on the Project menu, to perform this type of schema generation operation.
Note This type of generation operation can only be used to generate XML schemas, not property schemas or flat file schemas.
• Migrating a schema from an older schema specification language to XSD. You can generate an XML schema for BizTalk Server 2004 from a schema that was developed by using a previous version of BizTalk Server, which stored schemas in XML-Data Reduced (XDR) format. For more information about how to migrate older XDR schemas to the XSD format used by BizTalk Server 2004, see Schema Migration from Previous Versions of BizTalk Server.
You can also generate an XML schema based on XSD from a document schema expressed by using the Document Type Definition (DTD) syntax.
Use the Add Generated Items – dialog box, accessed by clicking Add Generated Items on the Project menu, to perform this type of schema generation operation.
Note These types of generation operations can only be used to generate XML schemas, not property schemas or flat file schemas.
Whichever schema creation technique you use, you will continue by modifying the schema so that it provides a sufficiently complete description of its corresponding instance messages. To get started on these tasks, see Managing the Nodes Within a Schema, Setting Node Properties, and Working with Existing Nodes.
FAQ for BizTalk Orchestrations
FAQ for BizTalk Orchestrations
Authors: Xuehong Gan and Paul Ringseth
Microsoft Corporation
April 2006
Applies to: Microsoft® BizTalk® Server 2004 and Microsoft® BizTalk® Server 2006
Summary: This whitepaper answers some frequently asked questions about orchestrations in Microsoft BizTalk Server 2004 and BizTalk Server 2006.
Prerequisite Knowledge: BizTalk Server 2004 or BizTalk Server 2006
Is there a way to limit the number of active instances of a given orchestration?
________________________________________
BizTalk Server 2004 has no built-in mechanism for controlling the number of instances of a given orchestration. The BizTalk Server engine does its own throttling to maximize system throughput.
If you need to control the number of active instances because of external resource constraints (for example, availability of database connections), then the orchestration must do its own access control. Typically you do this by implementing a singleton or a fixed number of resource-controller orchestrations that dispense access to the resource.
Perhaps the simplest example of instance control is as follows: You want to control the number of instances of orchestration A that are doing work. Orchestration B is the singleton resource dispenser. On activation, A sends a request to B. B reads the request, determines if this new A can execute now, and returns a reply: yes or no. A reads the reply. If the reply is no, A delays for a period of time and then requests again. If the reply is yes, A executes. At completion, A sends another message to B telling B that it is finished.
As stated above, this is a simple example. In practice, you might need something more complex. More abstractly, you need to control the rate at which messages are activated to better match the rate that activated instances can complete their processing.
Additionally, if your resource-controller orchestrations are long running on BizTalk Server 2004, you need to have the following hotfix installed: http://go.microsoft.com/fwlink/?LinkId=65331.
How can I share global variables across all instances of a given orchestration?
________________________________________
There is no easy way to share global variables across all instances of an orchestration. If the global variables are static values, you might consider storing them in a persistent storage, such as a configuration file or SQL database, and allowing each instance to get the values from storage. You can also share a static state in user code as long as locks are placed correctly on access and modification of the shared state.
Why is my orchestration instance suspended with the status of "Completed with Discarded Messages"?
________________________________________
"Completed with Discarded Messages" is one of the states an orchestration instance may end with. A message that is discarded in this way is called a "zombie" and typically occurs when an extra message is routed after control flow in the executing orchestration has passed the Receive shape with the matching subscription. This can be due to a time-out on a long-running transaction or a time-out of a Delay branch on a Listen shape. It can also occur in a loop that contains a Receive shape that exits before consuming all routed messages.
You can use a Windows Management Instrumentation (WMI) method to listen to the suspend events, find the message associated with the orchestration instance, and resubmit the message.
Many messages end up with the status of "Delivered Not Consumed" in HAT. Should I be concerned with them and where should I look?
________________________________________
A message is in the "Delivered Not Consumed" state when it is in the BizTalk Server internal work queue. It might be in this state because the engine is busy with other messages, or because the message destination is processing more slowly than expected.
You first need to determine where these messages are going: to the orchestration or to the send port. In HAT, you can figure this out by looking at what service the "delivered not consumed" references are associated with. Then you can check whether the destination orchestration or the send port is working correctly.
Why does the compiler require my variable to be serializable?
________________________________________
The XLANGs runtime may persist to the database (dehydrate) your orchestration, including all of its data, at any point (except in the atomic scope). When the orchestration dehydrates and rehydrates, user-defined variables are binary serialized and deserialized. In most cases, you need a serializable object. A non-serializable object can only be declared and used in an atomic scope. The XLANGs compiler gives you compilation errors if you try to use a non-serializable data type outside of an atomic scope.
Message definitions, whether with .NET types or with actual message types, require that the .NET types be XML serializable (for example, System.IntPtr cannot define a message), and that all the message parts (in the message type) be defined through either XML-serializable .NET types or schema types.
My object is serializable and implements an interface. When I try to access my object in an Expression shape of a non-atomic scope, the compiler complains that my object is non-serializable. Why?
________________________________________
Interfaces cannot be marked serializable, nor can you assume that they are serializable, because you never know how they are implemented. Therefore, XLANGs treats interfaces as non-serializable. Non-serializable objects must run inside atomic scopes. This is why interface-based programming must be done inside an atomic scope. In fact, in .NET, you cannot declare an interface to be serializable.
How does an orchestration invoke a COM/COM+ component?
________________________________________
XLANGs generates C# code. All user-declared XLANGs variables are generated as C# variables. There is no special behavior except in the case of atomic transactions. When a serviced component (that is, an instance of a class that implements System.EnterpriseServices.ServicedComponent) is declared in an atomic scope, then and only then does XLANGs generate and use a real DTC COM+ transaction.
If a variable is referenced as an L-value (that is, it is written to) in the atomic scope, but is declared in an outer scope, the variable is cloned to support rollback. However, an object (such as an XmlDocument) can be modified inside a .NET function call when passed as an in-parameter, and thus XLANGs will miss that the object is being written to and it will not roll back correctly. The workaround in this case is to pass such objects as ref parameters.
The bottom line is that components should behave as they do in other C# programs.
Why doesn't my atomic transaction retry? How does the atomic transaction retry work?
________________________________________
An atomic transaction retries when a RetryTransactionException is deliberately thrown by the user or when a PersistenceException is raised at the time that the atomic transaction tries to commit. The latter could happen if, for example, your atomic transaction was part of a distributed DTC transaction and some other participant in that transaction aborted the transaction. Likewise if there were database connectivity problems at the time when the transaction was trying to commit, a PersistenceException would be raised.
There can be several root causes for PersistenceException, depending on the situation, but what you generally observe is that all the XLANGs actions in your atomic scope seem to go through correctly, but then instead of committing, the scope fails. If that happens for an atomic scope that has Retry=True, then the atomic scope will retry up to 21 times. The delay between each retry is two seconds by default (but you can modify that value). After 21 retries, if the transaction is still unable to commit, the whole orchestration instance gets suspended. Then you can manually resume it and it will start over, with a fresh counter, from the beginning of the offending atomic scope.
Note that only two exception types can cause an atomic scope to retry: RetryTransactionException and PersistenceException. Any other exception raised in your atomic scope cannot cause it to retry, even if you have the Retry property set to True. If you're having trouble trying to figure out why an atomic scope isn't retrying, double-check the exception type.
You can override the two-second default delay between consecutive retries by using a public property on RetryTransactionException (if that's the exception you're using to cause the retries).
Does orchestration support parallel activation?
________________________________________
Parallel-activating Receive shapes do work under the following conditions:
1. If one of the tasks of a parallel activation has an activatable Receive as the first shape, all of the tasks of that parallel activation must have an activatable Receive as the first shape, and all of those Receive shapes must initialize at least one correlation.
2. If a particular correlation is initialized on more than one task of a parallel activation by a Receive shape, each of the concerned activating Receive shapes must initialize exactly the same correlation.
This is the parallel convoy case. It is the only parallel activation that XLANGs supports.
Why do I sometimes get "could not find subscription error" when I send a message from the parent orchestration to the child orchestration, which was just started by the parent?
________________________________________
This is a race condition. Apparently you expect that the new orchestration will start in time to create the necessary subscriptions to receive the messages that will be sent to it. But you have no idea how long it will take to create the orchestration, because starting a new service is not a synchronous operation.
It would be better to have the newly created orchestration send a message back to its parent orchestration, reporting that it has started. Then have the new orchestration listen for its messages. In this scenario, the parent orchestration knows that there is a receiver for the messages before sending them. This also provides the necessary commit point to get the subscription to the MessageBox database.
How can I get context or other promoted properties from XLANGMessage?
________________________________________
In an Expression shape, you can use yourMessage(propertyName), for example, yourMessage(BTS.MessageID). However, if you want to access message properties from the XLANGMessage interface (for example, from user code), you would use the XLANGMessage methods SetPropertyValue and GetPropertyValue. You cannot use a context property for routing unless the property is in a correlation that is either initialized or followed in a Send shape.
I attach a dynamic send port to a logical port with Delivery Notification = Transmitted. However, the runtime does not seem to deliver any delivery notification. What is going on?
________________________________________
Dynamic ports are not designed to inherit all attributes and characteristics of the port whose address is assigned to the dynamic port. A dynamic port just gets an address, which is analogous to casting a void* pointer in C/C++ to a more structured pointer type. The pointer that initialized that address has had all its information stripped away. The XLANGs runtime only listens for delivery notification if the port is statically set up that way.
How can I perform dynamic transform in XLANGs?
________________________________________
You can use construct/transform code inside an Expression shape, to make it possible to assign the map dynamically. The code inside the Expression shape is similar to the following:
mapType = System.Type.GetType(mapName);
construct Out_msg
{
transform(Out_msg) = mapType(In_msg, In2_msg);
}
I changed some message fields inside an Expression shape. However, when I send the message out, I do not see the updated values. Why?
________________________________________
In BizTalk Server, the messages are immutable. You can use a Construct shape to create a new message. Copy the original message to the new message and update the fields on the new message.
The orchestration calls a Web service with the SOAP send adapter and receives the response. When an exception occurs, the orchestration service is suspended with "Suspended (not resumable)". How can I retry the Send?
________________________________________
You can place the SOAP Send inside a scope with an exception handler and let the exception handler catch the resulting SoapException. Then you can retry the SOAP Send by nesting the scope inside a while loop.
What parameters control dehydration?
________________________________________
Three parameters control dehydration in BTSNTSvc.exe.config: MaxThreshold, MinThreshold, and ConstantThreshold. These work as follows:
• MaxThreshold is the maximum time that a dehydratable orchestration is retained in memory before being dehydrated.
• MinThreshold is the minimum time that a dehydratable orchestration is retained in memory before it is considered for dehydration.
Note
MaxThreshold and MinThreshold are upper and lower bounds for time-to-dehydration. The true time-to-dehydration fluctuates between the MinThreshold and MaxThreshold values. It takes into account both the history of how long it took that subscription to dehydrate in the past and stress/throttling
• ConstantThreshold is used to attempt to ignore the throttling implication in deciding when to dehydrate. Changing this parameter is not recommended. -1 is the default value, and it tells the engine not to use a constant threshold.
History is used as follows in determining time-to-dehydration: Recycling the BizTalk service process resets the history. The history is kept parameterized by subscription; therefore, the history of a given Receive is independent of orchestration instance. The first time a subscription is seen, there is no history, so BizTalk Server chooses to dehydrate immediately. After the first dehydration, BizTalk Server uses the history.
The default for MaxThreshold is 30 minutes and the default for MinThreshold is one second. The default dehydration threshold is 30 minutes. With resource pressure this scales down to as little as MinThreshold. When a Receive blocks, BizTalk Server looks up past blocking times of this Receive for every instance of this orchestration and creates an estimate of how long it will take to receive a message to unblock. If this estimate is greater than the dehydration threshold, then BizTalk Server dehydrates. The first time through the loop with a single instance, there is no history so BizTalk Server dehydrates immediately.
BizTalk Server 2004 and BizTalk Server 2006 differ as follows:
• In BizTalk Server 2004 only: If the history of a subscription across other instances has satisfied the subscription in less time than MaxThreshold, then BizTalk Server waits without dehydrating at that subscription forever or until it is satisfied.
• In BizTalk Server 2006 only: BizTalk Server dehydrates if it has been waiting at any subscription with a non-empty history for more than 2*MaxThreshold.
When does the persistence of an orchestration happen?
________________________________________
Guaranteed persistence is at end-of-transaction (EOT), Send (unless inside an atomic scope), Start Orchestration, and Suspend. Delay or Receive only persists if dehydration occurs. When end-of-service (EOS) or Terminate occurs, there is not a commit of any pending database operations, but the instance state is not persisted.
Commit points are optimized away in the following patterns:
• Two or more EOTs collapses to a single commit.
• One or more EOT followed by EOS collapses to a single commit.
• A Send followed by EOT or EOS collapses to a single commit. For example, Send immediately followed by EOT immediately followed by EOT immediately followed by EOS is a single commit. However, some potential optimizations are missed, for example, "Send, Send, Send, EOT" is three commits because we only coalesce a single "Send, EOT". Similarly, "Send, EOT, Send, EOT" is two commits.
On graceful shutdown BizTalk Server attempts to dehydrate and thus persist all orchestrations in memory. This is not always successful; sometimes orchestrations are not dehydratable and so the process ends without performing all the dehydrations. If this happens, the orchestration is restored on restart from the last persisted point.
How can an orchestration be updated without bringing down the BizTalk Server host?
________________________________________
To update an orchestration
1. Change the AssemblyInfo version number of the orchestrations, and then build and deploy the new assembly.
2. Bind the new orchestrations.
3. Manually perform the following steps:
1. Disable the receive location to temporarily prevent new messages from arriving. Of course, this implies that your service is unavailable to the outside world.
2. Unenlist the old version using BizTalk Explorer (do not stop it). This prevents new instances from starting while allowing old ones to finish.
3. Enlist the new version and start it. All new instances will be created using this one.
4. Enable the receive location.
How can I load a message to construct an XLANGMessage?
________________________________________
When constructing an XLANGMessage with a stream, the stream type must either implement IStreamFactory or else be a MemoryStream. The following code sample shows how to construct an XLANGMessage:
public class FileStreamFactory : IStreamFactory
{
string _fname;
public FileStreamFactory(string fname)
{
_fname = fname;
}
public Stream CreateStream()
{
return new FileStream
(
_fname,
FileMode.Open,
FileAccess.Read,
FileShare.Read
);
}
}
public static void AssignStreamFactoryToPart(XLANGMessage msg)
{
IStreamFactory sf = new FileStreamFactory( @”c:\data.xml” );
msg[0].LoadFrom( sf );
}
How can I make an orchestration output a string without any XML tags?
________________________________________
An orchestration always wraps the System.String string as an XML document when sending it out. For example, the following is the output of the string "mystring: from an orchestration:
mystring
To get a simple string without any XML tags, you need to define a custom-formatted part that serializes to raw text.
The following code shows an example of how to define a type that can be used in place of System.String to define such an XLANGs message part:
public abstract class BaseFormatter : IFormatter
{
public virtual SerializationBinder Binder
{
get { throw new NotSupportedException(); }
set { throw new NotSupportedException(); }
}
public virtual StreamingContext Context
{
get { throw new NotSupportedException(); }
set { throw new NotSupportedException(); }
}
public virtual ISurrogateSelector SurrogateSelector
{
get { throw new NotSupportedException(); }
set { throw new NotSupportedException(); }
}
public abstract void Serialize( Stream stm, object obj );
public abstract object Deserialize( Stream stm );
}
public class RawStringFormatter : BaseFormatter
{
public override void Serialize(Stream s, object o)
{
RawString rs = (RawString)o;
byte[] ba = rs.ToByteArray();
s.Write( ba, 0, ba.Length );
}
public override object Deserialize(Stream stm)
{
StreamReader sr = new StreamReader( stm, true );
string s = sr.ReadToEnd();
return new RawString( s );
}
}
[CustomFormatter(typeof(RawStringFormatter))]
[Serializable]
public class RawString
{
[XmlIgnore]
string _val;
public RawString(string s )
{
if (null==s)
throw new ArgumentNullException();
_val = s;
}
public RawString()
{
}
public byte[] ToByteArray()
{
return Encoding.UTF8.GetBytes( _val );
}
public override string ToString()
{
return _val;
}
}
How can I clean up suspended send port instances after handling the XLANGs exception?
________________________________________
Whenever a message is suspended after retries to a send port, the messaging engine generates a NACK. This NACK is translated into an exception in the orchestration. You can set the DeliveryNotification property to Transmitted on your send port, and add a catch handler to your scope to handle a DeliveryFailureException. However, in addition to generating the NACK, the messaging engine also suspends the message. There is no way to disable this behavior.
You need your own logic to clean up the suspended send port instance (message). You can create another orchestration that subscribes to NACKs. Both ACKs and NACKs have the following system context properties promoted, which can be used in filter expressions for routing.
After you have written an error-handling orchestration to subscribe to NACKs, you can use BizTalk Server WMI methods to terminate the suspended instance. You will get the instanceID of the suspended send port instance in the NACK.
Some of the context properties you can use in subscribing are:
• BTS.AckType. Set to ACK or NACK.
• AckID. Set to the message ID of the message that this ACK/NACK is for.
• AckOwnerID. Set to the instance ID that this ACK/NACK is for.
• AckSendPortName. The name of the send port that this message was being sent over.
• AckOutboundTransportLocation. The outbound URL that this message was being sent to.
When is the Delivery Notification delivered?
________________________________________
A Send on a Delivery Notification (ACK/NACK) can appear at any point in the orchestration. The Receive for the ACK/NACK occurs at the end of the enclosing scope, unless the enclosing scope is atomic. If the scope is atomic, the Receive for the ACK/NACK occurs at the end of the atomic scope's enclosing scope (for example, you do not get the delivery failure exception until all shapes in the enclosing scope have executed).
I have an orchestration with custom components. I deployed my assembly successfully. However, when I tried to run the application, I got an error: "File or Assembly name or one of its dependences not found."
________________________________________
This error usually means the BizTalk orchestration engine cannot locate the custom component. You must install all assemblies included in a BizTalk application in the global assembly cache of the computer that hosts the application.
Why does the orchestration debugger show the orchestration is running at the Send shape even though I know the Send has finished?
________________________________________
When you look at an orchestration in the debugger, you only see its state at the last commit point (in this case the send).
To see the current state of the orchestration, you can suspend the orchestration instance from HAT and open the Orchestration Debugger on this instance. From the Debug menu of the Orchestration Debugger, you can resume the instance in debug mode and attach to the instance to see its state.
When I terminate active orchestration instances from HAT, the instances stay active with Terminate as the pending job. How can I force them to terminate immediately?
________________________________________
You can stop and unenlist the orchestration. Then you can terminate the orchestration in HAT.
