- Orchestrations

BizTalk: Ordered Delivery

Leonid Ganeline — Wed, 11 Jan 2012 22:34:36 GMT

It is one more description of the Ordered Delivery (OD) in BizTalk.

The main article about it is in MSDN.

Here I am discussing the BizTalk Ordered Delivery “implementation details”.

OD Considerations

Ordered Delivery (sequential) mode is opposite of the “Parallel Delivery” mode. Parallel Delivery is the most productive mode; the Ordered Delivery is less productive mode.
Transports such MSMQ and protocols, supporting the WS-ReliableMessaging, are the protocols supporting OD. Other protocols as FTP, File, SQL, SMTP etc. do not have notion of the “order”.
BizTalk application usually is a part of the whole message workflow.
There are two approaches in the OD implementation:
- All steps of the message workflow independently support OD.
- A Destination System implements the re-sequencing and manages lost and duplicate messages.
Order is relative. Sequences can be ordered regards one or several parameters. For example, OD for the Company or for the Company + Department.

OD and the BizTalk Architecture

MessageBox is an implementation of the Message Queue. OD is an intrinsic feature of the MessageBox.
The BizTalk Server works in the Parallel Delivery mode by default.
There are three parts in the BizTalk message exchange outside of the MessageBox in relation to OD: Receive Locations; Orchestrations; Send ports.
- Receive Locations support OD on the Transport level (say, MSMQ and some WCF adapters).
- OD in Orchestrations is implemented by the sequential convoy pattern.
- Send ports support OD for all static adapters.
The BizTalk Pipelines (part of Receive and Send Ports) always process messages in order using streams.

OD and Ports

To force Send Ports work in order we set up a flag the “Ordered Delivery” in Send Ports, then the BizTalk MessageBox takes care of implementing OD.

To force Receive Locations work in order we set up flag the “Ordered Delivery” option in the Receive Location Transports, whenever is possible. Then the BizTalk Transport Adapter takes care of implementing OD.

Ordered Delivery Send Port instance works as a singleton service. Since start it stays in Running state. It will not recycle if we restart its Host Instance. We could manually terminate it, if we want.

OD and Orchestrations

MessageBox implements the convoy message exchange pattern [See Using Correlations in Orchestrations]. See the detail convoy description in the BizTalk Server 2004 Convoy Deep Dive article.
It is not just a design pattern that developer should follow. There are special mechanisms inside MessageBox responsible for implementing OD.

OD and Orchestration: Sample

Imagine four Orchestrations which implement four approaches to the sequencing.

The first is the ProcessNoOrder Orchestration. It processes all messages without any order. One ProcessNoOrder Orchestration instance will be created for each inbound message.

The ProcessInOrder Orchestration processes all messages in one sequence. Only one ProcessInOrder Orchestration instance will be created.

The ProcessInOrderByCompany Orchestration processes messages in sequences correlated by the Company value (A, B, C, D, etc.). The separate queue is created for each new value of the Company. Messages inside queues are processed in order. Queues for different Companies are independent. A separate ProcessInOrderByCompany Orchestration instance will be created for each new Company value.

The ProcessInOrderByProduct Orchestration works exactly as the ProcessInOrderByCompany Orchestration but correlated by the Product value (xx, yy, etc.).

Discussions

Performance

By default all Orchestration and Messaging Service instances works in the Parallel Delivery mode with maximum performance.

If we check up the Ordered Delivery option in Send Port, BizTalk will initiate the Send Port instance as a singleton service. It is always a single instance. We don’t have the flexibility of the Orchestration where we could tune up “the proportion of the sequencing” and could control the recycling of the service instance.

Send Port OD could be in two states, on and off:

OD is off: a service instance per message, one message per queue, maximum performance.
OD is on: one infinite service instance, all messages in one queue, minimum performance.

Orchestration OD could be in two states also, on and off:

OD is off: a service instance per one activating message, one activating message per queue, maximum performance.
OD is on: one or several service instances, one per new correlation set value; all correlated messages per queue; performance is from min to max, depends ot the correlation set..

Carefully designing the correlation sets we could tune up the performance of the Orchestration. For example, if we only care of the document order for each separate Company, we include the Company to the Correlation set. If we had thousand documents related to hundreds companies, the performance will be near maximum. If there are only two companies, the performance will be near minimum, and we should consider improving the correlation with one more parameter.

Orchestrations and Zombies

Zombies are big problem of Convoy Orchestrations. See BizTalk: Instance Subscription and Convoys: Details article with description of this problem. This problem could be mitigated but could not be completely removed. We are waiting a new version of the BizTalk Server where this issue will be targeted.

BizTalk Server version Next, Ordered Delivery and Zombies

It is possible the BizTalk Server version Next will implement the automatic Ordered Delivery for Orchestrations, with pattern similar to the Ordered Delivery in Send Ports.

Three new Orchestration parameters are shown up there: Ordered Delivery, Stop on Exception, and Recycle Interval (in seconds).

Ordered Delivery parameter works in the same way as the Ordered Delivery parameter of the Send Port. Now we don’t have to build the Convoy Orchestration manually. No more Loop inside Orchestration.

If the Ordered Delivery parameter set up to True, the Orchestration is working as a Singleton. The first Receive shape receives all correlated messages in sequence. Correlation set is created implicitly regards of the Activation Subscription expression.

There are several limitations for this kind of Orchestration. The most important is: only one Receive shape is permitted here.

There are two big advantages of this new feature:

Simplified Orchestration design for the Ordered Delivery.
No more Zombies. The Orchestration instance is recycled in controllable way, when no messages, matched the Orchestration Subscription, are placed in the MessageBox.

Conclusion

We discussed the Ordered Delivery implemented in the BizTalk Server and ways to improve it.

BizTalk: Sample: Error Handling

Leonid Ganeline — Sun, 01 Jan 2012 19:57:03 GMT

Recently I uploaded a "BizTalk: Sample: Error Handling" in MSDN Gallery

This sample shows the BizTalk features:

Routing Failed Messages in ports
Catching Failed Messages with Send Port
Catching Failed Messages with Orchestration
Handling Exceptions inside Orchestration
Handling SOAP Fault messages inside Orchestration

BizTalk Orchestration Naming Conventions

