Passed exam 70-235

Victory Is Mine!!!
Today I successfully passed the exam 70-235 meaning that from now on I can call myself technical specialist in:
Developing Business Process and Integration Solutions by Using Microsoft BizTalk Server 2006

Next one will be exam: 70-241
Developing Business Process and Integration Solutions by Using Microsoft  BizTalk  Server  2006 R2

Let BizTalk automatically send a WCF Response message on delivery without the use of orchestrations.

Recently I faced the challenge of returning a delivery acknowledgement message to an WCF service when it shoots a new message in our BizTalk environment. All this needs to be done using “context based routing”, in other words, without the use of an orchestration. Main reason for this is the extra performance overhead you get using orchestrations.

To sum it all up, our goal for today is:

• DON’T USE ORCHESTRATIONS!
• Send a dummy message to the WCF service.
• Wait for the message to be placed into the BizTalk messagebox.
• Receive an acknowledgement that the message is indeed accepted by BizTalk.

After some “intelli searching” on the web I came across this article of Daniel Probert. In this article he shares his vision on the problem at hand. Being a total newby in BizTalk world his explanation was a bit mindboggling for me. After a couple of hours playing with the concept I manage to recreated his concept to the point I actually understood what was going on beneath the shiny surface.

It all has to do with a “magical” subscription that will be created on the fly by BizTalk when the receive-port receives a new message. But first things first!

To be able to send messages to BizTalk using a webservice we can use the “BizTalk WCF Service Publishing Wizard”. This Wizard will guide you thru the process of setting up your Webservice and “connecting” it to your BizTalk application, resulting in a newly created “receive port / location” in your BizTalk Application. This newly created port is by default a Two Way receive port, meaning it can talk both ways (Request/ Response). Exactly what I wished for… NOT!

The problem lies is the response handling, when BizTalk receives a new incoming message it will try to deliver it to its subscribers and.. that’s about it…. There’s no build-in response system! So what you will experience using the Web-service is a time-out (lack of response) on you WCF request.

Back to the “magical” subscription part… every time BizTalk accepts a message from a two way port it automatically creates a new subscription for its “response” port subscribing it to ALL messages containing the following promoted properties:

• EpmRRCorrelationToken == {*****}
• RouteDirectToTP == True

Sadly these properties can’t be promoted the usual way since they are some sort of special system properties. To accomplish the impossible we will have to create a custom pipeline that will do exactly that for us. And that’s exactly what I did, using a little code snippet from Daniel.

After using this custom pipeline as your “Receive Pipeline” BizTalk will send back a copy of the incoming message as an acknowledgement to the initial WCF request.

Yeah! No more timeout’s, problem solved!
Installer: Windows Installer File (MSI)
Sourcecode: CodePlex
Documentation: Word Document

Getting a SharePoint Feature GUID, the easy way!

Today my colleague Waldek pointed me to an interesting way to find out the "GUID" of a SharePoint Feature.
Only prerequisite is that you have installed the Internet Explorer Developer Toolbar
Go to your feature page "Site Settings > Site Features" or more directly go to /_layouts/ManageFeatures.aspx?Scope=Site
Here you will find the list of deployed features.
Now choose "Select Element by Click" en select the "Activate" of "Deactivate" button of your feature.




Now you can see the "GUID" in the elements window

I'm in love, her name is MSBuild.

A colleague of me pointed out that there are several stages of emotion when developing SharePoint. Ignorance, Anger, and finally Acceptance. This makes you wonder… Why the anger?
So after experience them all, I found out that the default SharePoint Development workstation provided by Microsoft (Visual Studio in combination with MOSS) was lacking, how should I bring this… Completeness! Every developer in town will automatically say, is there any software that truly complete, well have to acknowledge that I haven’t found any in my lifetime, but the search continues. What I want to point out is that there is a LOT of room in SharePoint Development for tooling. A great resource for all sorts of tooling that will make life easier you can find at http://www.sharepointblogs.com/ But we are drifting a bit off topic here. One of the main thing’s that made me angry was the seemingly endless repeating of steps needed while developing in SharePoint. Creating a simple WebPart will take a lot of steps I can tell you (all those xml files, you know what I mean).

A little less angry…
First thing a developer will say when they are confronted with repeating steps, lets automate the process as much as possible.
Here is where I met the powerful build system Microsoft provides called: MSBuild.
For example, lets look at the developing process of a WebPart.

