by community-syndication | Jul 19, 2007 | BizTalk Community Blogs via Syndication
BizTalk Server 2006 comes with a library called Microsoft.BizTalk.Operations that
allows you to do common operational queries on the BizTalk message boxes and tracking
databases. The concept is very cool and it is something very needed for a product
like BizTalk; particularly since the WMI-based API wasn’t fully updated in 2006 to
reflect model changes.
Unfortunately, while the Operations assembly might seem very nifty at first, the reality
is far less interesting: Like many other cases, Microsoft decided here to “play it
safe” and only expose a tiny fraction of the library’s functionality.
One of my favorite features in BizTalk Server 2006 is the Group Query page in the
Administration Console (it rocks!). Thought you could do the same queries with Microsoft.BizTalk.Operations?
I did to. Well, no, you can’t. The BizTalkOperations class,
unfortunately, only exposes basic enumeration capabilities.
That means you can use M.B.O. to get a list of, say, all Service Instances, but after
that, you’re on your own filtering them (and good luck if you’ve got a few thousand
instances hanging around). You wanted a list of subscriptions? Nope, you can’t; you
can only get subscriptions associated with a specific service instance.
All the functionality necessary to create and execute your own custom queries like
those in the Administration Console is indeed in M.B.O. and used by MicrosoftMicrosoft.BizTalk.Administration.SnapIn,
but it is internal :-(. Why, oh, why?
On a related note, whoever came up with [InternalsVisibleTo] is
starting to seriously piss me off. The idea was good, but too many people running
around using it for evil purposes
by community-syndication | Jul 19, 2007 | BizTalk Community Blogs via Syndication
A misunderstanding about how BizTalk builds MSI packages for applications caused me some recent heartache.
Let’s say I have a BizTalk “application” with the following resources:
As you can see, I’ve got a BizTalk assembly, a “standard” .NET assembly, binding file, text file, and virtual directory (for a web service). In my simple mind, I see […]
by community-syndication | Jul 19, 2007 | BizTalk Community Blogs via Syndication
Hi All,
You can now host Windows Workflow Foundation’s workflows in BizTalk Server 2006 R2 by downloading the “BizTalk Server 2006extensions for Windows Workflow Foundations” from Microsoft Connect Site.
1. Complete a simple survey from https://connect.microsoft.com/Survey
2. Go back to Connect Home page and click on Available Connections
3. Now click on “BizTalk extensions for Workflow Foundation” and click […]
by community-syndication | Jul 19, 2007 | BizTalk Community Blogs via Syndication
I’m on a client site today installing clustered SQL Server to be used as a BizTalk 2006 backend. During the installation, I was flummoxed by the following error and the setup would fail:
Setup failed to start on the remote machine. Check the Task Scheduler event log on the remote machine.
The domain user accounts were in […]
by community-syndication | Jul 18, 2007 | BizTalk Community Blogs via Syndication
I just realized that my friend Christian Weyer has blogged a fantastic sample about Duplex messaging using BizTalk Services . In fact, Christian details some of the benefits of this approach for real world scenarios. So read Christian article first and…(read more)
by community-syndication | Jul 18, 2007 | BizTalk Community Blogs via Syndication
Once a year, during the business rules symposium, vendors of rule engines can show how they implement a general use case that contains many business rules. This use case is known as the UServ Product Derby. You can read the specifications here.
A few years ago I was actively involved with the implementation using Aion (from CA). Last year I put together the web front-end for Corticon. And recently I’ve been examining the implementation from Microsoft with WF rules.
Microsoft’s example (download here) illustrates the technical feasibility of using WF rules. Although the WF rules example does show that it’s technical possible, it does a poor job on making these rules accessible and understandable by business users.
For me it was a nice opportunity to see if the Rule Manager from Acumen Business could actually show the rules and perform rule verification on the policy to discover any anomalies. We start this blog series with a closer look at the ‘Driver’s Eligibility’ policy as defined in the use case. After a few adjustments on the Rule Manager, I produced this report (PDF, XPS) from Microsoft’s example implementation.
The part that got my attention right away was the discovered contradiction. On first look, the rule with the unfriendly name ‘DA_7’ is rather complicated. It is a typical programmer’s construction to use a not (expr and expr)
Such a statement has probably a few nanoseconds advantage on your processor. However do we really want the business user to decipher this statement by applying De Morgan’s law?
Just keep is simple stupid. Where possible, avoid negated rule expressions and split or-statements in multiple rules.
You might wonder if we found an error with the rules example? The example works fine, however Microsoft uses rule priorities to ensure that rule DA_7 (priority -1) , is executed before DA_8 (priority 0). The problem that I have with rule priorities is that you throw away the declarative feature of the rule engine. Suddenly the rule writer has to be aware of priority values in order to achieve the desired result.
Also note that DA_7 does not halt the rules engine. So in a case where we have a male driver of 71 years old Microsoft rule engine will first assign ‘Typical Driver’ to the Driver class, and overwrites this value with ‘Senior’. Not very elegant, because now we also have to make sure that rule ‘DA_4’ must be executed after DA_7 and DA_8. If DA_4 would fire before, we make the incorrect conclusion that a 71 year old senior is eligible without checking his training certificate. Can somebody explain the word declarative? It’s obvious that we lost the baby with the bath water. So please only use priorities if you really have to. And we will show below that these few rules really don’t require rule priorities.
Finally, we see two disjoint rule networks in the Rule Network Graph! We have to wonder what happened with the rules that determine the ‘Training Certification’. And also how the DUI is related to the Training Certificate? Did they use the same specification?
Again, Microsoft example was only illustrating the technical aspects of WF rules. And the example shows how you can achieve First Order Logic with WF rules. (For All Drivers do…)
I will write in a later blog entry, how we are solving the First Order Logic with the Rule Manager.
If we would have just followed the Use case business rules specification, it’s all not that difficult. I always try to stay as close to the initial definition. Here is a produced report of my rewrite (PDF, XPS).
There are no disjoint rule graphs, no self contradictions within the rules, and no rule anomalies among rules. We do discover some incompleteness. E.g. is a Female of 24 years old eligible?
This incompleteness is probably my misinterpretation of the use case specification. But with this report it’s very easy to get these few issues clarified.
by community-syndication | Jul 18, 2007 | BizTalk Community Blogs via Syndication
If you are in Minneapolis on Thursday July 19th please join us for the next Twin Cities BizTalk User Group Meeting.
The meeting takes place at the Microsoft office in Bloomington from 6:00 to 7:30
Andy Morrison, from Digineer, will be delivering a presentation titled ‘Leveraging BAM in the real world’.
by community-syndication | Jul 17, 2007 | BizTalk Community Blogs via Syndication
You can view it here: http://www.on10.net/Blogs/larry/watch-windows-home-server-rtm/
As far as I know, it’s the first case at Microsoft when the product sign-off is captured on video and published.
by community-syndication | Jul 17, 2007 | BizTalk Community Blogs via Syndication
Have you ever created a custom monitoring or troubleshooting tool (or data store)
for working with BizTalk, and wanted the ability to launch the HAT (Health and Activity
Tracker) tool in a particular context? Here are the command line parameters
that will enable you to do just that…
First, though you can typically launch the HAT tool from “C:\Program Files\Microsoft
BizTalk Server 2006\BTSHatApp.exe”, for a production tool you probably want to read
the install location of BizTalk from the registry at “SOFTWARE\Microsoft\BizTalk
Server\3.0\InstallPath.”
The command line syntax looks like:
BTSHatApp.exe “btshat:“ViewName:<OrchDebugger|MessageFlow|SvcInstQuery>
MgmtSvr:<your server> MgmtDb:<your mgmt db> SvcInstId:<service instance
id> [MsgId:]<optional msg id>””
OrchDebugger and MessageFlow bring up the expected HAT views that you are familiar
with. SvcInstQuery will actually open the BizTalk Admin console, with a query
set up so you can see a live service instance with associated messages, etc.
You can also launch with the name of a saved tracking query, as in:
BTSHatApp.exe "c:\program files\microsoft biztalk server 2006\tracking\queries\MessagesSentInPastDay.trq"
The BizTalk management pack for Microsoft Operations Manager appears to use this command
line interface so that it can provide built-in tasks to launch HAT with the context
present in captured event log entires. This means that if you have the MOM operator
console installed on a machine that is joined to a BizTalk group, you have a
nicely integrated set of troubleshooting tools.
by community-syndication | Jul 17, 2007 | BizTalk Community Blogs via Syndication
Have you ever created a custom monitoring or troubleshooting tool (or data store)
for working with BizTalk, and wanted the ability to launch the HAT (Health and Activity
Tracker) tool in a particular context? Here are the command line parameters
that will enable you to do just that…
First, though you can typically launch the HAT tool from “C:\Program Files\Microsoft
BizTalk Server 2006\BTSHatApp.exe”, for a production tool you probably want to read
the install location of BizTalk from the registry at “SOFTWARE\Microsoft\BizTalk
Server\3.0\InstallPath.”
The command line syntax looks like:
BTSHatApp.exe “btshat:“ViewName:<OrchDebugger|MessageFlow|SvcInstQuery>
MgmtSvr:<your server> MgmtDb:<your mgmt db> SvcInstId:<service instance
id> [MsgId:]<optional msg id>””
OrchDebugger and MessageFlow bring up the expected HAT views that you are familiar
with. SvcInstQuery will actually open the BizTalk Admin console, with a query
set up so you can see a live service instance with associated messages, etc.
You can also launch with the name of a saved tracking query, as in:
BTSHatApp.exe "c:\program files\microsoft biztalk server 2006\tracking\queries\MessagesSentInPastDay.trq"
The BizTalk management pack for Microsoft Operations Manager appears to use this command
line interface so that it can provide built-in tasks to launch HAT with the context
present in captured event log entires. This means that if you have the MOM operator
console installed on a machine that is joined to a BizTalk group, you have a
nicely integrated set of troubleshooting tools.