Leonid Ganeline — Wed, 28 Dec 2011 20:38:39 GMT

This is a second part of the BizTalk Naming Convention.

Part 1: biztalk: BizTalk solution naming convention

Special Orchestration Objects

<RoleLink> =:
roleLink_ + <Name>

Note: These objects are special BizTalk objects. They are used in different language context and sometime they use different language syntax. Prefixes help to differentiate the objects in the XLang expressions.

where

	Send	Receive	Send-Receive (Solicit-Response)	Receive-Send (Request- Response)
prefix	S_+	R_+	SR_+	RS_+

Notes:

The Port objects are the only objects which can be seen outside orchestration. We see them while bind orchestration with Ports, not the orchestration Ports but Ports created in the BizTalk Administration Console. Sometimes the orchestration Ports are named as Logical Ports and the Ports as the Physical Ports. Here are some considerations about this ambiguity with Port names.
Send-receive prefixes help while Orchestration is binding with Ports. Ports with different Communication pattern are using different prefixes.

Example: S_ OrderAck.

Orchestration Object Types

<ArtifactType> =:
<ArtifactName> + “_type”

Note: We can see orchestration types in the Orchestration View window in Types. They are: Port, Multi-part Message, Correlation and Role Link Types. We can use one suffix the “_type” for all different types because different types are seen only in the different lists and never mixed. For instance, we can never see the port types together with message types.

Controversial:Suffixes for types work better than prefixes, because types are mostly used in the drop-down lists not in the XLang expressions.

Orchestration Workflow Shapes

Problems with orchestration shapes:

Shapes are too small to display long names (only 12-18 characters are visible).
We have to hover a mouse over a shape or click shape to see Properties window and to "understand" this shape, to understand which message is processed.

Useful features:

Shapes have names, but names are not the “variable names”, not identifiers. They are descriptions (excluding the Port shapes names, which have not Name parameter but Identifier and Description parameters). Shape names are used only for description not as XLang variable identifiers. Shape names can be long and can include any symbols as spaces, dots, etc.
Icons of shapes give us the useful information. Do not repeat the “icon information” by words. For example, we can a name a Construction shape as “Construct OrderAck” or as “OrderAck”. Last variant give us more clear and short definition because we have the Construction icon + name.
Shape names are used mainly in Orchestration Editor (excluding the Port shapes names). We don’t need the “well-sorted” names, so we don’t need to use prefixes, because the main purpose of the prefixes is creating well-sorted lists.
Group shape is a scalable shape. Nesting other shapes to a Group shape can make a long description visible. Group shape will display as much text as you want. Group shapes add a lot of documentation value to the orchestration.

Rules for shapes

Whenever it is possible use the short MessageType as a shape name.
Do not repeat a type of shape icon by word.
Feel free to use spaces and any other symbols inside the shape names.
Feel free to repeat the shape names.

Note: Purpose of the orchestration and the most of the shapes is in processing the messages. We can unambiguously describe the messages by the message type. A message type gives us the main information about a message. That is why in the most cases using the message type as the shape name gives us the main information about message flow, about the whole orchestration processing.
Example: Send shape with name "OrderAck" means “send OrderAck message”.

Controversial:

Orchestration Naming Convetion works not to make easier the administration and troubleshooting but mostly to make orchestration more readable. Most orchestration names are not visible outside the Orchestration Editor. So, do not force the orchestration naming convention to hard! If your developers use differen conventions, it is fine; of course, if they understand each other. Forcing convention can do more harm than help. It can force team to spend more effort for a little.
When exception is thrown from a shape, the error description includes a name of the shape. It is a rare case when names are exposed outside of the Orchestration Editor. When we use MessageType as a name of shapes, many shapes can get the same name. So, if we want to differentiate shape names for debugging purpose, we could use numbers or single letters in the end of names.
Example: “OrderAck 2”

BizTalk: Using context for routing

Leonid Ganeline — Mon, 28 Feb 2011 00:26:18 GMT

[See Sample: Context routing and throttling with orchestration]

Imagine the project where most of the routing happens between orchestrations. I.e. routing is mostly between the MessageBox and orchestration with direct endpoints.

Imagine also the most of the messages are with the same Message type.

Usually in this case messages got the special node only for the routing. For example, the field can be the “Originator” or “Recipient” or “From” or “To”.

What wrong is with this approach, it creates the dependency between the message and the message processing. Message “knows” something about Originator or Recipient.

So what we can do with it? How can we “colorize” the same message to route it to the different places without changing the message itself?

One of the decisions is to use the message context.

BizTalk uses the promoted properties for routing. There are two kinds of the properties: the content properties and the context properties. The content property extracts its value from inside the message, it is a value of the element or attribute. [See MSDN] The context property gets its value from the message environment. It can be the port name that receive this message, it can be the message Id, created by the BizTalk. Context properties look like the headers in the SOAP message. Actually they are not the headers but behave like headers. The context properties are the good match for our case.

First, we don’t have to change the message itself to set or change the routing property. The context is stored outside the message body.

Second, we don’t have to create the property schema to use the context properties. [See MSDN: How to create Property schema] BizTalk has the predefined schema set for the context properties. [See MSDN: Message Context Properties] Use one of them and that's it.

The main purpose of the context properties is working on behalf of the BizTalk internals. But we can read, create and change them. Just do not interfere with BizTalk internals on this way.

BizTalk: Sample: Context routing and Throttling with orchestration

Leonid Ganeline — Sun, 27 Feb 2011 23:04:53 GMT

[See BizTalk: Using context for routing]

The sample demonstrates using orchestration for throttling and using context routing.

Usually throttling is implemented on the host level (in BizTalk 2010 we can also use the host instance level throttling). This sample demonstrates the throttling with orchestration convoy, that slows down a message flow from some customers. Sample implements sort of quality service agreement layer for different kind of customers.

The sample demonstrates the context routing between orchestrations. It has several advantages over the content routing. For example, we don’t have to create the property schema and promote properties on the schemas; we don’t have to change the message content to change routing.

Use case:

The BizTalk application has a main processing orchestration that process all input messages. The application usually works as an OLTP application. Input messages came in random order without peaks, typical scenario for the on-line users.

