The benefits of evolutionary design

Creating a well-planned design can be very difficult. Well-planned designs are often over-engineered. This means that a design can be flexible in areas that didn't need flexibility and inflexible in areas that did need it.

With evolutionary design, the design evolves slowly over the course of the development. You begin by coding a small amount of functionality, adding more functionality, and letting the design shift and shape.

Refactoring is an important part of this evolutionary design process. Design improvements are made whenever your code needs them. By having both unit tests and a disciplined technique of refactoring on top of the tests, changes can be made quickly and without introducing defects.

The key benefit to evolutionary design over a well-planned design is that you reduce the amount of work you over- or under-engineer. This in turn leads to an increase in team productivity.

Are you over-engineering your code?

Over-engineering is when you make your code more flexible or sophisticated than it needs to be.

It is not uncommon for many architects and programmers to add unnecessary flexibility and complexity to their designs because they believe they know their system's future requirements.

The problem with attempting to predict the needs of tomorrow is that often these predictions do not materialise.

The result is a code base that is larger and more complicated than it needs to be and this contributes to a decline in team productivity.

BizTalk Dynamic Adapter Protocol Aliases

Adapter	Protocol Alias
FILE	file://
FTP	ftp://
HTTP*	http:// or https://
MQSeries	MQS://
MSMQ	MSMQ://
MSMQT	Direct=
SMTP	mailto://
SQL	sql://
SOAP	soap://
WCF-BasicHttp*	http:// or https://
WCF-Custom	wcf://
WCF-WSHttp*	http:// or https://
WCF-NetMsmq	net.msmq://
WCF-NetTcp	net.tcp://
WCF-NetNamedPipes	net.pipe://
Windows SharePoint Services	WSS://

*If the address starts with http:// or https://, and if you do not specify the Microsoft.XLANGs.BaseTypes.TransportType field, by default, the BizTalk engine will use the HTTP adapter.

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).