Well, another interesting gathering of some local BizTalk Server enthusiasts has come and gone. A big thanks to Nabeel for preparing and presented a very interesting session on implementing TDD using BizUnit for your BizTalk Server solutions.
Some of the main points from the demo include:
-
-
An overview of the setup of a BizUnit test
-
The unit test steps provided by BizUnit
-
The structure of the test's Xml file
-
Executing a BizUnit test using either
NUint or Visual Studio Team System's unit testing framework (MSTest)
Of course it was also enjoyable engaging in an informal, open floor discussion where we discussed some of less obvious benefits of using a TDD approach to your BTS solutions.
One of the more noteworthy benefits was fault isolation in your solution. What I mean by this is that if you do find that your end to end solution is not performing as expected, you could use the BizUnit test which you have created as means to either help identify it as a problem in your environment or a problem in some external system you are integrating with.
As always, a big thanks to Ryan and Frikkie for making arrangements and to Ryan and Nabeel for getting the site up. See you all at the next one...
Just a follw-up posting (and to show that I'm still around 
) regarding a brief discussion from last week's Johannesburg BizTalk Server User Group meeting...
Some may recall a question I put forward, after Ryan's interesting presentation on the BRE, regarding the immutability of messages in the message box when calling rules from inside an orchestration. The general consensus was that the BRE itself would not guard the message box's message since:
-
The BRE can be used separately from a BizTalk orchestration and BizTalk Server itself.
-
When used independantly (in your own code), you are required to pass it the Xml, which is then (potentially) modified.
-
Since it can be used independantly, it would not be bound to the message box tables.
What we didn't establish was what would happen in various scenarios where the orchestration (through the BRE) modifies a message variable and any possible affects on the message still in the message box tables. The possible impact of allowing that to happen would be that any port which may be enlisted (but not yet started) or which may be running in a service window may receive the modified message instead of the original.
I've recently done a bit more investigation on some of the BizTalk technical sites and blogs and came across an article entiltiled "Messages are immutable.... or are they??"
This does go some way to show that there are some additional unseen guards provided by orchestrations to protect the immutability of messages. I suspect that this one is provided by the Call Rule shape. Maybe one day I will dig a little deeper in to the orchestration's generated C# code and have a look.
Nabeel also mentioned that he recalled some instances where immutability on the message box may not be guarenteed. So far I've not investigated this any further, however will post any information which surfaces regarding this topic.
Hope to see you all at the next one...
Some interesting news emerging from the Visual Studio and F# teams is that the language appears to moving out of the Microsoft Research (MSR) realm and into the Visual Studio Language Suite.
I have not yet read when this may be happening (apparently it will be the usual CTP's etc, and likely after VS 2008 has shipped), nor have I found anything on what project templates may be supported. F# has OO capabilities, runs on .NET and already can be used for GUI's (web and forms). F# Web Services anyone? 
Really great timing, mainly since my copy of "Foundations of F#" was only delivered to me two days ago. 
The main reason for buying the book was to satisfy my curiosity and although I haven't gotten far, it has certainly started off interesting.
For those who haven't heard of F#, it is currently a research language (of the funtional programming [FP] variery) from MSR and is used internally by both MSR and Microsoft (amongst others). In addition to its FP roots it also supports OOP and is claimed to be the de facto FP language (some say the future language) for the .NET Framework.
Being an MSR language it has already had an influence on both .NET and C# (amongst other languages). F# is widely acknowledged as being the driving force behind Generics in .NET, and LINQ and Lambda expressions borrow (or are) functional programming (FP) concepts.
Also, a few months back, I watched a video where Anders Hejlsberg discusses FP and the possibility to take advantage of multi-core processors by compiling code to execute in a multi-threaded way.
For those interested, I'll try report back as I go through the book and share some experiences going from the OO world to the FP world.
You can view a post on Somasegar's WebLog and on Don Syme's WebLog.
I've recently come across this little "gotcha" regarding class hierarchies and passing arguments to methods using ref (and out). The restriction I encountered is you can't pass a variable defined as a derived class to a method which takes a ref argument of it's base class. To demonstrate this little restriction, consider the following example.
Take the following two classes:
public class Widget
{
private int quantity = 0;
public int Quantity
{
get { return quantity; }
set { quantity = value; }
}
}
public class GrandWidget : Widget
{
private decimal unitPrice = 0m;
public decimal UnitPrice
{
get { return unitPrice; }
set { unitPrice = value; }
}
}
and the following method:
public static void IncreaseQuantity(ref Widget widget)
{
++widget.Quantity;
}
If I were to try and compile the following:
static void Main(string[] args)
{
GrandWidget instance = new GrandWidget();
IncreaseQuantity(ref instance);
Console.WriteLine("Quantity: {0}", instance.Quantity);
Console.ReadLine();
}
I would get these error messages:
-
Error 1 The best overloaded method match for 'ConfigTester.Program.IncreaseQuantity(ref ConfigTester.Program.Widget)' has some invalid arguments C:\Development\CustomConfig\ConfigTester\Program.cs 55 7 ConfigTester
-
Error 2 Argument '1': cannot convert from 'ref ConfigTester.Program.GrandWidget' to 'ref ConfigTester.Program.Widget' C:\Development\CustomConfig\ConfigTester\Program.cs 55 28 ConfigTester
Now this is a perfectly legal (on the surface) use of OO principles, so why can't I do this? The reason is because I am passing the argument by reference (if you don't understand this concept, there are plenty of articles out there to explain). So why is that important? Suppose I introduce this class into the picture:
public class OtherWidget : Widget
{
private decimal unitPrice = 0m;
public decimal UnitPrice
{
get { return unitPrice; }
set { unitPrice = value; }
}
}
And the body of my method changes as follows:
public static void IncreaseQuantity(ref Widget widget)
{
widget = new OtherWidget();
++widget.Quantity;
}
Again, this is perfectly legal, except when you consider the effect of the variable mapped to the instance argument. Since I have passed by reference I could potentially be attempting to do incompatible type assignments.
So how to get past this? You could either remove the ref keyword from the method (which would prevent any change on the original value) and let the default behaviour compile, or you could rewrite
GrandWidget instance = new GrandWidget();
as
Widget instance = new GrandWidget();
This will then still allow you to pass the instance variable by reference.
Firstly, I must confess that up until now I have not really known about partial methods. Whenever I encountered any text on them I would assume they were mentioned in the context of versions of C# beyond the upcoming 3.0 release. So I thought I'd make up for it...
Partial methods are similar to the idea of partial classes (introduced with C# 2.0) where code is organized across different files, however they are worth closer scrutiny as to their uses and limitations.
A partial method is a method (with some restrictions) which is declared in one part of a partial class and is actually implemented in a separate partial class. Lets have a quick look at the syntax
internal partial class ProcessExecution
{
public void Execute()
{
OnExecuting();
Console.WriteLine("Execute...");
OnExecuted();
}
partial void OnExecuting();
partial void OnExecuted();
}
As you can see, I have defined two partial methods, namely:
- OnExecuting()
- OnExecuted()
In the following snippet, I have completed the implementation (in a separate code file)
internal partial class ProcessExecution
{
partial void OnExecuting()
{
Console.WriteLine("Executing...");
}
partial void OnExecuted()
{
Console.WriteLine("Executed.");
}
}
Now this will ultimately draw comparisons with Header and Code files in C++ and Interface and Implementation sections in Delphi, however this is not the case. This is due to the restrictions which the compiler places on partial methods, the most important of which are:
- Partial methods are implicitly private.
- Partial methods must only return void.
- Partial methods cannot accept out argument types.
- Partial methods don't always have a body.
So why the restrictions? To answer this lets actually have a look at the IL which is generated for two scenarios:
- The partial method is implemented.
- The partial method is not implemented.
If we look at the generated IL for the case where the partial method has an implementation, we can see that the methods have been added to our ProcessExecution class (below)
and the calls to those methods have been added to the Execute() method body (below).
Now lets compare it to where we declare the partial methods, but we do not provide an implementation of the methods.
As you can see from the image (above), the calls to the partial methods have been removed from the body of the Execute() method. Additionally, the actual methods have also not been compiled into the ProcessExecution class (below). Digging into the IL for a partial method which is not implemented, we can see the OnExecuting() and OnExecuted() methods are not present.
This is where the restrictions come in.
Should a partial method be allowed to return a result, the lack of implementation would have an effect on the target variable since we may expect a value to be assigned, but never is. This would be the same reason why out arguments are not allowed. By definition the argument needs to be assigned (even if it's to null) before it leaves the methods body.
The private accessibility restriction applies since there is no guarantee that the methods will be compiled to the assembly. As we've just seen, the implementation needs to be provided in order for it to be compiled and any of it's calls to be compiled. This protects any derived classes or calling class from calling a method which may or may not exist.
As mentioned, there maybe comparisons to C++ headers files and Delphi Interface / Implementation sections. However, there are differences in intent and usage:
-
Partial methods are implicitly private and cannot be accessed outside of that accessibility scope. C++ headers define types beyond these limitations and are used as a means to describe types and operations provided by the implementation.
-
Partial methods must return a void type and cannot have any out arguments. C++ headers file have no such restriction.
As for the use cases for partial methods, I recommend having a quick look at this post. The author gives us a explanation and where they could be utilized.
One thing I find many developers over-look when moving to the new versions of Visual Studio is the IDE code editting enhancements. I know of many developers who are using the .NET 2.0 generation enhancements in VS 2005 very competently, yet still do not know about the code snippets, refactoring and "Surround With..." features available in the IDE.
As with VS 2005, VS 2008 brings a few more of these features into the code editors. I reommend taking a look at Scott Guthrie post for a quick tour. (personally, I really like the C# using statements organization feature).
I recently spend a few (many) hours doing some research into the workings of LINQ providers for an internal session on LINQ. I thought I'd share some resources I came across during the exercise for anyone who may also be interested and / or looking to create their own providers.
The ultimate result of this investigation was the reimplementation (translated into C# and made compatible with VS Orcas Beta I) of a LINQ to Windows Desktop Search provider. (As you can probably deduce, there have been some breaking changes on the interface(s) for LINQ providers between Beta I & II).
Now, to understand the role (and thus expectation) of the provider, consider how we query data from an in-memory object perspective (loops, predicates, methods, etc) and then consider how we may query data from a particular data source. These data sources (to name the most common associated with LINQ providers) could be SQL, XML, SharePoint or ActiveDirectory, All these data sources have a different data access API, such as Structured Query Language, XPath or LDAP statements.
What the provider ultimately has to do is translate the LINQ expressions (in the form of Lambda expressions, .NET properties and methods, etc) into an equivalent representation which is understood by the underlying data access API and provide the logic for the various types of statements which may be issued against the provider.
For those who are interested in actually going ahead and creating your own provider, check out the links at the end of the post. I found those to be the most useful for information and examples. From my perspective, I definately found the following aspects the most interesting:
-
The mechanisms by which the LINQ expressions [Lambda expressions] are compiled into data structures [Expressions trees] and then passed to the LINQ provider.
-
Parsing expression trees.
-
Translation of expressions into an underlying data access API.
Useful resources:
-
The IQueryable Tales - LINQ to LDAP - A series of articles by Bart de Smet. These articles give you a good explanation of what is required of the provider in terms of how the various interface methods are invoked and internal provider architecture. Note that as of writing, the information and samples are still based on VS Orcas Beta I. [Update: 5 August 2008] - You can get more recent releases of LINQ to Active Directory on CodePlex.
-
Kevin's VB Adventures - How to implement IQuerable - This is the sample I used and translated into C#. It involves creating a simple LINQ provider which can query Window Desktop Search. This sample is relatively compact and simple and has the advantage of being compiled against the VS 2008 Beta II interfaces.
-
LINQ to SharePoint - A more complete provider also created by Bart de Smet. [Added: 10 August 2007]
-
LINQ: Building an IQueryable Provider - A series of posts from a member of the Visual C# Team at Microsoft. Highly recommended and written for VS 2008 Beta II interfaces. [Added: 28 August 2007]
Just a quick update for anyone who has been following news around BizTalk Server R2 and the WCF LOB Adapter SDK.
I mentioned in my "BizTalk Adapter Wizard (for 2006) posted on CodePlex" post that the SDK was only available for the TAP customers. I am happy to say that it appears that it is now available throught Microsoft Connect as a public RC.
If you are interested, you can find some more information and download details at the BizTalk Server Team Blog.
Custom components (.NET assemblies) can be used quite a bit throughout BizTalk Server. The main scenarios would be:
-
A class library which is called via an orchestration.
-
A custom pipeline component running in the messaging system.
-
A custom adapter sitting on either a receive location or a send port.
Assuming you have compiled these components for debugging and have deployed all the BizTalk artefacts, you can then debug these components using the following process.
1. In the Visual Studio IDE, select Debug > Attach to Process...
This will bring up the list of available processes running on the machine (as seen below)
2. Select the correct instance of the BTSNTSvc.exe process. If you prefer, you can select all of the instances to attach to simultaneously. (You may need to check the "Show processes from all users" checkbox.)
3. Click the Attach button.
You can now execute your BizTalk process and still have Visual Studio hit any break points which you have set on your code.
Should you not want to attach to all the processes, you can attach to the particualr instance you want. The instance will depend on which host your component will be executed from. In order to determine which host you want, shut down the host instance before you open the processes window. Once the process window is open, restart the host instance and refresh the process window. Note which of the entries is a new ID and that will be the host to attach to.
One of the nice features of the BizTalk Server Business Rules Engine (BRE) is the capability to host the engine within your own applications (i.e. it is not exclusively tied to BizTalk Server). This allows you to use the rules engine and all of it's nice policy management and API's from any of your custom written applications. However, there are licensing cost which one must consider when designing and deploying such application.
Should you currently be interested in alternatives, I've just recently come across Smart Rules from Kontac.
I think this product, in particular, is worth mentioning mainly due to it similarities with the BizTalk Server BRE. Just a quick look at the product information and you kind find the following in common:
-
Policy Versioning and Management.
-
XML, Database and .NET assembly type Fact Retrievers.
-
Creating dictionaries and vocalularies.
-
Hosting capabilities
In addition to these similarities, the UI looks almost like an exact clone of the BizTalk Server BRE UI. An added bonus is that there is also a Lite Edition (with some limitations) which can be downloaded for free.
Unfortunately, having just come across it, I am not able to comment on how it works or give feedback on any experiences I've had with this tool. If I do get a chance to play with it, I'll definately give some more feedback on how it compares with the BRE and even WF's rules infrastructure.
If you are interested, there is also a post on The Code Project containing a demo which uses this product.
Excellent to see that Boudewijn van der Zwan has posted the source to his BizTalk Adapter Wizard on CodePlex.
This is a definite must have for anyone looking to develop adapters as it takes care of much of the plumbing in regards to using the Adapter Framework.
The wizard will take care of the following for you:
-
Creating the run-time and design-time assemblies and hook them into the base adapter assemblies which ship with the BizTalk Server SDK.
-
Create Receive (Request and Request-Response patterns) and / or Send (Send and Solicit-Response patterns) adapters.
-
Create the property schemas for both handler and port level configurations on both Receive and Send type adapters.
A nice feature which Boudewijn added to the 2006 release is support for the XML annotations which make the properties schemas more useful. This includes fields such as Friendly name and Description.
I still recommend having some familiarity with the Adapter Framework as there will still be a few cases when you'll need to take care of the plumbing yourself. These cases may be:
-
Writing the code to validate the adapters configuration.
-
Modifying the property schemas.
-
Using a Metadata Harvesting style of design-time UI.
As for R2, Microsoft will be shipping the WCF LOB Adapter SDK which should take much of the complexity away from the current Adapter Framework. Good news is that it appears that both the current framework and the new WCF framework based adapters should be able to run smoothly side-by-side.
Unfortunately the WCF Adapter SDK appears to only be available for the TAP customers and is currently scheduled to be made available Q3. In the meantime, keep visiting Developing adapters using WCF.
Note: In addition to the adapter wizard, you can also get his BizTalk Time Breakdown tool from his blog.
I've recently completed going through the first issue of BizTalk Hotrod Magazine (available for download here) and have to commend the guys who spent time putting this together. They really have gone out of their way to produce a fun and informative publication which stands out.
The first issue deals with the following topics:
- BizTalk Server 2006 R2 - First Look
- Monster BizTalk Databases and how to avoid them
- Implementing FIFO processing with BizTalk Server 2006
- Top 10 things you should know about BAM
- Invoice Automation with BizTalk 2006
- "Debatch" or "Not to Debatch"
- Tools of the Trade
In addition to the articles, there are also links to:
- Whitepapers for BTS 2004 and BTS 2006
- MSDN Webcasts for BTS 2004 and BTS 2006
- Community and Blogger sites
- Training sites
- A calender of upcoming BizTalk related events.
Well done guys! Can't wait to see the next issue. 
Just a quick pointer to a new offering from Microsoft which I've had a brief look at: BizTalk Services.
This offering is currently being described as "the first Internet Services Bus". From what I gather it is an extension of the Enterprise Service Bus model, extending the model to provide a single (public) repository and uniform authentication, security and relaying model across the services.
To quote one of the team members:
"your service opens at a URI on the connect.biztalk.net machines. Then a client connects to that URI and can start sending messages. We don’t want to be in the way of your app, so our relay will immediately try to establish a direct connection between clients"
The following services are currently either live or on the way:
- BizTalk Identity Services
- BizTalk Connectivity Services
- BizTalk ServiceBus Services
- BizTalk Workflow Services
Developers can also create their own services using WCF and the BizTalk Services SDK and then expose these on the Internet Service Bus. A plus point is it appears that your service does not actually need to be exposed via the BizTalk Server product, just WCF. BizTalk Services will handle the authentication requirements, after which the client and service will communicate directly.
You can have a look at the site / CTP here. Also take time to download the SDK and have a look at the samples and API documentation.
As I mentioned, this was just a brief excursion into BizTalk Services. I will hopefully get a chance to play with this and do a few more posts or correct any errors I've made in this post.
Useful links:
Virtualization is a great thing in software development. You can create specific environments with specific versions of toolsets and servers without having significant hardware costs. However, you hit an unexpected (and rather amusing) problem, as I did, when you start using device emulators.
I had been using a particular Microsoft Virtual PC 2004 setup for a few months which I created as a dedicated development environment for a particular group of solutions. Recently there was a requirement to create a line of business application developed to run on the .NET Compact Framework and target Pocket PC 2003 devices.
The following is a screen shot of the message I got when I started debugging the application on the Pocket PC 2003 Emulator.
I've just found this nice little article in the May 2007 edition of MSDN Magazine. As the title implies, it gives some details on some of the better development practices for developing BizTalk Server solutions.
A quick list of the tips and tricks discussed are:
- Always Use Multi-Part Message Types
- Always Try to Design Orchestrations with Direct-Bound Ports
- Always Use Separate Internal and External Schemas
- Never Expose Your Internal Schemas Directly in WSDL
- Always Optimize the BizTalk Registry for Web Services
- Always Set the Assembly Key File with a Relative Path
- Never Overlook Free Sample Code
- Debug XSLT in Visual Studio
When I first looked at some of these recommendations, some appeared to be taking things a little too far. However if you read the justifcation for scalability, deployment and flexibility, then you will getting an idea of where these recommendations come from. I know I'll be considering them for future projects.
More Posts
Next page »