But sometimes the big data batch payloads come. These batches overload processing orchestrations. All processes, activated by on-line users after the payload, come to the same queue and are processed only after the payload. Result is on-line users can see significant delay in processing. It can be minutes or hours, depending of the batch size.

Requirements:

On-line user’s processing should work without delays. Big batches cannot disturb on-line users. There should be higher priority for the on-line users and the lower priority for the batches.

Design:

Decision is to divide the message flow in two branches, one for on-line users and second for batches. Branch with batches provides messages to the processing line with low priority, and the on-line user’s branch – with high priority.

All messages are provided by one hi-speed receive port.

BTS.ReceivePortName context property is used for routing. The Router orchestration separates messages sent from on-line users and from the batch messages.

But the Router does not use the BizTalk provided value of this property, the Router set up this value by itself. Router uses the content of the messages to decide if it is from on-line users or from batches.

The message context property the BTS.ReceivePortName is changed respectively, its value works as a recipient address, as the “To” address for the next recipient orchestrations. Ideally we should use two receive ports or two receive locations and BizTalk set up the context property for us. If we use the same context for both messages (the same port and location), we need to use orchestration to modify the context property using content of the messages or something else.

Those next orchestrations are the BatchBottleneck and the MainProcess orchestrations.

Messages with context equal “ToBatch” are filtered up by the BatchBottleneck orchestration. It is a unified convoy orchestration and it throttles the message flow, delaying the message delivery to the MainProcess orchestration.

The BatchBottleneck orchestration changes the message context to the “ToProcess” and sends messages one after another with small delay in between. Delay can be configured in the BizTalk config file as:

Of course, messages with context equal “ToProcess” are filtered up by the MainProcess orchestration.

NOTES:

Filters with string values: In Orchestrations (the first Receive shape in orchestration) use string values WITH quotes; in Send Ports use string values WITHOUT quotes.
Filters on the Send Ports are dynamic; we can change them in run-time. Filters on the Orchestrations are static; we can change them only in design-time.
To check the existence of the promoted property inside orchestration use the Expression shape with construction like this:
if (BTS.ReceivePortName exists myMessage) { …; }
It is not possible in the Message Assignment shape because using the “if” statement inside Message Assignment is prohibited.
Several predefined context properties can behave in specific way. Say MessageTracking.OriginatingMessage or XMLNORM.DocumentSpecName, they are required some internal rules should be applied to the format or usage of this properties. MessageTracking.* parameters require you have to use tracking and you can get unexpected run-time errors in some cases. My recommendation is - use very limited set of the predefined context properties.
To “attach” the new promoted property to the message, we have to use correlation. The correlation type should include this property. [Here is a good explanation by Saravana ]
Say we have two correlation types, each with one parameter inside. If we want to correlate to both parameters simultaneously, we cannot use both correlation types, we have to create the correlation type with both parameters and use this type. Otherwise only one correlation type would be chosen for correlation, that means only parameter would be used for correlation.

[The sample source code is here].

BizTalk: Suspend shape and Convoy

Leonid Ganeline — Thu, 10 Feb 2011 06:06:53 GMT

Part 1: BizTalk: Instance Subscription and Convoys: Details

This is a Part 2.

I am discussing the Suspend shape together with Convoys and going to show that using them together is undesirable.

In previous article we investigated the Instance Subscriptions and how they could create situation with dangerous zones in processing.

Let' start with Suspend shape. [See the BizTalk Help]

"You can use the Suspend shape to make an orchestration instance stop running until an administrator explicitly intervenes, perhaps to reflect an error condition that requires attention beyond the scope of the orchestration. All of the state information for the orchestration instance is saved, and will be reinstated when the administrator resumes the orchestration instance.

When an orchestration instance is suspended, an error is raised. You can specify a message string to accompany the error to help the administrator diagnose the situation."

On the Suspend shape the orchestration is stopped in the Suspended (Resumable) state. Next we have two choices, one is to resume and the second is to terminate the orchestration.

Is the orchestration is stopped or unenlisted? You don't find a note about it anywhere. The fact is the Orchestration is stopped and still enlisted. It is very important.

So again, the suspended orchestration can be resumed or terminated. The moment when the operator or the operation script resumes or terminates can be far away. It is also important.

Let's go back to the case from previous article. Make sure you notice the convoy and the dangerous zone after the last Receive shape.

Now we have a Suspend shape inside the orchestration.

The first orchestration instance is suspended. Next messages start new orchestration instance and have been consumed by this orchestration, right? Wrong!

The orchestration is stopped on the Suspend shape but still enlisted. Now the dangerous zone, the "zombie zone" is expanded to the interval between the last receive and the moment of termination or end of the orchestration. The new orchestration instance for this convoy will not start till this moment. How fast operator finds out this suspended orchestration? Maybe hours or days. All this time orchestration is still enlisted and gathering the convoy messages. We can resume the orchestration but we cannot resume these messages together with orchestration.

Seems the name Suspended of the orchestration is misleading. The orchestration can be in the Started (and Enlisted)/Stopped (and Enlisted)/Unenlisted state. The Suspend shape switches orchestration exactly to the Stopped state. The Stop name would describe the shape clearly and unambiguously and the Stopped state would describe the orchestration.

Imagine we can change the BizTalk.

The Orchestration editor can search these situations and returns the compile error. In similar case the Orchestration Editor forces us to use only ordered delivery port with convoys.
The run-time core can force the orchestration with convoy be suspended in Unresumable state, that means the run-time unenlists the orchestration instance subscriptions.
The Suspend shape name should be changed. The "Suspend" name is misleading. The "Stop" name is clear and unambiguous. The same for the orchestration state, it should be “Stopped” not “Suspended (Resumable)”.

Conclusion:

It is not recommended using a Suspend shape together with the convoy orchestrations.

BizTalk: Instance Subscription and Convoys: Details

Leonid Ganeline — Sun, 06 Feb 2011 01:10:28 GMT

This is Part 1.

Part 2. BizTalk: Suspend shape and Convoy

Convoys are frequently used in the in the orchestrations in BizTalk Server. Sometimes we have got contra intuitive behavior in the convoys, when messages and orchestrations get suspended in unpredictable manner. This issue is well-known, the suspended messages get name the "zombie". The name is unofficial, but issue is still there. Here I would describe in details, what, when and why this zombie situations are happen.

