by community-syndication | Sep 17, 2007 | BizTalk Community Blogs via Syndication
I was provided a schema withan attribute named “Type” provided byan ERP vendor. I needed to promote it for use in Send Port Filters and in a Correlation Set. I promoted the attribute and allowed BizTalk to create the promoted property “__Type” shown here:
“Type” is a reserved name. The Send Port Filter allows me to use this “__Type” Promoted Property.
But , . . . when I try to use this Promoted Property in a Correlation Set it gives me the following error.
Why does BizTalk default to the “__” prefix for reserved names, when it will not allow these prefixed names in Correlation Sets?
by community-syndication | Sep 17, 2007 | BizTalk Community Blogs via Syndication
My wife and I did the annual Ogden Valley triathlon over the weekend…
This was the pic just before the race. I was a swimmer growing up so that was the easiest part for me personally. I was in about 6th or 7th place (in my age group) coming out of the water, and from that point on it was pretty depressing. I basically watched people pass me for the rest of the race. Plenty of moms and grandfolk-aged athletes. Pretty humbling.
I guess I should have listened to my wife and actually trained for it. 😉
by community-syndication | Sep 17, 2007 | BizTalk Community Blogs via Syndication
The next thing on my teaching schedule is our upcoming Double Feature: WCF + WF, which begins next Monday (9/24) in Boston (Waltham MTC). Matt Milner will co-present with me.
We still have a few seats left for this one if you can swing the last-minute travel. We’ve had a great response to our Double Feature’s because they’re a great way to kill two birds (WCF & WF) with one training stone. If this one doesn’t work, there’s another one planned for the West coast (Irvine), later in Dec (12/10). If you want to be notified when new courses are scheduled, subscribe to our course schedule blog.
by community-syndication | Sep 17, 2007 | BizTalk Community Blogs via Syndication
That’s right. I couldn’t resist any longer, especially after the price drop.
Simply amazing.
by community-syndication | Sep 17, 2007 | BizTalk Community Blogs via Syndication
I just returned home after spending several days in meetings with various folks from the Microsoft Connected Systems Division (CSD). The event I attended is what Microsoft typically refers to as a Software Design Review (SDR). I’ve had the privilege of participating in numerous SDR’s over the years, which has been fascinating in many ways. So I thought I’d take a second to describe what a Microsoft SDR is like and why they are a good thing for you and me.
The basic idea goes something like this: Microsoft invites a bunch of customers/partners to listen to them talk about what they’re thinking and planning for the next several years (timeframes always vary), which inevitably generates a great deal of discussion, emotion, and heated debate amongst all those involved.
The value prop for customers/partners is primarily early access to information, which can offer a significant competitive edge in some cases, not to mention the possibility of us actually being able to *influence* the direction of the product or technology in some small way that better server our personal objectives.
The reason it always ends with heated debate is primarily because of who they invite. You know the type, folks (like me) who think they know everything and are always right. The type of person that shares opinions as statements of fact and is sure that if Microsoft doesn’t listen, the company is doomed. Although it’s often frustrating for the attendees to cope with 20-30 other guys who share that same gene, it isn’t a bad thing for Microsoft, because remember their value prop is to get as much instant feedback as possible. What better way than to get a bunch of strongly-opinioned zealots who love to hear themselves talk? It’s clearly more effective than inviting polite folks who happily listen and accept what they’re told.
Throughout the various discussions and debates, new issues are commonly identified, ones that perhaps MS hadn’t fully considered, along with new ideas for the design that may better address our needs and goals. That’s why it’s called a design “review”, which implies there’s still a chance to influence the final outcome. I’ve seen this happen numerous times, where a comment made by a customer actually changed the way the product turned out.
I know it sounds crazy but it’s true.
Microsoft is different today than it once was. They do listen to their customers, earlier in the process than most folks realize. The focus on community is strong than ever before, and the company is becoming more transparent each time I interact in these sessions.
This doesn’t mean Microsoft couldn’t be even more transparent with their customers/parnters. There’s obviously a natural tendency to keep our cards close to our chest until we’re confident and secure, but that prevents the most valuable conversations from taking place. Timelines are taboo — the stuff no one wants to discuss.
Ultimately an SDR is a mutually beneficial event where MS and its customers/partners try to leverage one another with their own self-interest in mind, but both sides get something out of it, even if it’s not completely realized for years down the road.
If you ever have the chance to participate in one of these events, seize the opportunity…you won’t be dissappointed.
by community-syndication | Sep 17, 2007 | BizTalk Community Blogs via Syndication
From Clayton,
http://claytonj.wordpress.com/2007/09/16/moss-internet-site-articles/
by community-syndication | Sep 16, 2007 | BizTalk Community Blogs via Syndication
I have been having fun working on the middle tier of an application which is using BizTalk, Windows Workflow, MSMQ and the Windows Communication Framework.
One of the requirements is to processes messages we receive from a legacy system through MSMQ in FIFO order.
We used WCF to communicate with MSMQ and used the msmqIntegrationBinding binding since the legacy application was placing the messages on the queue.
The FIFO processing seemed to be little more difficult to iron out. It turns out that by default a service’s InstanceContextMode is PerSession. If the channel is a datagram then the IntanceContextMode degrades to PerCall. So what happens is that the WCF runtime will create a new service instance for each available request/message up to the MaxConcurrentCalls/MaxConcurrentInstance setting utilizing multiple threads. This was not going to provide my FIFO processing.
So, to set WCF to only pull and process one message at a time you need to set the service’s InstanceContextMode to Single along with setting the ConcurrencyMode to single. The following code shows these settings:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,
ConcurrencyMode = ConcurrencyMode.Single,
)]
public class MSMQEventService : IMSMQEventInterface, IDisposable
{
Once these settings are set you will achieve FIFO processing and WCF will only utilize a single thread and will process one message at a time from the single queue.
My next entry will cover processing multiple queues and processing each queue in FIFO order.
by community-syndication | Sep 16, 2007 | BizTalk Community Blogs via Syndication
Email from our internal readiness team…
Hi,
Aligned to the BizTalk Release 2, global launch in Australia, we have scheduled the training for Partners as per below.
Please ensure that your partners are aware of this and register: As always – thank you very much.
BizTalk R2
https://www.local.microsoft.com.au/australia/events/register/home.aspx?levent=478264&linvitation
Sydney – Oct 18 & 19
Brisbane – Oct 15 & 16
Melbourne – Oct 25 & 26
Perth – Oct 18 & 19
by community-syndication | Sep 16, 2007 | BizTalk Community Blogs via Syndication
Like most BizTalk Server developers I am addicted to the use of DebugView. This, in case you are one of the three BizTalk developers out there who are still not aware of it, is a free utility written by the SysInternals people. Microsoft bought SysInternals a while back, and the utility can now be downloaded from their web site at:
http://www.microsoft.com/technet/sysinternals/utilities/debugview.mspx
DebugView provides a viewer for traces created using the Win32 OutputDebugString() API.You can liberally instrument your .NET code using calls to System.Diagnostics.Debug.Write<xxx> methods, then open up DebugView and run you code. The output is nicely displayed in the DebugView console.For BizTalk developers, this is an indispensable tool because there is no way to single-step through XLANG/s expressions. The Orchestration debugger is built on top of the orchestration engine, and is not a ‘true’ Win32 debugger. It can only single-step through interactions between the orchestration and the orchestration engine which occur at a much coarser level of granularity than individual lines of XLANG/s code.
I’ve spent the last couple of weeks pretending to be an ASP.NET 2.0 developer. The code I was writing does a fair amount of re-direction. It supports a number of different log-in models based on the Forms Authentication model in ASP.NET 2.0, but integrated with a remote identity provider. The code is ‘proof of concept’ stuff, and supports different ’candidate’ approaches, including the ability to switch to local authentication in order to demonstrate the code in scenarios where we have no remote connectivity. To begin with I (rather stupidly, in hindsight) was trying to develop using the new Web Site project type in Visual Studio. Oh dear. I needed to use SSL sessions to debug the code because we are using CardSpace. You can’t do this under the local web server. I tried, without success, to debug my code under IIS, but found that, for some reason, I was unable to attach to IIS worker processes! Then, I really came unstuck when ASP.NET completely lost the ability to debug. It was creating pdb files OK, but one of them appeared to be corrupted somehow each time it was built (for example, no version number), and Visual Studio insisted that I had no symbols loaded, even though the Module window clearly showed that I did!
I gave up, and ported the code over to a Web Application project. I still have problems. Visual Studio currently reports a set of spurious build errors ‘dynamically’ while using the designer (these change dynamically over time even if I don’t touch the keyboard – yes I mean it!I just sit there and stare at the screen for a minute or two and see the error messages change before my eyes), but then builds and publishes the application anyway. It has lost the ability to see Master Pages if I use generated paths with the ‘~’ specifier.It has also become hopelessly confused in regard to a custom control that I am using -a problem, incidentally, for which there are thousands of hits in Google, but only one conclusion – ‘tough – it’s a long-standing bug – you can’t fix it and there’s no known workaround – rebuild your project from scratch’. Apart from that, the Web Application works OK, and I can now debug my code smoothly under SSL sessions. A good lesson learned. I certainly won’t use Web Site projects in future, and will try not to use ASP.NET unless I have to, until such time as Microsoft sees fit to stabilise the design-time ASP.NET tools.
The point of this, apart from letting off steam about the general flakiness of ASP.NET 2.0 under Visual Studio 2005 SP1 (it’s horrible), is that while developing using the Web Site, I needed to use DebugView quite extensively. Even now, it is of some use due to the re-direction. I can trace my code in one page, even though this page redirects to another so that I can’t see my trace output using the built-in tracing features of ASP.NET. DebugView shows me what I need to see, as long as I remember to place ‘#define DEBUG’ statements in my ‘CodeBehind’ files.
I ran into a problem with DebugView which I have seen before. I’ve been trying to research it to come up with a definitive answer, but I don’t know the underlying cause – just the symptoms. My problem is that my ASP.NET code runs in a different session to the desktop. This means that the output does not appear in DebugView unless I enable the ‘Capture Global Win32’ option. However, this option was not available in DebugView.
At this point, I should say that I am developing on Windows Server 2003 R2. I run Vista on my notebook. When I open the same version of DebugView on my Vista notebook, I can see the ‘Capture Global Win32’ option. However, I can’t see it when I run DebugView on the Windows Server 2003 box.
I was tearing my hair out over this one, and it isn’t the first time I have run into this problem. I spent some time trying to find an answer on Google. I didn’t turn anything up, but somewhere I read something about remote connections. I had a thought. I powered up a Remote Desktop session to my own development box and then opened DebugView. Success! The ‘Capture Global Win32’ option appeared, and once selected, DebugView started happily displaying the output from my ASP.NET application.
This approach cannot be used on XP (or, I think, Vista) because, even with SP2, XP does not support concurrent remotedesktop sessions. Apparently, Microsoft was going to lift this restriction at some point, but then decided not to. As I say, when running DebugView under Vista, I don’t get the problem anyway.
I experimented further with DebugView by setting up a ‘client’ instance (surely this should be termed a ‘server’ instance’) and then connecting to this on the same machine. In my first attempt, this appeared to work, but when I tried to reproduce the approach the following day, it failed. The Remote Desktop approach works every time though.
As I say, I don’t currently have an explanation. I know, from Googling, that there are some interesting issues when using OutputDebugString regarding the permission set granted to an underlying Mutex. Maybe the behaviour of DebugView has something to do with this. Maybe the explanation is simpler. It may have something to do with having another registered debugger in the same Windows session. I’m not sure. What I do know is that remoting into your own desktop on Windows Server 2003 works very nicely indeed.
by community-syndication | Sep 16, 2007 | BizTalk Community Blogs via Syndication
My fellow BizTalk MVP, Leonid Ganeline, asked if I would comment further on mechanisms to govern sequential flow in rules in MS BRE. He was picking up on some comments I made in my article comparing WF and MS BRE rule performance (see http://geekswithblogs.net/cyoung/archive/2007/08/12/114597.aspx#143628).
What I had in mind was the use of state transition patterns within rule sets. These can be used to layer a degree of sequential control over the set-based pattern matching approach taken by engines like MS BRE. The basic pattern is simplicity itself, and very common. What I generally do is assert an additional ‘context’ fact to the engine (typically some custom .NET object) in which I maintain a state specifier (e.g., a simple string property). I can then group rules together to match specific states, and use a low-priority rule in each group to change the state. The ‘sequential’ flow is then governed by the state transitions. Of course, any single group of rules that match the same state do not operate in a sequential fashion amongst themselves. However, you can always just have one main rule per state if you wish. Here is a very, very simple example of the kind of pattern I have in mind.
/*********************************************
* Group 1 – ‘Started’ state
********************************************/
Rule 1
IF
AND
Context.CurrentState == “started”
MyFactA.Property1 > 5
MyFactB.Property1 < MyFactA.Property
THEN
MyFactB.Property1 = MyFactA.Property1
assert MyFactB
Rule 2 (priority -1)
IF
Context.CurrentState == “started”
THEN
Context.CurrentState = “initialised”
assert Context
/*********************************************
* Group 2 – ‘Initialised ‘ state
********************************************/
Rule 3
IF
AND
Context.CurrentState == “initialised”
MyFactA.Property2 == “USA”
THEN
MyFactA.SetCountryCode(“01”)
Rule 4
IF
AND
Context.CurrentState == “initialised”
MyFactA.Property2 == “UK”
THEN
MyFactA.SetCountryCode(“44”)
Rule 5 (priority -1)
IF
Context.CurrentState == “initialised”
THEN
Context.CurrentState = “completed”
assert Context
assert MyFactA // convenient place to re-assert MyFactA
//to avoid loops if, for example,
// MyFactA.SetCountryCode() changes the
// state of MyFactA.
/*********************************************
* Group 3 – ‘Completed’ state
********************************************/
Rule 6
IF
AND
Context.CurrentState == ” completed “
THEN
MyFactA.Property1 = 0
MyFactB.Property1 = 0
/********************************************/
The low-priority ’state transition’ rules are rules 2 and 5. Group 2 contains two main rules, whereas the other groups have just one main rule.
Personally, I think MS BRL (and the Rules Composer) should provide a built-in abstraction for this design pattern – i.e., provide a way of grouping rules by state, and declaring how to transition to a new state when a group has completed its work. If this was supported, it would not be necessary to explicitly define an additional low-priority rule in each group.
This design pattern can be a little difficult to maintain in MS BRE currently because the rule composer displays rules in alphabetic order in the UI, regardless of the order in which you created them, and so you cannot see the groupings and state transitions. The answer to this, of course, is to adopt a rule naming convention which makes the pattern more explicit in the UI.
I used this design pattern recently when creating a rule set for applying Bayes Theorem. See http://geekswithblogs.net/cyoung/archive/2007/08/27/114988.aspx. The rule set was written for other rule engines (Jess and CLIPS), but uses exactly the same principle. I have ported the rule set to MS BRE, but just need to clear a potential commercial hurdle before publishing the code.
