SharePoint Community Center

Summer is just around the corner, and it’s time to hit the local Parks and Rec room to shoot some stick pool and play ping pong and… configure (your choice) SharePoint Portal Server 2003 or SharePoint Server 2007 Beta 2.  Beta 2 will release to the public in a few weeks (less?), and all of your friends will be working with it before you know it.  You can meet up with them at the newly launched/refreshed SharePoint Community Center page here: http://www.microsoft.com/sharepoint/community.mspx.  See you online…

ESB Adoption: lighting the road ahead

When building an infrastructure-type system like an ESB, often the architects and developers tend to naturally focus on the technical challenges. Ultimately, they reach a point where the code is done, functionality is complete, all unit tests pass, and everything has been deployed into production. Then an email goes out letting everyone know that the project goals have been met. We’re done, right?


Most of the time, I would say no, we are not done. Infrastructure services generally are not a case of “if you build it they will come”? Maybe, but not likely. Developers are creatures of habit. They get used to doing something a certain way, and stick to it. When deploying something like an ESB, you need to educate them. You’re deploying powerful capabilities, but the team needs to understand the implications and benefits in order to ensure adoption. With adoption, organizational benefits will be realized. Without adoption, you’ve just wasted a lot of effort.


For the project I am on, as part of our rollout, we are doing “brown bags” where people can learn about what the ESB is, and what it means to them and their applications. This is a great start and a great way to “socialize” the technology, and raise organizational awareness of infrastructure services.


However, I felt the need to provide developers with something more, something that would guide them and ease their adoption of ESB capabilities. Something that would continue on after I rolled off the project. It was this thinking that lead to the Core Engine SDK.


The Core Engine SDK will consist of:


– a naming conventions document
– sample programs
– a “Developer’s Guide to the ESB Core Engine” (more details later in this post)


Naming Conventions: what’s in a name?
Experienced BizTalk developers do all their work in virtual machines. In that isolated world, it doesn’t matter what you name things, if there are collisions or conflicts you’ll be able to figure them out. You’re likely only working with a small amount of artifacts. However, once you deploy into staging/production environments, your solution enters into a shared environment. In a large organization with a lot of BizTalk artifacts, a structured naming convention is required in order to ease management of the environments. Without one, chaos will ensue.


So, I created a naming conventions document that is based on best practices gleaned from past projects and other projects done by people I know. The resulting naming conventions document something that developers need to follow. In fact, although it may seem draconian, they MUST adhere to it or their application will not get deployed. Compliance to the naming conventions is a key part of the “on-boarding process” we will be implementing. I will do a future post on what I see this process as being.


Samples: show me how it’s done
The sample programs are examples of how the ESB Core Engine capabilities may be used in a solution. Knowing that the target audience will be BizTalk developers, these samples will follow the model of the BizTalk SDK in that they will have setup/cleanup batch files to quickly get a sample running, and to quickly remove it. We are creating a business scenario that will be used across all the samples, the idea being we want a readily understood business-specific scenario so developers don’t waste cycles trying to grasp some made-up business need, and focus instead on the techniques being shown. Our goal is that the samples will be very function-focused, each sample will address one (and where possible only one) aspect of something an application may need to do with the ESB.


As an example, I am writing “The Ultimate Handler for ESB Exceptions” (future post coming here, it is sooooo cool), but the first SDK sample will be how to write a highly targeted exception handler. This will show developers how they can incorporate our exception handling mechanism into their applications.


The Developer’s Guide: tell me what I need to know.
A project the scope of the ESB I am on will of course generate a bazillion documents and diagrams. However, in my opinion, one of the key documents, and in fact one of the keys to the success of the whole project, is the document I created for the developers and architects charged with building applications that will run on the ESB. I can’t post the document (of course!), but I thought posting the table of contents would at least show the sections that I felt it was important to address. This is not documentation for the ESB itself, that’s a whole other document aimed at developers who will be maintaining and extending the ESB. This documentation is targeted at the *users* (developers) of the ESB.


In the following listing, I have replaced the client’s name with “xxxxx”. I have left page numbers in so you get a sense of depth.