An orchestration can be enlisted with many subscriptions. In other word it can have several Receive shapes. Usually the first Receive uses the Activation subscription but other Receives create the Instance subscriptions. [See “Publish and Subscribe Architecture” in MSDN]

Here is a sample process.

This orchestration has two receives. It is a typical Sequential Convoy. [See "BizTalk Server 2004 Convoy Deep Dive" in MSDN by Stephen W. Thomas].

Let's experiment started.

There are three possible scenarios depended of the message sequences.

First scenario: everything is OK

Activation subscription for the Sample message is created when the orchestration the SampleProcess is enlisted.

The Instance subscription is created only when the SampleProcess orchestration instance starts and this subscription is removed when the orchestration instance ends.

So far so good, the Message_2 is delivered exactly in this time interval and consumed.

Second scenario: no consumers

Three Sample_2 messages are delivered. The first one is delivered before the SampleProcess starts and before the instance subscription is created. Second message is delivered in the correct time interval. The third one is delivered after the SampleProcess orchestration ended and the instance subscription was removed.

Note:

· It is not the first Sample_2 consumed. It was first in the queue but it was not waiting, it was suspended when it had been delivered to the Message Box and didn’t have any subscribers at this moment.

The first and the last Sample_2 messages are Suspended (Nonresumable) in the Message Box. For each of them two (!) service instances have created. One service instance has the ServiceClass of Messaging, and its Error Description is:

The second service instance has the ServiceClass of RoutingFailureReport, and its Error Description is:

Third scenario: something goes wrong

Two Sample_2 messages are delivered. Both are delivered in the same interval, while the SampleProcess orchestration is working and the instance subscription has created.

First Sample_2 is consumed. The second Sample_2 has the subscription, but the subscriber, the SampleProcess orchestration, will not consume it. After the SampleProcess orchestration is ended (And only after! I will discuss this in the next article.), it is suspended (Nonresumable). Now only one service instance is suspended. This service instance has the ServiceClass of Orchestration, and its Error Description is:

In the Message tab the Sample_2 message is in the Suspended (Resumable) status.

Notes:

The orchestration consumes the extra message(s) and gets suspended together with these extra messages. These messages are not consumed in term of “processed by orchestration”. But they are consumed in term of the “delivered to the subscriber”. The receive shape in the orchestration does not receive these extra messages. But these messages are routed to the orchestration. The Error information looks ambiguous.
The time zone between the last receive shape and the end of the orchestration is a "dangerous zone". The message delivery pattern should be scrutinized to avoid it.

Unified Sequential convoy

Now one more scenario.

It is a unified sequential convoy. The activation subscription is for the same message type as it for the instance subscription. The Sample_2 message now is the Sample message. For simplicity the SampleProcess orchestration consumes only two Sample messages. Usually the orchestration consumes a lot of messages inside a loop in this scenario, but now there are only two of them.

First message starts the orchestration, the second message goes inside this orchestration. Then the next pair of messages follows, and so on.

But if the input messages follow in shorter intervals we have got the problem.

We lose messages in unpredictable manner.

Conclusion:

Maybe the better behavior would be if the orchestration removes the instance subscription after the message is consumed, not in the end on the orchestration. This behavior looks like a bug. But right now it is a “feature” of the BizTalk subscription mechanism.
The time zone between the last receive shape and the end of the orchestration is a "dangerous zone". The message delivery pattern should be scrutilized to avoid this zone as much as possible.

Note [2011-2-9]:

I saw several times the explanation of the zombies, where the zombie can be created in the time zone between the moment an orchestration is scheduled to dispose and the moment the orchestration is disposed. I.e. the average dangerous time zone is about half of the MessageBox polling interval (by default it is 1 sec), that means 0.5 sec. It is not correct. The dangerous zone is between the last receive (for the message with the instance subscription) and end of orchestration, and this zone could be much bigger than a second.

See more about zombies in BizTalk from the BizTalk Core Engine Blog

BizTalk: History of one integration project

Leonid Ganeline — Fri, 24 Dec 2010 21:26:31 GMT

[Russian version of the article]

"In the beginning God made heaven and earth. Then he started to integrate." At the very start was the requirement: integrate two working systems. [fairy tale of the system integrators]

Small digging up: It was one system. It was good but IT guys want to change it to the new one, much better, chipper, more flexible, and more progressive in technologies, more suitable for the future, for the faster world and hungry competitors.

One thing. One small, little thing. We cannot turn off the old system (call it A, because it was the first), turn on the new one (call it B, because it is second but not the last one). The A has a hundreds users all across a country, they must study B. A still has a lot of nice custom features, home-made features that cannot disappear. These features have to be moved to the B and it is a long process, months and months of redevelopment.

So, the decision was simple. Let’s move slowly not jump, let’s both systems working side-by-side several months. In this time we could teach the users and move all custom A’s special functionality to B.

That automatically means both systems should work side-by-side all these months and use the same data. Data in A and B must be in sync. That’s how the integration projects get birth.

Moreover, the specific of the user tasks requires the both systems must be in sync in real-time. Nightly synchronization is not working, absolutely.

First draft

The first draft seems absolutely cool. Both systems keep data in SQL databases. When data changes, the Create, Update, Delete operations performed on the data, and the sync process could be started. The obvious decision is to use triggers on tables. When we are talking about data, we are talking about several entities. For example, Orders and Items [in Orders].

The decision was to use the BizTalk Server to synchronize systems. Why it was chosen is another story.

Second draft

Let’s take an example how it works in more details.

1. User creates a new entity in the A system. This fires an insert trigger on the entity table. Trigger has to pass the message “Entity created”. This message includes all attributes of the new entity, but I focused on the Id of this entity in the A system. Notation for this message is id.A. System A sends id.A to the BizTalk Server.

2. BizTalk transforms id.A to the format of the system B. This is easiest part and I will not focus on this kind of transformations in the following text. The message on the picture is still id.A but it is in slightly different format, that’s why it is changing color. BizTalk sends id.A to the system B.

3. The system B creates the entity on its side. But it uses different id-s for entities, these id-s are id.B. System B saves id.A+id.B. System B sends the message id.A+id.B back to the BizTalk.

4. BizTalk sends the message id.A+id.B to the system A.

5. System A saves id.A+id.B.

