UK Connected Systems User Group – May 2011
The next uk connected systems user group event is open for registration:
11th May 2011 @ EMC
http://ukcsbugmay2011.eventbrite.com/
Code Uploaded for WCF/WF and AppFabric Connect Demonstration
A few days ago I wrote a blog post explaining a sample solution that took data into a WF 4.0 service, used the BizTalk Adapter Pack to connect to a SQL Server database, and then leveraged the BizTalk Mapper shape that comes with AppFabric Connect. I had promised some folks that I’d share the code, […]
Blog Post by: Richard Seroter
IE10 Preview – How Microsoft Competes in the Feature Olympics
Internet Explorer has made huge strides in the last couple of years.Microsoft has at last begun to lay the ghost of IE6 to rest with a solid, fast, standards compliant, reasonably up-to-date (not quite the same thing) forward-looking browser with the cleanest UI in the business.
However, one issue clouds the horizon.Other browsers, most notably Google Chrome, rev much faster that IE.The importance of this is that, by bringing out new versions on shorter (much shorter, in some cases) timescales, other browsers gain a clear advantage.They get emerging specifications and technologies out to end-users faster and therefore shape the future of the web in a way that IE could not touch for many years.This, in turn, builds a sense of momentum which increases the loyalty of the user base.Indeed, it is a major factor in growing the user-base, as we can see clearly with Chrome.With IE, by contrast, we have lived for years with a strong sense of Microsoft holding everyone else back.
Microsoft needs to speed up the cycle.I wondered if we would see any signs of this after the RTW of IE9 last month.Well, yes we can.Yesterday, Microsoft released Platform Preview 1 of IE10.Given Microsoft’s record, this is absolutely astounding and provides further evidence that the bad old days for IE really are receding.Of course, after three weeks of development, things are not that different to IE9, but the HTML5 story is improved, thanks chiefly to several new CSS3 features.
IE9’s HTML5 story is mixed.On the one hand, the browser lays a strong foundation for the future with comprehensive DirectX rendering and a much-repeated commitment to HTML5 as a future standard.On the other hand, the feature list count for HTML5 is noticeably lower than its nearest rivals.Put simply, IE9 supports less HTML5 than others, but supports it well.The IE team has repeatedly stated its position on this.Their main argument is that IE9 supports ‘site-ready’ HTML5 that will interoperate across all today’s browsers and avoids features on which there is still disagreement or which may not make it to the final specification.A secondary theme is that it was more important to develop the sub-systems that underpin a great HTML5 experience than strive after having the longest HTML5 feature list.
Broadly, the argument plays quite well.Given IE’s poor reputation amongst web developers, it is understandable that they want to stress their commitment to interoperability.Certainly, some of the other browsers are now carrying the burden of ‘HTML5’ features that won’t actually make it into the W3C Recommendation (whenever it finally arrives) and features which are not broadly interoperable with other browsers.Of course, it’s not really as clear cut as this.Some of the features that were once counted as part of HTML5 are still very much alive and kicking and will almost certainly be incorporated into future versions of HTML.
Try using each of the HTML5-enabled browsers in turn to browse the various HTML5 showcases provided by different vendors, and you will quickly get an idea of where HTML5 interoperability is really at, currently.And yes, the other HTML5 browsers tend to fare well on Microsoft’s HTML5 preview site in terms of functionality, suggesting that Microsoft’s take on HTML5 does indeed approximate to a ‘lowest common denominator’ interoperable approach.Of course, performance is a different story and seems to be the dominant theme of Microsoft’s showcase apps.
The myth that Microsoft spends its days subverting every standard going whilst all other players effortlessly deliver interoperable perfection has never been accurate since a brief period in the first half of the 1990’s when the company first ’won’ this reputation thanks to some fairly cynical actions (nothing, of course, to do with web standards).It is certainly the case that the complaint of poor standards compliance can no longer be honestly sustained with respect to IE9.However, IE9 illustrates a dilemma that all browser vendors face.It can take an eon for emerging web specifications to stabilise and for standards organisations to ratify and publish a given standard.It simply isn’t the role of organisations like the W3C to be in the vanguard of developing new specifications for everyone else to follow.There has been a huge misunderstanding about this for years.The W3C, and others, follow where the industry leads.They work to foster collaboration and agreement amongst those who are actually coming up with the ideas, trying out new innovations and pushing the boundaries.That means that the more innovative browsers will always be ahead of the curve and, consequently, in danger of subverting interoperability.
This, then, is the big question about IE’s HTML5 support.Now that Microsoft has convincingly closed the field on its rivals, will it be content simply to follow where others lead, trailing at the rear end of a densely-packed group of HTML.next ’feature-athletes’?Or should it attempt to move closer to the front of the pack in order to more effectively set the pace.Well, long-distance running is all about pacing and strategy.If you are in the race for the long-haul, it often pays to hold back for a while. I think it probably suits Microsoft’s purposes for the time being to merely match the pace set by others whilst all the time quietly building on their blindingly-fast DirectX rendering engine. And after all, we are still some way off seeing an equivalent Microsoft HTML5 technology for mobile devices which is where, increasingly, it really counts.I suspect they are attempting to maintain their stamina and build up their strength for a future push to the front.After all, Microsoft always preferred being in the industry driving seat.
Certified Trainer renewal – and why 400 is a magic cc limit
I renewed my Microsoft Certified Trainer “license” (if you so will) for another year today. I really do enjoy spending some time in the classroom now and then. I recognize that I might not always be the best pedagogue, though you should know I try, but I do hope that that mix of theoretic learning material with that crucial ingredient of real world experience gives “this is how this thing works” that extra nuance of “this is how this thing is actually used”. And that’s super important and often left outside of the course material since it’s hard to convey, but in many cases I believe I can bring that to the table.
To those that are unaware, the certified trainer is not really a certification that you pass, although you do need to have passed a certification as one of the requirements, it’s more of a affirmation of your ability and commitment to pass on your insight into your-technology-of-choice to others.
Or as the MCT site puts it:
Become part of an elite, international community that spans more than 150 countries and regions and includes classroom and e-learning instructors, learning consultants, authors, conference presenters, and user group leaders. Microsoft Certified Trainers (MCTs) are the premier technical and instructional experts on Microsoft technologies, and are the only individuals authorized to deliver training for Microsoft Certification.
Now, why is 400 (or really 4000 Swedish crowns) a magic limit to (my) credit card companies? Well, that’s roughly what the MCT renewal cost me, and it bounced. When I called the cc company to see why, and verify that it had, I got told that they had an outage of the system that day, and that only amounts below the 4k Swedish crown limit were automatically approved when the system was unavailable. That sounds like a security hole if any to me. I really do hope there are more safeguards in place around that. Or is there someone there in need of an MCT for some security best practices classes?
Blog Post by: Johan Hedberg
New MSDN Virtual Lab: BizTalk Server 2010: Deploying and Managing BizTalk Applications
It’s available a new MSDN Virtual Lab: BizTalk Server 2010: Deploying and Managing BizTalk Applications “After completing this lab, you will be better able to assign a strong name key to an assembly, configure the application deployment property, build and deploy a BizTalk application, manage ports by using binding files, manage applications by using MSI […]
Blog Post by: Sandro Pereira
BizTalk 2009 – Be careful when setting Service Windows on Send Ports
Note: This blog posts pertains to BizTalk 2009. It has not been tested against other versions although I suspect the behavior is the same.
We recently had a situation where a downstream system was having issues processing certain types of messages. We were asked to “queue” messages received from the source system until the issue was resolved. In order to do this we simply stopped the Send Port but left it enlisted. Since the Send Port is still enlisted, a subscription still exists within the MessageBox database. Any messages received while the Send Port is in this state are essentially “queued”.
When you send a message into BizTalk and have the port Stopped(but enlisted) you can expect a Suspended message that has an error description of “Service instance was suspended because the corresponding service (orchestration, sendport, …) was in the stopped state. Instance can be resumed after corresponding service is started.”
Even with this Send Port stopped, we can still right mouse click on the suspended instance and resume it without issues.
We knew that we had to have this send port stopped for a few days while the issue was resolved. Since we have multiple people working within our Middleware team and also have automated processes to ensure our applications are online, we decided to set a Service Window on the Send Port in addition to having these messages queued as a precautionary measure.
The intent of this Service Window of 1 second allows us to log into the server before 9am to ensure the Send Port is not started. Then we would disable the service window and use a time that is before the current time. The current time, for the purpose of this blog post, is 10:06 am.
If we send in another message with this Service Window we will see a screen much like we saw without the schedule in place.
If we check our BizTalkServerApplicationQ table within our MessageBox database we will discover that no records exist:
If we check our BizTalkServerApplicationQ_Suspended table we will discover that metadata exists for our message that we just received.
So what are these tables? These tables make up BizTalk’s work queues for our BizTalk Server Application Host. Stay tuned and note which tables have records as you will soon see a discrepancy.
With our message “queued” and our Service Window still set for 9:00:00 am to 9:00:01 am I am going to resume this message and it will be delivered successfully even though the Send Port is stopped.
Great! So what is the point of this post? Change your window to be 1 minute instead of 1 second and you will get an entirely different behavior.
With the Service Window set to be 1 minute and with the current time set to 10:21 am, I will now submit another message to BizTalk. Once again I will get a suspended message.
If we take a look at the BizTalkServerApplicationQ_Suspended table we will discover that our message is in there but is not in the BizTalkServerApplicationQ table
When resuming the message this time, it will not get delivered to the end point. Instead it gets into a “Retrying and idle” state.
If we further investigate this message we will determine that the Message Status is set to “Queued (scheduled for later delivery)”
If we check out the status of our tables in the MessageBox we will determine that the message is no longer in the “Suspended” table.
We can now find the message in the “Q” table. Also note the Start and End Windows.
So what can we do if we want to resume this message since the Downstream system is now available and they want the 1800 messages that have been queuing up over the past 3 days?
- Maybe we should remove the Service Window from the Send Port? (hint – it doesn’t help)
- Maybe we should start the app? (hint – it doesn’t help)
- Maybe we should restart the host instance? (hint – it doesn’t help)
- Since the message is in a “dehydrated” state maybe we need to wait 5/10/20 minutes for BizTalk to wake up? (hint – it doesn’t help)
There are really two solutions in my mind:
- Wait for the actual service window, with application online and Service Window checkbox removed, and these messages will get processed – promise.
- Update the service window in the “Q” table so that BizTalk will send these messages when this window is met. To demonstrate this I will update the table with a timestamp that is in the near future. It is currently 10:46 am and I will update the timestamp for the window to start at 10:50 am.
Without any intervention the outstanding message(s) will get processed/delivered at 10:50 am.
Key Takeaways
- Be aware that Service Windows are “attached” to the messages as they are being processed. There is no way to modify this except through the database.
- Changing the Service Window of a Send port where messages already have a Service Window has no effect. (It is too late)
- Setting a Service Window of 1 second has no impact.
Catching Web Service Exceptions in BizTalk orchestration
I had a business requirement to catch all web service exceptions and include them in an email.
Here’s how to do it:
Put the Web Service Call and Response inside a scope with an Exception Handler. You don’t have to make it transactional. You won’t be able to put both the send and receive shapes in an atomic scope. I left it as “None”. You’ll need to add a reference to System.Web.Services.dll assembly to your project. Right-click on your scope and select Add New Exception Handler.
Select the exception handler you just added and open the properties window.
Configure the following properties:
Property Value
Exception Object Type System.Web.Services.Protocols.SoapException
Exception Object Name ex_MyException
Inside of the exception handler you can do what you need by accessing ex_MyException.Details. Be careful about terminating the orchestration inside of the exception handler, as it might cause zombies.
Blog Post by: Eric Stott
BizTalk Server EDI Scenario: Send an X12 Message Over AS2 and Receive an Asynchronous MDN
This article applies to BizTalk Server 2006 R2 and BizTalk Server 2009. The instructions in this article are targeted for a two-machine scenario where both trading partners involved in a B2B scenario have their BizTalk Server set up.
BizTalk Server Resources on the TechNet Wiki
See what BizTalk-related videos, articles, samples, posters, and documentation are available.
BizTalk Server Non-EDI Scenario: Sending and Receiving a Non-EDI Message Over AS2 with an Asynchronous MDN Using Different BizTalk Servers
This article applies to BizTalk Server 2006 R2 and BizTalk Server 2009. The instructions in this article are targeted for a two-machine scenario where both trading partners involved in a B2B scenario have their BizTalk Server setup.