Introduction 4
– Overview 4
– Target Audience 4
– Revision History 4
Introduction to the xxxxx ESB 5
– What is it? 5
Introduction to the ESB Core Engine 6
– What is it? 6
– How is it architected? 6
– How should you architect your BizTalk solutions? 7
Working with the Iteration 1 xxxxx ESB Core Engine 8
– Functionality Provided 8
– Scenarios 9
Getting Started with the Core Engine 11
– How it works 11
– Installing the ESB in your virtual machine 11
– Installing the CtxSetGeneric Pipeline Component 12
– Installing the JMS Pipeline Components 13
Developing BizTalk Solutions with the Core Engine 14
– Naming Conventions and Rules 14
– The ESB On-Ramp: Receiving and Creating Messages for ESB Processing 14
— Using the CtxSetGeneric Pipeline Component 15
— Using a Property Schema 15
— Getting access to ESB Metadata Properties by Assembly Reference 17
– The ESB Off-Ramp: Creating Subscribers 19
– Working with JMS Messages over MQ Series 21
Dynamic Mapping 23
– Overview 23
– Order of Selection 23
– Dynamic Mapping Errors 23
Exception Handling 24
– Overview 24
– Core Engine Exception Handling 24
– Creating Custom Exception Handlers 24
Core Engine Roadmap 26
– Overview of Iteration 2 and beyond 26
– Protocol Hops 26
– Defined Processing Steps 26
– Increased Map Selection Capabilities 26
– Enhanced Exception Handling 26
– “Per instance” Receive Location Control 26
Appendix 1: ESB Metadata Schema 27
Appendix 2: Exception Message Schema 28


Many developers hate writing docs, but if you’re on an ESB project, the table of contents shown above could serve as a valuable guide to creating an effective and easily understood way to get developers up to speed and using the ESB.


Now all you have to do i

NUnit Developer

Alright, so it’s a bit of boasting on myself but I’m happy to say that officially as of yesterday I’ve been added as a Developer on NUnit.
If you know me, you know I believe firmly in Test Driven Development and I’ve been
contributing for some time now to the NUnit project. Well Charlie
Pool extended the offer and I’ve accepted the position to become a Developer on
the project officially. What does it change? Very little, I’ll still be writing code
for this great tool just like I was before this but it does make me feel like my contributions
to the project have been of a high quality and that people appreciate the time I’ve
dedicated to it.

Excel File Schema Wizard


Jeff has written a recent article on showing how to use the new FarPoint XLS File Pipeline Component to create a an XML schema from an existing Excel file. I have been looking for something like this for quite sometime. Since Excel has been used as a defacto standard in many companies, I hope this would be of great help for many integrations.


From the Screenshots Jeff has posted it looks mostly like a Flat File Schema wizard. Check it out here

Cumulative Sum inside a loop in Biztalk Mapper

One of my blog reader asked my help to resolve a mapping to find a cumulative sum inside an existing Loop. The Source Xml Structure is as follows


<Details>



<Detail>



<Code>1</Code>


<Amount>200</Amount>


</Detail>


<Detail>



<Code>2</Code>


<Amount>1200</Amount>


</Detail>


<Detail>



<Code>1</Code>


<Amount>200</Amount>


</Detail>


</Details>


The Expected result is as follows. If you see the Amount has to be added for the same <Code> values.


<Details>



<Detail>



<Code>1</Code>


<Amount>400</Amount>


</Detail>


<Detail>



<Code>2</Code>


<Amount>1200</Amount>


</Detail>


</Details>


Even though this appears to be simple, it’s quite hard to do this inside Biztalk mapper without writing Inline XSLT.The reason is that there needs to be flattening (Should not create duplicate <Code> nodes) combined with Cumulative sum.


I found a way using some global variables to resolve this. Even though it might not be the best way, it can help if you do not want to write XSLT inside the mapper. If you are interested, you can download the solution from here

Professional BizTalk Server 2006 Book Update

Phew!  


After some very long days and nights I’ve shipped my second Chapter to Wiley, I decided to go after the chapter I was most passionate about this time round and the Business Activity Monitoring (BAM) chapter was born – some 105 pages which is slightly worrying given the book itself is only supposed to be 700 pages and I’ve got around 14 more chapters to write!   It’s come together really well though, covering all of the BAM plumbing, outlining how you could use it and then demonstrating BAM enabling a proper application and then creating a “Observation Portal” for Dev/Ops and Support people.


My next chapter is on Adapters, after a brief introduction to the guts of Adapters I’m planning to drill into each in-box adapter and cover what it can and cannot do, dynamic properties (when using dynamic ports), context properties they populate and provide some proper real-world examples for each Adapter.


Any suggestions – get them in quick! 🙂


Another big development is that I’ve persuaded my colleague Kevin Smith to contribute to the book which is fantastic news, Kevin as you probably know was a Dev Lead on the BizTalk Product Team up until the 2004 release and was already reviewing the chapters as the official Wiley Reviewer.