Why both id-s should be saved on both systems? It was one of the next requirements. Users of both systems have to know the systems are in sync or not in sync. Users working with the entity on the system A can see the id.B and use it to switch to the system B and work there with the copy of the same entity. The decision was to store the pairs of entity id-s on both sides. If there is only one id, the entities are not in sync yet (for the Create operation).

Third draft

Next problem was the reliability of the synchronization. The synchronizing process can be interrupted on each step, when message goes through the wires. It can be communication problem, timeout, temporary shutdown one of the systems, the second system cannot be synchronized by some internal reason. There were several potential problems that prevented from enclosing the whole synchronization process in one transaction.

Decision was to restart the whole sync process if it was not finished (in case of the error). For this purpose was created an additional service. Let’s call it the Resync service.

We still keep the id pairs in both systems, but only for the fast access not for the synchronization process. For the synchronizing these id-s now are kept in one main place, in the Resync service database.

The Resync service keeps record as:

· Id.A

· Id.B

· Entity.Type

· Operation (Create, Update, Delete)

· IsSyncStarted (true/false)

· IsSyncFinished (true/false0

The example now looks like:

1. System A creates id.A. id.A is saved on the A. Id.A is sent to the BizTalk.

2. BizTalk sends id.A to the Resync and to the B. id.A is saved on the Resync.

3. System B creates id.B. id.A+id.B are saved on the B. id.A+id.B are sent to the BizTalk.

4. BizTalk sends id.A+id.B to the Resync and to the A. id.A+id.B are saved on the Resync.

5. id.A+id.B are saved on the B.

Resync changes the IsSyncStarted and IsSyncFinished flags accordingly.

The Resync service implements three main methods:

· Save (id.A, Entity.Type, Operation)

· Save (id.A, id.B, Entity.Type, Operation)

· Resync ()

Two Save() are used to save id-s to the service storage. See in the above example, in 2 and 4 steps.

What about the Resync()? It is the method that finishes the interrupted synchronization processes. If Save() is started by the trigger event, the Resync() is working as an independent process. It periodically scans the Resync storage to find out “unfinished” records. Then it restarts the synchronization processes. It tries to synchronize them several times then gives up.

One more thing, both systems A and B must tolerate duplicates of one synchronizing process. Say on the step 3 the system B was not able to send id.A+id.B back. The Resync service must restart the synchronization process that will send the id.A to B second time. In this case system B must just send back again also created id.A+id.B pair without errors. That means “tolerate duplicates”.

Fourth draft

Next draft was created only because of the aesthetics. As it always happens, aesthetics gave significant performance gain to the whole system.

First was the stupid question. Why do we need this additional service with special database? Can we just master the BizTalk to do something like this Resync() does?

So the Resync orchestration is doing the same thing as the Resync service.
It is started by the Id.A and finished by the id.A+id.B message. The first works as a Start message, the second works as a Finish message.

Here is a diagram the whole process without errors. It is pretty straightforward.

The Resync orchestration is waiting for the Finish message specific period of time then resubmits the Id.A message. It resubmits the Id.A message specific number of times then gives up and gets suspended. It can be resubmitted then it starts the whole process again:
waiting [, resubmitting [, get suspended]], finishing.

Tuning up

The Resync orchestration resubmits the id.A message with special “Resubmitted” flag. The subscription filter on the Resync orchestration includes predicate as (Resubmit_Flag != “Resubmitted”). That means only the first Sync orchestration starts the Resync orchestration. Other Sync orchestrations instantiated by the resubmitting can finish this Resync orchestration but cannot start another instance of the Resync.

Here is a diagram where system B was inaccessible for some period of time. The Resync orchestration resubmitted the id.A two times. Then system B got the response the id.A+id.B and this finished the Resync service execution.

What is interesting about this, there were submitted several identical id.A messages and only one id.A+id.B message. Because of this, the system B and the Resync must tolerate the duplicate messages. We also told about this requirement for the system B. Now the same requirement is for the Resunc.

Let’s assume the system B was very slow in the first response and the Resync service had time to resubmit two id.A messages. System B responded not, as it was in previous case, with one id.A+id.B but with two id.A+id.B messages.
First of them finished the Resync execution for the id.A. What about the second id.A+id.B? Where it goes? So, we have to add one more internal requirement. The whole solution must tolerate many identical id.A+id.B messages. It is easy task with the BizTalk. I added the “SinkExtraMessages” subscriber (orchestration with one receive shape), that just get these messages and do nothing.

Real design

Real architecture is much more complex and interesting.

In reality each system can submit several id.A almost simultaneously and completely unordered.

There are not only the “Create entity” operation but the Update and Delete operations. And these operations relate each other. Say the Update operation after Delete means not the same as Update after Create.

In reality there are entities related each other. Say the Order and Order Items. Change on one of it could start the series of the operations on another. Moreover, the system internals are the “black boxes” and we cannot predict the exact content and order of the operation series.

It worth to say, I had to spend a time to manage the zombie message problems. The zombies are still here, but this is not a problem now. And this is another story.

What is interesting in the last design? One orchestration works to help another to be more reliable. Why two orchestration design is more reliable, isn’t it something strange? The Synch orchestration takes all the message exchange between systems, here is the area where most of the errors could happen. The Resync orchestration sends and receives messages only within the BizTalk server.

Is there another design? Sure. All Resync functionality could be implemented inside the Sync orchestration. Hey guys, some other ideas?

BizTalk: Compensation Model

Leonid Ganeline — Fri, 26 Feb 2010 06:34:58 GMT

BizTalk: Compensation Model

Charles Young mentioned, the Compensation is one of the most under-used features of the BizTalk.
[“BizTalk Server 2006: The Compensation Model” ]
If you didn’t read his article, I would strictly recommend it. Next article to read is
[“Transactions and Compensation Using BizTalk Server”]
by Richard Seroter.

There are still many questions in using Compensation in BizTalk.

· What is the proper order of the Exception and Compensating blocks (handlers), Compensate shapes?

· Do we have to rethrow the Exceptions?

· Do we have to use Compensate shape for the current transaction or for the internal transactions?

· What exactly does the Compensate shape?

· What is the difference between Atomic and Long-Running transactions from the Compensation point of view?

Let’s start from the theory.

Compensation and Rollback

I have to use term the Rollback in this document. It is not from the BizTalk Documentation.

Data_1 --> [Transaction: Data_1to2] --> Data_2

I use the Rollback term like the same term in the database transactions. There is a Rollback and rollback, the last is the undefined term and undefined process in BizTalk. The Rollback means restoring all data to the point before transaction. It is completely automatic, atomic process. We cannot control Rollback. Only one operation is possible, Start Rollback. It rolls back only the local orchestration data, orchestration variables and parameters.

The local orchestration data outside the transaction could be only Data_1 or Data_2. When Transaction is Committed, the data is Data_2. When Transaction is Rollbacked, the data automatically returns to the pre-transaction state, to the Data_1. We never get the Data_1to2 outside the Transaction. We all know this; it is ABC of the Transaction model.

But BizTalk is not a data base server as SQL Server and transaction in BizTalk is not a data base transaction. For example the Send shape inside transaction scope can send message to the external system and change data in this system. In general case BizTalk cannot automatically roll back this operation and won’t do this. We have to manually create a code to roll back the external changes. Atomic transaction might change the external system in the same way as Long-Running transaction. BizTalk helps us with managing this roll back procedure. We include the custom roll back code in the Compensation block. This code is invoked automatically by BizTalk or manually by a Compensate shape and the whole process called the Compensation.

Compensation it is not a Rollback. It is another process.

Compensation is a controlled process. Here is a typical example: code inside BizTalk transaction inserts rows in the database. BizTalk does not automatically rollback this operation. But it gives us possibility to implement [maybe] complex business process of deleting inserted rows. Plus, the last uncontrolled step of the Compensation is a Rollback. We implement some custom business process of compensation and then BizTalk invoke Rollback.

All Rollbacks and Compensations are initiated by an Exception. If an Exception is fired inside transaction, BizTalk invokes Rollback, but Compensation for this transaction is usually prohibited.

BizTalk invokes Rollback, but before that BizTalk invokes the Exception block of this transaction, if there is such block and if this block catches the Exception.

Note: Compensation block and Compensation shape are different things. Compensation shape is a method to call the Compensation block.

Atomic and Long-Running transactions

By design Atomic transaction should be used for the fast and simple procedures. The data before Atomic transaction is persisted on the disk, it is not persisted inside transaction regardles of operations inside. Atomic transaction is quick that’s why it does not damage the total reliability. You can mention that Atomic transaction Timeout property by default set up to 60 sec, but not for the Long-Running transaction. Moreover only the Atomic transaction has the Property the Retry because it makes sense to automatically retry only the short process not the long one.

The likelihood of the system crash is bigger in the durations of hours and days than in seconds. That’s why data inside Long-Running transaction persisted to disk. That’s why the orchestration data used in the Long- Running transaction must be serializable. That’s why the Long-Running transaction theoretically slower than Atomic transaction.

Note: Atomic transaction in BizTalk is not atomic in strict sense. It can include requests to the external processes, calls to the .NET classes, etc. Each of these processes could change something outside the orchestration and the transaction Rollback does not automatically roll back all these changes. It would be dangerous.

The Atomic transaction is short by definition. It cannot nest other transactions inside. The Atomic transaction is processed as a single unit of work. If Exception is fired inside the Atomic transaction, all we have to do is to roll back this transaction. And BizTalk makes this automatically. We cannot change this roll back process no matter what sort of Exception was fired.

Seems this is the main difference between n the Atomic and Long-Running transactions in BizTalk, how they behave in case of the internal Exception. Atomic transaction always automatically performs Rollback. We cannot avoid this Rollback and cannot do something else. Long-Running transaction could catch the Exception in the optional Exception block and process additional rollback operations in specific custom code. But the Exception block cannot prevent the automatic Rollback. The Rollback occurs after executing the Exception block. If a Long-Running transaction does not have the Exception blocks it processes an Exception the same way as an Atomic transaction.

Compensations and Exceptions

Rule 1: Transaction block can get only one custom Compensation block.

Rule 2: If the Compensation block is not defined, the Transaction uses the default Compensation. Default Compensation is the Compensation for the current Transaction. That means the unwiring the Compensations for the nested Transactions and Rollback (restoring the Orchestration variables).

Rule 3: Firing an Exception is the only way to initialize the Compensation process.

Rule 4: Atomic transaction block cannot get the Exception block.

Rule 5: Long-Running transaction use the default Exception block for the “General Exception” if the custom Exception block for the “General Exception” is not defined. Default Exception block invokes the Compensation shape for current transaction and rethrow the Exception.

Rule 6: Compensation shape can be inserted only inside Exception block or Compensation blocks.

It seems obvious but anyway…

We can include the Compensate shape nowhere but only in the Exception and Compensation blocks. We cannot start the compensation process arbitrary. No exception – no compensation! Sometimes we need to utilize the automatic compensation ability of the BizTalk in the ordinary business process. Firing Exception is not the ordinary situation; an exception should be always indicator of the error in process. But here we have to use exception, there are no other ways.

Rule 7: Transaction that fired the Exception processes a Rollback right after this Exception. We cannot compensate this transaction.*

*) As Charles Young mentioned here is a workaround for this rule (see the “Using Compensation Blocks on L-R Transactions” topic in his article), but you have to use undocumented features of the BizTalk. BizTalk is wisely trying to prevent compensating uncommitted transaction.

