Announcement
On Friday Sept. 5, Microsoft will announce features for BizTalk Server 2009 and future releases plans to provide customers and partners with further clarification about what to expect.
Details:
Below is an update on plans for BizTalk Server 2009 and provided clarity on the rhythm of future releases following BizTalk Server 2009.
The two main highlights of […]
From another session Breeze jointly did with Kenetics whom supplied the hardware for
the entire TechEd 08.
It was a great session Scotty & myself did around demo-ing the bits that were
used to build the system.
>
As promised, the chaos of TechEd has subsided and if there’s that thing of normality
approaching….we’ll I must be close to it.
My Thursday after lunch session went great with a whole series of demos about different
aspects of hosting and running workflows (WCF based, .NET 3.5, Tracking, FilePersistence,
Obtaining Metadata etc):
>
Powerpoints
WF
Demo Solution
The main details folks are as follows: (from an earlier email from Corp)
Details:
1. BizTalk Server vNext:
2. Future Plans:
More Info:
For more information on the BizTalk Server roadmap announcement please visit the BizTalk
roadmap page.
Additional Resources
For more information go to:
%u00b7 PressPass Q & A with Oliver Sharp, GM of BizTalk Server: http://www.microsoft.com/presspass
%u00b7 BizTalk Website: http://www.microsoft.com/biztalk/
%u00b7 BizTalk Server Team Blog: http://blogs.msdn.com/biztalk_server_team_blog/
%u00b7 Steven Martin, director in the Connected Systems Division Blog: http://blogs.msdn.com/stevemar/default.aspx
I’ve seen a number of posts, videos, and now a conference talk abstract talking about
Lo-REST versus Hi-REST
I thought this was already a closed issue
See Dare’s
post
There isn’t anything that is “Lo-REST”, there are services that follow the constraints
of the REST architectural style, and those that don’t (sometimes those that don’t
have a good reason not to)
Some of this seems to revolve around some clients not supporting all verbs, this is
easily fixed with the X-HTTP-Method-Override HTTP header
My next post hopefully will show how easy this is to implement using WCF extensibility.
Check out my new book on REST.
So BizTalk can walk the walk, -but can it TALK the TALK?
I sincerely hope this adapter will come to the rescue, upon deploying your mission critical solution.
Yes I know, I got to much spare time…but here is the download.
The SQL Server 2008 Management Studio has a nice little new feature which seems to be omitted from the documentation. The Script Wizard (Database – Tasks – Generate Scripts) now has a “Script Data” option. If selected the Wizard will generate INSERT statements for the data in the scripted tables. This can be very handy.
This […]
Lately I’ve been using custom Xslt more and more instead of the BizTalk mapping tool. I still use the mapping tool in easy scenarios when I just need to do some straight mapping or maybe even when I need to concatenate some fields, but as soon as I need to to some looping, grouping, calculations etc I’ve made a promise to myself to use custom Xslt!
I find custom Xslt so much easier in more complex scenarios and once one get past the template matching and understands how and when to use recursion (No you can’t reassign a variable in Xslt and you’re not supposed to!) I find it to be a dream compared to the mapping tool. I also find the code so much easier to maintain compared to the result from the mapping tool. I mean someone would have to pay me good money to even start figuring out what this map is doing. And the scary thing is that if you worked with BizTalk for a while you probably know that maps like this isn’t that rare! I’ve even seen worse!
Don’t get me wrong, Xslt definitely has some major limitations.
Some of the acute limitations of XSLT 1.0 I can think of off the top of my head are:
>
> * The lack of real string comparison
> * No support for dates
> * No simple mechanism for grouping
> * No querying into RTF’s
>
And it doesn’t take long before one runs up against one of these and suddenly you wish you were back in mapping tool were we just could add scripting functoid and some code or a external assembly. But then you remember … (Sorry, I know it’s painful just to watch it).
There has to be a better way of doing this and combining the best out of the two worlds!
I started looking into to how BizTalk actually solves combining Xslt and the possibility to use external assemblies. After a couple of searches I found Yossi’s nice article that explained it to me (from 2005! I’m behind on this one!) and it even turns out that there an example in the BizTalk SDK.
Ok, so now I had what I need. I started a new class library project and began writing some date parsing methods, some padding methods and so on.
It somehow however felt wrong from the start and I got this grinding feeling that I must be reinventing the wheel (I mean these are well know limitations of Xslt and must have been solved before). Even worse I also felt that I was creating a stupid single point of failure as I started using the component from all different maps in my projects and I have actually seen how much pain a bug in similar shared dll:s could cause. Basically a small bug in the component could halt all the process using the library! Finally I realized that this kind of library would be under constant development as we ran into more and more areas of limitations in the our Xslt:s and that would just increase the risk of errors and mistakes.
After some further investigation I found EXSLT which looked like a solution to my problems! A stable, tested library of Xslt extensions that we could take dependency on as it’s unlikely to have any bugs and that should include the functionality we’re missing in standard Xslt!
These days it’s the Xml Mvp crowd over at the Mvp.Xml project who develops and maintains the .NET implementation of EXSLT. So I downloaded the latest binaries (version 2.3). Put the the Mvp.Xml.dll in the GAC. Wrote a short custom extension Xml snippet that looked like this (using what I’ve learnt from Yossi’s article).
<?xml version="1.0" encoding="utf-8"?>
<ExtensionObjects>
<ExtensionObject
Namespace="http://exslt.org/dates-and-times"
AssemblyName="Mvp.Xml,
Version=2.3.0.0, Culture=neutral,
PublicKeyToken=6ead800d778c9b9f"
ClassName="Mvp.Xml.Exslt.ExsltDatesAndTimes"/>
</ExtensionObjects>
All you define is the Xml namespace you like to use in your Xslt to reference the dll, the full assembly name and finally the name of the class in Mvp.Xml.Exslt you want to use (make sure you also download the source to Xml.Mvp, it helps when looking up in what classes and namespaces different methods are placed).
That means you need one ExtensionObjects block for each class you want you use which really isn’t a problem as the methods are nicely structured based on there functionality.
Then we can use this in a Xslt like this:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:S1="http://ExtendedMapping.Schema1"
xmlns:S2="http://ExtendedMapping.Schema2"
xmlns:exslt="http://exslt.org/dates-and-times"
version="1.0">
<xsl:template match="/">
<S2:Root>
<Field>
<xsl:value-of select="exslt:dateTime()"/>
</Field>
</S2:Root>
</xsl:template>
</xsl:stylesheet>
Which gives us the below output. Notice the current time and date! Cool!
<S2:Root xmlns:S1="http://ExtendedMapping.Schema1" xmlns:S2="http://ExtendedMapping.Schema2" xmlns:exslt="http://exslt.org/dates-and-times">
<Field>2008-09-05T20:45:13+02:00</Field>
</S2:Root>
All you then have to do in you map is to reference the Xslt and the extension Xml.
Just as final teaser I’ll paste a few methods from the EXSLT documentation
Some string methods:
str:align()
str:concat()
str:decode-uri()
str:encode-uri()
str:padding()
str:replace()
str:split()
str:tokenize()
Some date and time methods:
date:add()
date:add-duration()
date:date()
date:date-time()
date:day-abbreviation()
date:day-in-month()
date:day-in-week()
date:day-in-year()
date:day-name()
date:day-of-week-in-month()
date:difference()
date:duration()
date:format-date()
date:hour-in-day()
date:leap-year()
date:minute-in-hour()
date:month-abbreviation()
date:month-in-year()
date:month-name()
date:parse-date()
date:second-in-minute()
date:seconds()
date:sum()
date:time()
date:week-in-month()
date:week-in-year()
date:year()
As if this was enough (!) the Mvp Xml project added a couple of there own methods! What about string lowercase and string uppercase – all in Xslt! And about 30 new date-time related methods extra to the standard ones already in EXSLT!
Check out the full documentation here!
Let me know how it works out for you.
Hi all
I have just been informed by my MVP Lead, that Patrick Tisseghem, a very excellent
SharePoint guru and co-founder of U2U has
passed away a couple of days ago.
I have had the pleasure of listening t Patrick talk only once, but he left an impression
of a very knowledgeable and enthusiastic professional, as well as a great guy who
is happy to meet people and talk to them about what ever is one his/their minds.
My thoughts go to his wife, his children and the rest of his family.
—
eliasen
Microsoft announced BizTalk Server 2009 today, and gave the green light to talking about the new version. It’s due for release in the first half of next year, and is shaping up nicely. Microsoft is casting BizTalk Server 2009 as a major new version in its own right, rather than just an updated ‘release’ of BizTalk Server 2006. This is an important move, and one I strongly welcome. There is certainly enough in BizTalk Server 2009 to warrant thinking of it as a major revision of the product, although it retains the same familiar functionality and tooling we have been using since 2006 (or even 2004).
I’ve been fortunate in getting my hands on the current non-public CTP in the last month or so, and putting aspects of the new version through its paces. It’s not wise to go into much detail about this first CTP because some of those details will doubtless change in forthcoming betas, driven in part from the feedback Microsoft is getting. However, I will say a little about the new development and build features and expand just a little on the press releases. These are the areas I have been looking at in depth.
BizTalk Server 2009 will ship with bindings for Visual Studio 2008, and you will need to upgrade to this version of the IDE if you are still using Visual Studio 2005 (which you will be, of course, if you are a BizTalk Server 2006 user). It happens that, in previous months, I’ve seen more than one BizTalk shop where developers are having to run both versions of the IDE side by side in order to continue developing for BizTalk Server 2006 whilst exploiting features like WCF and WF in .NET 3.5. For many, the changes in BizTalk Server 2009 will come as a relief. This is not a cynical ploy by Microsoft to force people into upgrades for no additional benefit. The move to Visual Studio 2008 is accompanied by a very welcome move to a new project format, bringing BizTalk Server 2009 into line with mainstream .NET development. The new BizTalk project type is defined using MS-Build, just like C# or VB.NET projects. This has major implications in a number of areas. First, it means that, if you use TFS Build, you can now build BizTalk Server 2009 projects without having to write complex scripts that shell out to DevEnv. Just like C# projects, you can let TFS Build do the majority of the grunt work for you, and concentrate your attention more fully on ensuring that your automated build scripts are comprehensive and robust. This is worth the upgrade in its own right, and removes a major source of current irritation. Thanks to the rough edges in the current CTP, one of my colleagues has had the opportunity to get to grips with this side of BizTalk Server 2009 in some depth, and we can report that it is all looking very good indeed, once a few remaining gremlins have been chased out.
The other aspect of BizTalk Server 2009 which we have spent some time on is unit testing and debugging. In one sense, this is not really so much about new functionality, but more about bringing what has previously been considered ‘black-belt’ into the mainstream. In Biztalk Server 2006, we currently use BizUnit to drive black-box (grey-box?), end-to-end testing, but we have also created some additional code of our own to support unit testing of BizTalk maps, schemas and pipelines. Similarly, if you know the undocumented registry key in BizTalk Server 2006, you can get BizTalk to retain the generated C# code for debugging purposes, manually attaching to BtsNtSvc.exe processes in order to debug into orchestrations, etc. This has proved a life saver in certain situations. The new version of BizTalk Server is now designed to support these approaches seamlessly. Of course, it is designed to work with the integrated unit testing features of the IDE, rather than BizUnit. There are currently some outstanding questions with regard to the debugging support which I won’t go into here, because they simply reflect the unfinished state of the first CTP. However, unit testing certainly works smoothly with BizTalk Server 2009 projects, and will help to raise the bar in terms of the approach that is taken to development of BizTalk solutions. Again, I will avoid going into further here because I will hit issues that are still to be fully resolved, but things are generally looking good.
I have only mentioned those areas of BizTalk Server 2009 which I have been looking at in any depth. There is a lot, lot more. One thing I will monitor closely is the inclusion of ESB Guidance 2.0. I have some problems with some aspects of ESB Guidance 1.0, like the unfortunate way in which the UDDI resolver violates the UDDI standard! However, having spent the last year doing little else but designing and implementing service bus patterns using BizTalk Server and WCF (or, in one case, WSE), I regard the inclusion of ESB Guidance 2.0 as a really intriguing, and hopefully worthwhile, aspect of the new version. It is also intriguing that Microsoft has decided to release their implementation of UDDI 3.0 as part of the BizTalk package. Let no one tell you that BizTalk has no role to play in building service buses, or that it is to be regarded as ‘merely a hub-and-spoke message broker’. In my experience, the exploitation of the dynamic features of BizTalk (dynamic ports, BAM interception, the rules engine, etc.,) in a rigorous, policy-driven fashion provides good support for implementing many of the core patterns described within the world of ESB. The core design of BizTalk Server predates later ESB thinking, but is much better aligned to it that some people will admit.
Roll on 2009.