Kevin will be writing the low-latency chapter, and contributing to the Testing Chapter (BizUnit) and Performance testing, as the author of BizUnit he’s got the best background for the chapter and we’ve both done large-scale performance testing so it’s great to get his contribution which will make the book even better!


I’ve spoken to a lot of customers recently who seem to be eagerly awaiting the publication which is great to know, I wish it was out today but it’s going to be the end of 2006 I’m afraid 🙁


Thanks for your comments, as ever I’m always keen to hear your feedback – I want 5/5 scores on Amazon! 🙂

Using Test X509 Certificates with BizTalk Web Services

Using Test X509 Certificates with BizTalk Web Services



If you’re planning to use X509 digital certificates to secure communication between services then you would need to test all security features at some point. MakeCert.exe tool can help to generate self-signed certificates for development and integration testing. Here’s the quick process overview. We will need one Certification Authority Root certificate and one ore more (depending on application design and configuration) client and server certificates.



First, create root certification authority certificate. This certificate will be used to sign server and client certificates:



makecert -r -pe -cy authority -n “CN=Test Root Authority  –sk “Test Root Authority -sr CurrentUser -ss My -a sha1 -sky signature TestRootAuthority.cer




This will create self-signed certificate and install it in the CurrentUser/Personal store. Copy this certificate into LocalMachine/ Trusted Root Certification Authorities.


We also need to import this certificate into LocalMachine/Trusted Root Certification Authorities store of all client and server boxes so they can validate certification path. This can be done through MMC Certificates snap-in or using certmgr.exe:



certmgr -add -all -c “TestRootAuthority.cer” -s -r LocalMachine Root




Create server certificate:



makecert -pe -cy end -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -sy 12 –sp “Microsoft RSA SChannel Cryptographic Provider” –n “CN=HostName” -sr CurrentUser -ss My -in “Test Root Authority” -is My -ir CurrentUser TestServer.cer




Using MMC export just created certificate to the pfx file with private key to install it on servers. Note: when installing certificates make sure that account used has access to certificate private key. In case of BizTalk web service this is account for the host instance that runs BizTalk SOAP receive adapter.



Use MMC or certmgr.exe to import server’s public key TestServer.cer into LocalMachine/Other People store on client machines.



Create client certificate:



makecert -pe -cy end -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.2 -sy 12 -sp “Microsoft RSA SChannel Cryptographic Provider” -n “CN=Test Client” -sr LocalMachine -ss My -in “Test Root Authority” -is My -ir CurrentUser TestClient.cer



Install this certificate on the client in the Personal store of the service account that will be sending requests to BizTalk server. Make sure that service account has rights to access certificate private key. If you’re getting HTTP 403 Forbidden error when calling the service that may be the reason behind it. For example, when client makes web service request in context of ASP.NET web application it uses ASP.NET process identity (default, if impersonation disabled is Network Service or ASPNET). To grant certificate access for the specific account use this command:



winhttpcertcfg -g -c LOCAL_MACHINE\My -s “Test Client” -a  Domain\Account



Command above grants access to the “Test Client” certificate private key located in the LocalMachine/Personal to the Network Service account. Command tool winhttpcertcfg.exe is part of Windows SDK and can be found here.



Finally, import client public key into the LocalMachine\Other People store on servers. Then you can enable certificates on the IIS, apply authorization rules, map BizTalk parties to certificates, etc.. This pretty much allows you to reproduce and test real world scenarios with authentication between services, operations authorization, and party resolution in staging environment.

Fully qualified name differs for XSD’s withmultiple root nodes in the Business Rules Engine

One of the most common problems that exist when using the business rules engine is forgetting to use the fully qualified name from a schema in definition of the rule.

Posts like this on Google Groups can clarify what I mean if what I am talking about is not clear.

I have discovered something new regarding the fully qualified name which caught me out this morning and I thought I’d mention it here in case you have the same problem.

If you are using the fully qualified name of a schema with multiple root nodes in the BRE, the fully qualified name must include the name of the root node. When you go to your orchestration and try to feed a rules shape your XSD you will find it won’t recognize it (no drop down appears).

For example you can have a schema with multiple root nodes with a fully qualified name such as schma_name_fully_qualified which, with a single root node, would work just fine. But if the schema has multiple root nodes you must append the specific root node to this qualification for the orchestration to recognize the rule.

So if you had the fully qualified name schma_name_fully_qualified, look at your orchestration view, click on the message you are using and look at the message type: you will find that you must use something like schma_name_fully_qualified.header to properly identify the schema when creating your business rules. Changing this should then allow you to select a message type in your orchestration.