• You will startup Visual Studio and begin to write your code and create an .webpart file (or previously an .dwp file)
• You will then create the necessary feature structure required for creating an WSP file.
• You will create the WSP file using the command MakeCab.exe
• You will deploy and publish this feature to your website using the command STSADM.exe
• You will activate and try the newly installed feature.

This process (or something similar, like (un)registering your DLL in the GAC for instance) will be used a lot of times during development. Previously we were using batch files for automating our solutions as much as possible.
But now that we have discovered MSBuild targets we are in the process of getting rid of these batch files and replace them with .target files.
There are a couple of reasons why I think you should consider using this feature:

• More control, There is a tight integration between Visual Studio and MSBuild providing us with more control over what when happens based on al sort’s of states of your project.
• Reusability, given the fact that MSBuild has tight integration it will give you the power of create more flexible scripts, thereby giving you a more reusable solution.
• Cleaner, A lot of “plumbing” is done behind the scene therefore making your solution cleaner. output of the scripts will be displayed in the output window within Visual Studio instead of separate log files for example (although that’s definitely still one of the possibility’s)
• Intellisense, I will not go into this deeper than necessary, Most likely you know what Intellisense can do for you, less code errors due to human type errors ect. ect.

Drawback’s:
So, is this MSBuild your answer to all your developing questions?
Definitely not! On the contrarily, there are some little “problems” with using this.

• Changing any target files (read: script files) require you to reload your solution. This is because the imported target files will only be evaluated during loading of the projectfile.
  This is mainly a problem when you are creating new template’s and need to change the target files a lot.
• Although using MSBuild instead of Batch Files is more clean, this “behind the scene’s plumbing” can make the whole process less transparent. So here come in the reason that you always need to communicate (read: create documentation) about what's is happening during the process. I myself find it very useful to use the output windows for showing what is happening in the MSBuild process.

How to use it:
So, now that you have read the benefit's and drawback's you may find yourself questioning, can this MSBuild target thing do something for me, and where do i start exploring?
Well,  just Google "MSBuild Target" you will find a lot of in depth information about how to do the magic. In this post I will explain my conceptual point of view which I used for my recently created template. The template will consist of a couple of xml based files, all sharing the extension .target

Here's my concept:

\SolutionDir\MSBuild\
    Imtech.Common.Import.targets
    Imtech.Common.Properties.targets
    Imtech.Common.Targets.targets
    Imtech.Common.Tasks.targets

\SolutionDir\ProjectDir\MSBuild\
    Imtech.Project.Properties.targets
    Imtech.Project.Targets.targets
    Imtech.Project.Tasks.targets

I will break these file's up into pieces for you
As you can see in the used naming convention there are really only 4 thinks to explain here namely: Import, Properties, Targets and Tasks (except from the fact that I used 2 different folders to put these files in, but more about that later on).

• *.Import.targets
  This is the file that will connect all the other file's in the right order and an reference to this file will be placed in your .proj file.
  
• *.Properties.targets
  In these file's you will define you "dynamic" properties.
  for example, the path of your local IIS folder or the location of your STSADM.EXE tool.
• *.Targets.targets
  These file's will be your "coordinator", and will provide you with the possibility to enforce logic based on the selected "Solution Configuration" and properties you defined in the Properties.targets. It will call tasks defined in your Task.target files based upon the implemented logic.
  In other words: this will be your router (I used to be a network engineer, and sometimes still think in terms of networks)
• *.Tasks.target
  In these file's you will find separate pieces of functionality that will be referenced in your Targets.target file.
  Here you will define the actual commands that will be executed and name/group them using some sort of logical convention.
  

So now that we have covered the difference's between the file's I will explain the 2 folders I used. Earlier I explain that one of the benefits of using MSBuild targets is that it's reusable. This means that in a new project, I can use the same template as I used before. In order to do this, you have to separate any execution logic from your project dependency's. This is where the properties target file kick's into place. In the properties you will define all your project dependant things. And because you probably have more than one project in your solution you have to deal with some "global" and some "local" dependencies. That's why I used 2 folder's, one where you can declare your globally used targets, task and properties an one folder where you can (re)define these properties, or even extend your targets and tasks.

If needed I will post some sample's of the target files we use.
As always, if you have some comment, don't hesitate to... comment!

Silverlight and SharePoint, a beautiful marriage?