Standard compensation process (Example)

Let’s cover the standard compensation process.

Below is the simple orchestration with one LR nesting transaction (1---) and two nested transactions (11… and 12…).

Second nested transaction fired the Exception.

Let see what is going on here:

1. Code generates the DivideByZeroException

2. The Exception is caught in the Exception block of the same Transaction.

3. The Exception is rethrown.

4. BizTalk rolls back the Transaction, that means it restore the orchestration variables and parameters.

5. The Exception is caught in the Exception block of the nesting, outer Transaction.

6. Calls to the Compensating of the nested Transactions in the revers order. Compensation of the 12… cannot be executed because this transaction was not Committed (completed).

7. Compensating of the 11… Transaction.

8. Exception is rethrown. Orchestration is suspended.

Why the Compensation blocks the Comp12 and Comp 1 were not executed? For different reasons.

Comp12 was not executed because Transaction the 12… was not committed but rollbacked and a try to call the Compensation in the C_Ex 1 block was skiped.

Comp1 was not executed because it could be called only from the outer, nesting transaction. We don’t have such transaction here.

The trace log was:

1 ---

1 --- 11...

1 --- 11... 12... (1)

1 --- 11... 12... >>> Exc 12 (2)

1 --- 11... 12... <<< Exc 12 Rethrow Exception ******** (3) (4)

