How reliable is your system?

There is no point in building an unreliable system however building resiliency into your system and environment only reduces the potential for failure, it does not eliminate it.

With user driven systems this is not so much an issue. If the system fails, the user can check to see if the system has been updated and continue working.

With computer driven mass processing systems problems tend to be multiplied by the rate at which the system works. Therefore a timely resolution to a failure may be impossible.

It is therefore essential for computer driven systems to have a means of recovering from a failure in a timely manner.

Without the recovery processes your system may not be as reliable as you may think.

Why is idempotence so important?

Every enterprise system has some operations that need to occur only once.

Typically transactions are used to guarantee only once processing. Although transactions work well inside applications they don't work so well when connecting systems together.

Distributed transactions do guarantee only once processing given infinite time, however during this time resources are often locked and this may cause the applications to become unusable.

The use of transactions to guarantee only once processing between connected systems is therefore not practical, but building an unreliable system is senseless so we need an alternative.

Without transactions the best we can do is ensure a message will be delivered at least once. If we need to ensure only once processing, we need to make sure the target system won't duplicate the work if it receives duplicate messages.

In other words, we need the target system to be idempotent.

BizTalk Filename Macros

%datetime%
Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).

%datetime_bts2000%
UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).

%datetime.tz%
Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).

%DestinationParty%
Name of the destination party. The value comes from message the context property BTS.DestinationParty.

%DestinationPartyID%
Identifier of the destination party (GUID). The value comes from the message context property BTS.DestinationPartyID.

%DestinationPartyQualifier%
Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier.

%MessageID%
Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.

%SourceFileName%
Name of the file from where the File adapter read the message. The file name includes extension and excludes the file path, for example, foo.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value, for example, if message was received on an adapter other than File adapter, then the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%).

%SourceParty%
Name of the source party from which the File adapter received the message.

%SourcePartyID%
Identifier of the source party (GUID). The value comes from the message context property BTS.SourcePartyID.

%SourcePartyQualifier%
Qualifier of the source party from which the File adapter received the message.

%time%
UTC time in the format hhmmss.

%time.tz%
Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).