So after almost 2 months of silence I decided it’s time for some new postings. As you may know by now, I have been very busy with Sharepoint the last couple of months. Currently I’m creating a whole new Internet facing website as requested by my boss. Work is progressing, ok not that very fast, I’m still learning more of the sometimes mystical world of SharePoint every day (didn’t I use the word mystical in a previous post, well the word has its purpose, believe me).

So without any further ado, I created a SharePoint WebPart that will show an entire Picture Library in the form of a SilverLight slideshow. The WebPart is mainly based on a project called Silverlight Slideshow initiated by Koen Zwikstra from Firstfloorsoftware.com All I had to do add a little functionality and wrap the whole package into an WSP.
First problem I had to tackle was the logic needed to retrieve information from an SharePoint Picture Library and somehow inject this info into the slideshow.
The original program uses an XML file as its main source of information, making the world a little better place for me ;-)
I created a nice Handler that will do this for me and present the found information in a way the slideshow will “swallow”.
This handler will create the XML based on 3 properties of the library (Image, Thumbnail and Title).
By default there are a lot of configurable properties build into this great SilverLight control. I wrapped all these properties into the WebPart public properties, giving you the great power of controlling the presentation of the control without leaving your SharePoint GUI.
For example, you can turn on/off the buttons, thumbnail, tracker of just change the colors used to render it.
Ok well, how does this thing work in real life then….

All you have to do is:
1. Deploy the WSP to your Sharepoint site.
2. Activate the newly deployed feature in your Site Settings
  
3. Add the WebPart to your site.

4. Select the Picture Library for your image resource
5. Change the properties of the WebPart to reflect your inner desires.
 
Volia, a fully functional slideshow on your page!
So, where can I download it you might wondering…
Before sharing the code with the community, I first have to check with the original creator of the Silverlight control and see if he’s ok with me releasing this as a WebPart.
For now you will have to do with a screenshot of the WebPart in action.

My first SharePoint webpart

A few months ago I created my first SharePoint webpart.
The conceptual idea was to have a webpart where items from the contenttype calendar would be aggregated and displayed to the enduser in the form of an eventlist.
Something like:

When the users clicks on an item, a new page would be displayed with more information about the selected event.
Something like:


1st step in creating this WebPart was to find out what components are involved.
So the WebPart will do the following basic steps every time it is viewed.
1. Get all the listitems (based on a public property's "SiteName" and "ListName" )
2. Sort the listitems
3. Cut the list to the appropriate size (based on a public property "NumberOfEvents")
4. Transform the list to an appropriate XML representation
5. Transform the XML representation by using a XLS (based on a public property "XSL")
6. Additionally if an event happens in the future, add a link to an InfoPath form where the user can subscribe to the upcoming event. This form will be forwarded by email.

Next time I will post some short pieces of code.
For now I just send you to this great resource on how to build your own WebPart for SharePoint

Regular expression? No Wiener Melange for me please....

This is what most of us will say when we hear the term "Regular expression". No it's not a brand new coffee brand, no it isn't the most common used (and therefore regular) facial expression of the world. No this time I'm talking about some sort of query language used by freaky developers. Recently my program experience is expanding (fast or slow, it IS expanding) and from time to time I literally bounce of a new subject.
Regular expressions is just one of them.
The concept really is fascinating!
These expressions can do almost anything, except make you a delicious Wiener Melange (on the other hand, could your coffee machine make one for you "without" regular expressions? that the question!).
Well jokes aside, I really was fascinated by the concept and couldn't resist taking a little sneak preview in this crazy world of expressions.
An there come's the "bounce"...
Really, can anyone tell me what the hack this means???

^((?>[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+\x20*|"((?=[\x01-
\x7f])[^"\\]|\\[\x01-\x7f])*"\x20*)*(?<angle><))?((?!
\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+)+|"((?=[\x01-
\x7f])[^"\\]|\\[\x01-\x7f])*")@(((?!-)[a-zA-Z\d\-]+(?
<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<!\[)\.)(25[0-5]|2[0-4]\d|
[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-
\x7f])[^\\\[\]]|\\[\x01-\x7f])+)\])(?(angle)>)$

Well, if you break it down piece by piece you will eventually see some logic in the above syntax. To safe you all some backtracking time, here is the answer: The above syntax can be used for validating the syntax of an email address. Well, for me this isn't that logical. From a conceptual point of view these sort of expression can have tremendous power and can be used in very complex situations like pattern recognition. For now I say: Back to the schoolbooks, we've got a lot to learn!