Compartir a través de

A BizTalk DSL using “Oslo”

  • Artículo

It's been a while since my last post.  I recently started playing with the latest “Oslo” CTP release and wanted to share with you what I have built so far.  One of the cool features of the “Oslo” SDK is the ability to write new Domain Specific Languages (DSL) with MGrammar.  I had worked in the past with ISV's who wanted to generate BizTalk Orchestrations from their products, so I took some test code I had written that generates test ODX files and decided to try building an MGrammer for generating these files.  The idea is to build an easy to read language that when compiled would generate a BizTalk Orchestration .

An example input file to my grammar for an Orchestration looks like this:

Orchestration test
Receive rcvMsg
where ReportToAnalyst = True
end

  If "x>2" then
Transform trnsfrmMsg1 end
else
Transform trnsfrmMsg2 end
end

Send sndMsg end
end

The above creates an Orchestration that receives a message, makes a decision which message transform to run and then sends the message.  Also notice some shapes can contain other shapes and you can set parameters on the Shapes (eg. "where ReportToAnalyst = True "). The syntax for the DSL is very easy to understand, most people could figure out what the process was trying to accomplish simply by looking at the input file.

Next, I need to be able to parse the new syntax.  I did this using the “Oslo” SDK and creating a grammar.  Below is a screenshot of the “Oslo” Intellipad editor in tree mode.  On the left is my input text.  The center pane is my MGrammar and the right pane is the parse tree of the input file:

Intellipad

Now that we can parse the input using MGrammar, I needed a way to generate the ODX file.  To do this, I built a commandline compiler in C# that uses Oslo’s  System.Dataflow library that walks the parse tree and generates the correct XML for the ODX file.  The compiler creates an in memory object for each shape and sets the correct properties and relationships between the shapes.  Each shape object knows how to render itself in XML and also knows it’s child shapes.  Below is the output from running the compiler (for debug purposes, I display the Orchestration shapes and their child relationships):

compiler

Now that I have the Orchestration file, I can load up the ODX in BizTalk and check out what was generated.  I used an empty BizTalk project and “Add Existing Item…” to add the Orchestration to the project and load it up:

BizTalk

Notice it generated the Receive, Decision, Construct/Transform and Send shapes all based on our original input.  The Orchestration still needs to be completed by the developer (for example message types have not been set) but you can see how “Oslo” makes it so even a non-programmer could describe a process flow and have that generated into something executable.

MGrammar makes it easy to create and modify the language.  For instance, I want to make the syntax even more non-programmer friendly.  One simple way could be to change the “end” token to a period.  The syntax to create a shape would change from:

Receive msg1 end

to

Receive msg1.

The key is that I can make that modification to the language without changing the parse tree.  Using the Projections functionality of MGrammar, I can make changes and additions to my language without the need to make major changes (if any) to my compiler.

As you can see, one of the benefits of the Oslo technology is that it can make software development and customization much more approachable.  I talk with many ISVs who are excited  about using “Oslo” as a way to help their end users and system integrators adapt and configure the ISV's out of the box software to run in customer environments.

I encourage you to download the Microsoft "Oslo" SDK - January 2009 CTP and try it out yourself.  And check out the great content on the Oslo Developer Center to help you get up to speed.  Let me know your experiences and thoughts on how you might use “Oslo” with your software.

Comments