Review: Applied Architecture Patterns on the Microsoft Platform

15 November 2010

 

Recently the book ‘Applied Architecture Patterns on the Microsoft Platform’ was released. The book is written by Richard Seroter, Stephen Thomas, Ewan Fairweather, Mike Sexton and Rama Ramani. Yossi Dahan is the technical reviewer. The book is published by Packt Publishing.

Shortly before the book was released, an event was held in Stockholm, Sweden. I was lucky enough to be able to attend. Three of the authors (Richard, Stephen and Ewan) did two long days of presentations. In the humorous and spirited presentations the chapters in the book were discussed accompanied by nice live demos.

I was already interested in this book because these authors are respected and known worldwide as BizTalk and Microsoft experts. After attending the event I was even more interested in reading the book.

A couple of weeks after the event I was contacted by the publisher. They asked me to read the book and write a review on my blog site. Below is my review:

During the last few years the Microsoft platform has evolved in two directions. Extension and enhancement of existing technologies and products has of course continued. A couple of new technologies and products including Windows AppFabric, Windows Azure AppFabric, and StreamInsight have been added to the stack. Architects have the important task of picking the right technology for their specific problem at hand from the broad landscape of technologies and products. Picking the right technology for a new project can be very challenging due to the number of architectural decisions that must be made. Wrong choices in this area can lead to big problems and high costs for companies.

How to pick the right technology or product from the Microsoft stack is exactly what this book is about. It must be said that the book does not try to be the ultimate reference guide with the right pointer for each possible scenario. Instead it equips the reader with the knowledge to decide which technical architecture is most appropriate.

The book can be roughly divided into three parts. The first part (chapter 1) creates an architectural decision framework. The decision framework is one of the tools used in the process of translating requirements into technical solutions.

The second part (chapters 2 through chapter 6) compromises the technology primers. The primers are an introduction to technologies and products used in the book. For each primer, typical use cases are described. There is also a sample solution included for each primer.

The third and final part (chapter 7 to chapter 19) contains the elaboration of a couple of fictitious cases. First, a company with a specific IT problem is introduced. Next, the decision framework from the first chapter is used to determine the best fitting architecture for the IT problem. Finally, the case is implemented in a downloadable sample solution.

In my view, books about architecture tend to be boring and hard to read. This book is absolutely not the case; I really enjoyed reading it. This book fills a gap in the Microsoft architecture guidance.

My favorite things about the book are:

· It provides a broad overview of the Microsoft product and technology stack. Newer technologies like Windows AppFabric and StreamInsight are included.

· The decision framework provides a useful tool for real world scenarios and helps in the design process of translating requirements into software.

· The extensive set of cases (12 chapters) is the main part of the book. It provides architectural information and reusable code that can be used as a starting point for real world scenarios.

This book is a must have for every Microsoft architect and developer.


Setting the filename in send port (post number:1023054)

2 November 2010

This is probably the most blogged topic in the BizTalk community but I hope my attempt still adds something.

Let’s start with some simple questions:

Question1:
What syntax do you need to use to access the filename of a message you received using the file adapter in an orchestration?

In an expression shape you use something like this:

myVariable = myMessage(File.ReceivedFileName);

Question 2:
Ok, that one was easy! Now the same question for the a message received using the FTP adapter?

Again in an expression shape use:

myVariable = myMessage(FTP.ReceivedFileName);

Question 3:
Ok, makes sense. So what do you need to do when you wan to set the filename for a message that you send out using the file adapter?

Easy, two steps needed:

1). Set the filename property in the send port to use the macro %SourceFileName%.
2). Set the context property in the orchestration to the filename you want to use, like this:

myMessage(FILE.ReceivedFileName) = “MyFileName.xml”;

The file adapter will replace the macro with the value of the context property.

Question 4:
Last question; Same question for the FTP adapter. How do you set the filename for a message that you want to send out using the ftp adapter?

myMessage(FTP.ReceivedFileName) = “MyFtpFileName.xml”;

Wrong!!!!!!!! you also need to use the same syntax as with the file adapter:

myMessage(FILE.ReceivedFileName) = “MyFtpFileName.xml”;

This is something I encountered during development last week. I think this is a little confusing. It took me a while to find out what happened here. Also, by searching the internet, if found out this seems to confuse more people.

I think the idea behind this is an attempt to make an orchestration adapter agnostic and to create an abstraction layer between the logical process (orchestration) and the adapters which are bound to a certain technology or protocol. So whether you use the file or FTP adapter it is always ‘FILE.ReceivedFileName’ you need to use. This idea is good but my remarks are:

- This works different for receive side which makes it a little inconsistent.
- The word ‘FILE’ is (at least in my head) directly connected to the file adapter. The abstraction would be more clear if some other term was used.

Confusing!


Artikel over BizTalk en PowerShell

2 November 2010

nederlandse-vlag

Dick Dijkstra en ik hebben een artikel geschreven over BizTalk en PowerShell. Het artikel is recent gepubliceerd in de gedrukte versie van TechNet magazine.

Het artikel is helaas nog niet online beschikbaar.

 

Note to international readers of my blog:
The above post is aimed at the Dutch community and therefor only published in Dutch language. Unless you want to learn Dutch you can safely ignore it (I realize that is probably true for all my posts). Smile


Monitor BizTalk Server Job in BizTalk 2010

19 October 2010

When looking a the new features of BizTalk 2010 I noticed that the set of SQL Server Agent jobs has been extended. There is new job called ‘Monitor BizTalk Server’.

new sql job

This job is especially good news for those of us responsible for keeping BizTalk Server running and healthy.

The general idea behind the job is to check for errors and report that those errors exist in one of the message box databases, the management or the tracking database. A zombie message is an example of an error that will be detected. For a complete list of all the issues see the BizTalk 2010 help on this topic

The job consists of two steps. The first step is responsible for collecting error data from the different message box databases, the management database and the tracking database. The second step checks the collected data and raises an error if there is an issue in of the databases.

job steps

If any inconsistencies are found the job will fail and will write an error to the application event log. You can easily extend this by configuring other notifications for the job like e-mail, etc.

job notification

The job does not fix any issues it is just provides an alert mechanism. You can other tools like the BizTalk administration Console to fix any issues found.

When running the job on a healthy BizTalk server environment, the job succeeds:

job success

Now I use the following non uniform sequential convoy orchestration to generate a zombie message:

orchestration

I can easily do this by throwing in message 2 (destination receive shape 2) multiple times. The orchestration is only expecting one instance of message 2 which will lead to a zombie message. In the admin console this looks like this:

admin console error

When running the job the second time I now see the following result:

job outcome error

The job history gives me more detailed information of what is wrong:

error job history

This information is also in the event log:

eventlog error

Some final considerations:

  1. By default the job is scheduled to run once a week. You can of course change this schedule if you like.
  2. This seems to be a heavy job in terms of SQL resource usage. Microsoft recommends to run the job during low traffic.
  3. The will not detect if issues have already been reported. When the job runs for the second time and the issues have not been fixed they will be reported again.

I think this is a useful new feature in BizTalk Server 2010. I have seen many clients where issues in the BizTalk databases where not noticed for a long time.


Replacing functoids in BizTalk 2009

19 October 2010

A BizTalk developer recently learned me a great trick to replace funtoids in a map. It looks like a lot of BizTalkers, like me, are unaware of this handy feature.

When you accidentally used the wrong functoid in a map you can replace it by just dragging another functoid on top of it. The old functoid is replaced with the new one. The great part is that all the input and output parameters of the functoid are preserved.

The following video shows how to do this in BizTalk 2009:

BizTalk 2009 Mapper replacing functoids

I haven’t tried but this should also work in BizTalk 2006 (R2). I don’t know about BizTalk 2004.

When trying in BizTalk 2010 I was a little bit surprised to find out that this does not work. See video below:

BizTalk 2010 Mapper replacing functoids does not work

Fortunately there are many other productivity enhancements in the BizTalk 2010 mapper so I think I can live without this replace feature Smile.


Follow

Get every new post delivered to your Inbox.