1 --- 11... >>> C_Ex 1 (5)

1 --- 11... >>> Comp 11 (6)

1 --- 11... <<< Comp 11 (7)

1 --- 11... <<< C_Ex 1 Rethrow Exception ******** (8)

Below is the XLANGs code generated by BizTalk Orchestration Editor:

module GLD.Samples.Compensation

{

internal service longrunning transaction StandardCompensation

{

port implements PortType_1 Control_R;

message System.Xml.XmlDocument msg_XmlDocument;

System.Int32 var_int;

System.String var_State;

body ()

{

activate receive (Control_R.Operation_1, msg_XmlDocument);

var_int = 0;

var_State = "";

scope longrunning transaction tx_1

{

System.Int32 var_IntLevel1;

body

{

var_IntLevel1 = 0;

var_State = "1 --- ";

System.Diagnostics.Trace.WriteLine(var_State);

scope longrunning transaction tx_11

{

body

{

var_State = var_State + "11... ";

System.Diagnostics.Trace.WriteLine(var_State);

}

compensation ()

{

System.Diagnostics.Trace.WriteLine(var_State + " >>> Comp 11");

System.Diagnostics.Trace.WriteLine(var_State + " <<< Comp 11");

}

scope longrunning transaction tx_12

{

body

{

var_State = var_State + "12... ";

System.Diagnostics.Trace.WriteLine(var_State);

// Exception!!!

var_int = var_int / System.Convert.ToInt32("0");

}

exceptions

{

catch

{

System.Diagnostics.Trace.WriteLine(var_State + " >>> C_Ex 12");

System.Diagnostics.Trace.WriteLine(var_State + " <<< C_Ex 12 Rethrow Exception ********");

throw;

}

compensation ()

{

System.Diagnostics.Trace.WriteLine(var_State + " >>> Comp 12");

System.Diagnostics.Trace.WriteLine(var_State + " <<< Comp 12");

}

exceptions

{

catch

{

System.Diagnostics.Trace.WriteLine(var_State + " >>> C_Ex 1");

if (succeeded(tx_12))

{

compensate tx_12 ();

}

if (succeeded(tx_11))

{

compensate tx_11 ();

}

System.Diagnostics.Trace.WriteLine(var_State + " C_Ex 1 Rethrow Exception ******** ");

throw;

}

compensation ()

{

System.Diagnostics.Trace.WriteLine(var_State + " >>> Comp 1");

compensate tx_1 ();

System.Diagnostics.Trace.WriteLine(var_State + " <<< Comp 1");

}

The uncear points in the Compensation Model

To me there are several confusing things in the Compensation model.

First, the Compensation blocks are called outside. Event to call the Compensation comes outside! It is pretty unusual from the developer experience. One more time: the Compensation block is called outside. We are waiting that methods start from the first operator, and the exceptions catch blocks are placed in the end of code. The Exception blocks in the Orchestration are placed as we are waiting for, in the end of the code. Compensation blocks placed in the same place but worked in opposite manner. It is unintuitive. Now the similar graphic presentation of the Exception and Compensation blocks mixed with different behaviour of the Exception and Compensation blocks. It is misleading.

Second, Rollbacks and Compensation are kind of unsynchronized. I will tell about this in the next sample.

Compensation Model process (Example)

Let’s cover the more complex compensation process.

This is the transaction tree:

Below is the orchestration picture. Nesting transaction was implemented in nested loops.

Exception was fired in the 1222 transaction.

The trace log was:

------------------------------- 5 ----------------------------

1000***

1000*** 1100===

1000*** 1100=== 1110---

1000*** 1100=== 1110--- 1111...

1000*** 1100=== 1110--- 1111... 1112...

1000*** 1100=== 1110--- 1111... 1112... 1120---

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121...

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122...

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200===

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210---

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211...

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212...

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... 1220---

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... 1220--- 1221...

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... 1220--- 1221... 1222...

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... 1220--- 1221... 1222... ******* Throw exception(1)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... 1220--- 1221... >>> C_Ex 3(2)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... 1220--- 1221... >>> Comp 4(3)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... 1220--- 1221... <<< Comp 4(4)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... 1220--- 1221... <<< C_Ex 3 ******* ReThrow exception(5)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... >>> C_Ex 2(6)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... >>> Comp 3(7)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... >>>Comp 4(8)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... <<< Comp 4(9)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... >>> Comp 4(10)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... <<< Comp 4 (11)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... <<<Comp 3(12)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... 1200=== 1210--- 1211... 1212... <<< C_Ex 2 ******* ReThrow exception(13)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... >>> C_Ex 1(14)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... >>> Comp 2(15)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... >>> Comp 3(16)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... >>> Comp 4(17)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... <<< Comp 4(18)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... >>> Comp 4(19)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... <<< Comp 4(20)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... <<< Comp 3(21)

1000*** 1100=== 1110--- 1111... 1112... >>> Comp 3(22)

1000*** 1100=== 1110--- 1111... 1112... >>> Comp 4(23)

1000*** 1100=== 1110--- 1111... 1112... <<< Comp 4(24)

1000*** 1100=== 1110--- 1111... >>> Comp 4(25)

1000*** 1100=== 1110--- 1111... <<< Comp 4(26)

1000*** 1100=== 1110--- 1111... 1112... <<< Comp 3(27)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... <<< Comp 2(28)

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122... <<< C_Ex 1(29)

.......................................................................

1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122...

Picture of whole compensation process:

As an initial exception (1) is fired, there are several stages in the compensation process. A catch block follows after each exception, then compensations (blue arrow) and rollbacks (green arrow) for nested transaction(s). Each compensation is followed by a rollback with nested compensations and rollbacks in between.

For example, an Exception (5) in the Catch Exception block the “C_Ex 3” of the transaction 1220 is caught into the Catch Exception block (6) of the Transaction 1200, then follows the Compensation “Comp3” for the Transaction 1210 (7), the Compensation (8) and the Rollback (9) for the Transaction 1212, the Compensation (10) and the Rollback (11) for the Transaction 1211, the Rollback (12) for the Transaction 1210.

You can mention one interesting detail in the whole compensation process: All compensation blocks were called and all compensation code inside was invoked. But the orchestration data was not returned to the initial state. The orchestration data was roll backed only for the transaction branch where exceptions were fired, for the transaction 1200 and nested transactions. We could predict the roll backed data would be the “” but it is “1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122...”

Is it a bug in BizTalk?

Seems the compensation process is tuned up only for the “default” compensation model for some reason. In this model each implicit Exception block is finished by a Throw Exception operator. As you can remember the Default Exception block invokes the Compensation shape with current transaction and rethrow an initial Exception. If we follow this model we have got a predictable rollback process.

In the preceding example we have to nest the Transaction 1000 in outer Transaction and add a Throw Exception operator in “C-Ex 1” Exception block. In this case the data would be roll backed to the “” value in this outer transaction.

Rule 7: The orchestration data is roll backed to the initial point of the transaction where the last exception is rethrown.

For example, the last exception was rethrown in the Transaction 1200. The initial data for this Transaction was “1000*** 1100=== 1110--- 1111... 1112... 1120--- 1121... 1122...”. The orchestration data was roll backed to this value, not to the initial data for the outer compensated Transaction 1000.

Conclusion

Let’s summarize how to create the standard compensation process.

1. Define the Compensation blocks for all transaction you want to be compensated. This is the most chalenging task.

2. Define the Exception blocks where the Exception(s) should be cought.

3. Add the Compensate shape(s) to this Exception block. Define what transaction you want to compensate. The standard way is to define a current transaction. All nested transactions would be compensated automaticaly in the right order.

4. If you need a predictable rollback process for the orchestration data, rethrow an Exception in each Exception block where you added the Compensate shape.

BizTalk: xpath: How to work with empty and Null elements in Orchestration

Leonid Ganeline — Tue, 17 Nov 2009 23:55:12 GMT

The problem is with three Empty-Null cases.

Is it possible to separate all these cases in Expression shapes of the Orchestration?

For example, we have the record with <name> element, in such flawors:

case: "NonEmpty"

<ns0:People>
<ns0:Name>Name_0</ns0:Name>
<ns0:IsDependent>IsDependent_0</ns0:IsDependent>
..

case: "Empty"

  <ns0:People>
    <ns0:Name></ns0:Name>
    <ns0:IsDependent>IsDependent_0</ns0:IsDependent>
..

case: "OneTag"

<ns0:People>
<ns0:Name/>
<ns0:IsDependent>IsDependent_0</ns0:IsDependent>
..

case: "Null"

<ns0:People>

<ns0:IsDependent>IsDependent_0</ns0:IsDependent>
..

Is it possible to separate all these cases in Expression shapes of the Orchestration?

There is no information into the MSDN about this [http://msdn.microsoft.com/en-us/library/aa561906(BTS.10).aspx]

I tried to use the xpath() function in two variants, one with "string(xpath_expression)" second with "xpath_expression"

Expression Shape:

[

System.Diagnostics.Trace.WriteLine("== with string() ====================================================================");

var_xpathString = "string(/*[local-name()='Root' and namespace-uri()='http://MapTest.IncPerson']/*[local-name()='People' and namespace-uri()='http://MapTest.IncPerson']/*[local-name()='Name' and namespace-uri()='http://MapTest.IncPerson'])";

System.Diagnostics.Trace.WriteLine("[" + System.Convert.ToString(xpath (msg_SourceRoot, var_xpathString)) + "]");

if ( xpath (msg_SourceRoot, var_xpathString) == null)
{ System.Diagnostics.Trace.WriteLine("Name == null"); }

else if ( xpath (msg_SourceRoot, var_xpathString) == "")
{ System.Diagnostics.Trace.WriteLine("Name == Empty");}

else
{ System.Diagnostics.Trace.WriteLine("Name != null && Name != Empty"); }

System.Diagnostics.Trace.WriteLine("-- no string() --------------------------------------------------------------------");
var_xpathString = "/*[local-name()='Root' and namespace-uri()='http://MapTest.IncPerson']/*[local-name()='People' and namespace-uri()='http://MapTest.IncPerson']/*[local-name()='Name' and namespace-uri()='http://MapTest.IncPerson']";

System.Diagnostics.Trace.WriteLine("[" + System.Convert.ToString(xpath (msg_SourceRoot, var_xpathString)) + "]");

if ( xpath (msg_SourceRoot, var_xpathString) == null)
{ System.Diagnostics.Trace.WriteLine("Name == null"); }

else if ( xpath (msg_SourceRoot, var_xpathString) == "")
{ System.Diagnostics.Trace.WriteLine("Name == Empty"); }

else
{ System.Diagnostics.Trace.WriteLine("Name != null && Name != Empty");}

]

I.e. the "string(xpath_expression)" expression is used in the firs section, the"xpath_expression" is used in the second.

Result is:

"NonEmpty" == with string() ====================================================================
[Name_0]
Name != null && Name != Empty
-- no string() --------------------------------------------------------------------
[Microsoft.XLANGs.Core.Part+ArrayBasedXmlNodeList]
Name != null && Name != Empty

"Empty"== with string() ====================================================================
[]
Name == Empty
-- no string() --------------------------------------------------------------------
[Microsoft.XLANGs.Core.Part+ArrayBasedXmlNodeList]
Name != null && Name != Empty

"OneTag"== with string() ====================================================================
[]
Name == Empty
-- no string() --------------------------------------------------------------------
[Microsoft.XLANGs.Core.Part+ArrayBasedXmlNodeList]
Name != null && Name != Empty

"Null"== with string() ====================================================================
[]
Name == Empty
-- no string() --------------------------------------------------------------------
[]
Name == null

Conclusion:

* I cannot separate the cases "Empty" and "OneTag"

* I can separate the cases "Empty and "Null" with "xpath_expression", not with "string(xpath_expression)" expression
* "Null" case does not throw an exception.
* xpath expression inside string() works fine to get all three cases ("Empty", "OneTag", "Null") under one "if" statement. And here it returns only "" (Empty string).