We’ll I just spent about three hours tonight fighting with this issue, so I thought I’d post about it to hopefully save someone else from having to go through this.
I was trying to run a couple of samples from the ESB and I noticed that whenever I used an example that had to use an orchestration, I received the following error in my event log
Event Type: Warning
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5410
Time: 4:08:39 PM
An error occurred that requires the BizTalk service to terminate. The most common causes are the following:
1) An unexpected out of memory error.
2) An inability to connect or a loss of connectivity to one of the BizTalk databases.
The service will shutdown and auto-restart in 1 minute. If the problematic database remains unavailable, this cycle will repeat.
Error message: Exception has been thrown by the target of an invocation.
Error source: mscorlib
My host instance would then shut down and try to restart itself every minute. Each retry would fail with this same error. I also ended up with a running service instance in the admin console that I couldn’t terminate.
Each time I sent another message, I would have to manually clean these left over instances from the DB before I could restart the host instance successfully. I finally noticed that this error was only occurring whenever a component in my “In-proc” host instance tried to run. Base on this I tracked the issue down the btsntsvc.exe.config file that we were suppose to edit during install. I had forgotten to remove the “[path]” place holder that is in the <ConfigurationFile> tag. We were suppose to replace this with the actual path to the Microsoft.Practices.ESB.PipelineComponents.config file. (I’ve did not have this step in my install checklists, so I have since added it). I realized that the AppDomains were not loading correctly and this caused my errors in every orchestration in that tried to run in that AppDomain.
This is what I had left in my config file:
As I said, I had forgotten to replace the [path] place holder. Anyways, I put in the proper path and I expected this to correct the situation, but I kept getting the same annoying error. After another hour of frustrated debugging, I realized that I had entered the config data like this:
You’ll notice that I had put line breaks before and after the path and filename. It was these dam line break that were causing the problem. I took them out and and used this:
Everything worked fine and the issues are gone.
I’ve seen a number of people asking about this on codeplex and other locations, so double check your settings and avoid the headaches.
Cheers and keep on BizTalking…
I’ve been meaning to post this stuff for a while and now finally gotten round to it 🙂
Venkatesh (RFID lead architect) before Christmas ran through a first teach of our
RFID Course in Singpore + China.
One piece of feedback that came out of the course was that the existing MS RFID DLP
Provider gave a few problems with quick consecutive tag reads – and would cause the
Provider to stop. (and the other important thing is that the DLP Reader – didn’t beep when
reading a tag)
So whether Venkatesh could sleep one night or not, he’s come up with a new and improved
DLP Provider that relies on a COM interface.
Grab the updated files here….
(13.81 KB) – BizTalk RFID LogFile Viewer – can’t leave home without this one 🙂
If you have been keeping up to date with developments within the Connected Systems Division within Microsoft you will be aware of the “Oslo” initiative. Microsoft has released information about this here, and Charles Young has a very informed summery of the initiative here.
I’m not going to discuss too much about what Oslo is, what I will look at is how current and future BizTalk developers can start to consider the impact that Oslo will have on development, and how we can start looking at technologies and developing skills that will be relevant on the new platform. This is just my opinion, as a BizTalk developer I’m keen to keep up to date with new developments, and I’m currently following these guidelines myself.
The first version of Oslo is scheduled for release sometime in 2009, which means we may see TAP, CTP and Beta releases sometime in 2008. If you are a seasoned BizTalk developer or a newbie, Oslo will have a major impact on your development over the next few years. So how should we go about navigating the road to Oslo?
What if I am a BizTalk 2004/2006 developer?
It remains to be seen what the general architecture and feature set for the first release of Oslo will look like. One thing that Microsoft has promised us is that “nothing is going away”, meaning that we will still be able to develop using the tools that we are familiar with, and the applications we are developing today will still work on the new platform. This is very different from the transition from BizTalk 2002 to 2004, when people were saying that having no knowledge of BizTalk 2002 was an advantage to learning 2004, and migrating applications was often more of a re-write than a migration.
We are already seeing some of the technologies that may be refined to make up parts of the Oslo platform; some of those are available in BizTalk Server 2006 R2, others as side projects. These are discussed in the “How do I get a head start in Oslo” section. If you are working with BizTalk today and want to start planning for the future, it’s maybe worth spending time checking them out.
I need to start an integration project, should I use BizTalk 2006 R2?
Absolutely. Since the 2004 release BizTalk Server has been the natural choice for developing integration solutions on the Microsoft platform. The feature set has been strengthened considerably in the 2006 and 2006 R2 releases, including strong EDI and WCF support in 2006 R2. As mentioned earlier “nothing is going away”, so if you need to start a project in the near future, BizTalk 2006 R2 is still the best choice.
When we get nearer the release dates, have more concrete information on the architecture and feature set, and CTP or Beta releases become available the choice of going for Oslo may start to become an option. There may be a chance to become involved in the TAP program and have early access to the bits. Bear in mind that in the early days Oslo will be a very new platform, whilst BizTalk has a wealth of documentation, knowledge, books, courses, blogs, and community experience, Oslo will be a voyage of discovery for everyone, and you will need to plan for this in your development cycle. If, like me, you were an early adopter for BizTalk Server 2004 you will know what I’m talking about.
I want to start learning about BizTalk, what should I start looking at?
Depending on your experience it can take up to twelve months to become a proficient BizTalk 2006 developer (I’ve been hard at it for over four years and am still learning new stuff about the core BizTalk engine). As Oslo is scheduled for a release some time in 2009, we may well see public Betas and CTP releases within twelve months. If you are planning on learning BizTalk to strengthen your CV it may be more worthwhile looking at the new technologies that are becoming available rather than learning BizTalk Server 2006 R2.
As Microsoft are keeping many of the details about the Oslo feature set under wraps it may be the case that if you spend the next twelve months learning 2006 R2, things change significantly and you will be back to the tutorials again. It could also be the case that your 2006 skills are very relevant and applicable to the new platform, so again it’s a bit of a gamble.
One thing we can be certain of is that WCF will increase in importance in the BizTalk feature set, and WCF will be more applicable to general development as well. If you have the time to develop your skills, you could consider looking at the WCF features in the current BizTalk release, and other related technologies, (BizTalk’s WCF adapters, WCF LOB adapter SDK, BizTalk Labs). The next section will discuss these technologies.
How do I get a head start in Oslo?
There are a number of technologies that Microsoft has been releasing that may, in a more mature form, go on to form part of Oslo. If you are keen to get ahead and stay ahead on the Oslo platform it would be well worth investing some time in them. Be aware that plans change, promised features change, and strategies change (remember “Jupiter”?), so be aware that investing time in the bleeding edge technology can be a gamble.
If you are keen to be an Oslo early adapter, here’s some stuff to look at: (Be aware that this is just my personal opinion.)
Windows Communication Foundation
WCF is becoming increasingly important on the Microsoft platform, especially the “Connected Systems” projects. If Oslo is to be a SOA platform, WCF will be the foundation that platform will be built on. We are already seeing WCF being adopted in the BizTalk product line (WCF adapters in R2, WCF Line of Business Adapter SDK, BizTalk Adapter Pack, BizTalk Labs), expect this trend to continue. Having a solid knowledge of WCF will likely be one of the core skills required for the Oslo platform.
Considering the importance of WCF on the Microsoft platform, it should be on most developer’s to-do lists. If you run Vista, or can run a virtual image with Server 2008 (you need a fast PC to do this!) check out hosting WCF in WAS.
Windows Workflow Foundation
WF has been around for a while now, and it has been discussed as a replacement for the BizTalk Orchestration Engine in BizTalk vNext ever since it appeared. As we know that the Orchestration Engine will still be present (“nothing goes away”), it remains to be seen how much of an impact WF will have on Oslo development. If Microsoft can deliver a solid workflow host with comparable development and management tools to the current orchestration designer, WF may be the weapon of choice for building business processes. As we know Oslo will be a long term strategy, there is a chance that we may still be choosing to build orchestrations rather than workflows on the early versions of the platform. It will be a while before we can make a decision on this.
If you will be looking at WF, the integration between WCF and WF in .net 3.5 looks like something worth exploring. The first version of WF had no concept of sending and receiving messages, the core functionality of most BizTalk orchestrations. In .net 3.5 we have a SendActivity and a ReceiveActivity, allowing WF workflows to publish and consume WCF endpoints. WF may be a skill worth having, but I’d prioritise on learning WCF if you are limited for time.
WCF Line of Business Adapter SDK
Microsoft’s strategy to migrate adapters to use WCF instead of being dependent on BizTalk makes a lot of sense. In the future we will be using .net adapters, rather than BizTalk adapters. The BizTalk Adapter Pack is making a start on this move; expect to see more adapters migrated in the future.
A great way to learn about the new adapter framework is to download the WCF LOB adapter SDK and take a run through the tutorial. Even if you are not going to develop your own adapters, it will give you an insight into how the new adapters will be built, it’s also great to look at the more advanced aspects of WCF development.
BizTalk Labs is a pilot project to investigate the use of an Internet Service Bus (ISB) in connected system development. The future of BizTalk labs has not been determined, but there is a good chance that one of the aims of running this project is to prototype ideas that may form part of the Oslo platform. If you want to explore BizTalk labs, there is an SDK to download, and you will need to set up an account. As it’s an experimental project it’s not guaranteed that the servers will running 24/7.
The relevance of BizTalk labs to the Oslo platform will not become clear for a while (the FAQ is worth reading for more info), so investing a lot of time learning them is a bit of a gamble, but it may well pay off in the future. BizTalk labs uses WCF as a framework, rather than BizTalk, so it’s another chance to get more WCF experience.
It’s all about WCF
The WCF-WF integration in .net 3.5, the BizTalk WCF adapters, the WCF LOB adapter SKD and BizTalk Labs are all based on WCF as their foundation. It’s fairly easy to conclude that WCF is going to be the key technology to understanding and leveraging this new wave of products.
A couple months back I wrote a short post explaining some simple BizTalk Server 2006 R2 + Windows Communication Foundation scenarios. Afterwards, I was approached by the folks at TopXML.com to write a series of articles that provided depth on BizTalk + WCF integration.
So, I’ve begun a multi-part series of articles that explain many of […]
Fellow pilot and talented IT professional, David Megginson, put out neat web site http://www.ourairports.com that allows to leave comments about airportsvisited (as pilotor passenger), and share personal maps. I added those whereI landed as a pilot from the logbook and it shows how I definitely need some real “cross country” trips 🙂
This post is based on something we experienced recently. When we activated some more file receive locations against a machine to which we previously had a bunch of receive locations configured, after a while they began to become disabled, one after the…(read more)
Great news! When I attended and spoke at the Microsoft SOA & Business Process
Conference I was informed that they were recording all sessions to be included in
a DVD of the event which would be sent out to those who had attended. Great,
wonderful, but not a lot of use to my blog readers. Well shortly there after
I received a request from the TechNet team to include my presentation as part of the
“Best Of” from event online. I happily agreed, and am happy to report that the best
of the Microsoft SOA & Business Process Conference can now be found on TechNet,
and that my
presentation on Building HIPAA solutions with BizTalk Server 2006 R2 is amongst
them. Incidentally apparently I received a 5 of 5 rating during the conference,
I thank the attendees for being so easy on me.
This talk is actually very relevant to anyone interested in EDI for BizTalk Server
2006 R2 as the HIPAA specific pieces are few. It is a good introductory talk,
it is not a deep internals talk but it does cover the configuration and setup of EDI/HIPAA
in R2 in some depth. If you’re interested in this topic and can’t get to an
event where I’m speaking, this is a nice alternative.
Tim Rayburn is a consultant for Sogeti in the Dallas/Fort
In an effort to gather more customer feedback on our Visual Studio 2008 developer exams,Microsoft hasextended the beta periods for the following tests:
* 71-502: TS: Microsoft .NET Framework 3.5, Windows Presentation Foundation Application Development – Extended through Feb 8, 2008
* 71-503: TS: Microsoft .NET Framework 3.5, Windows Communication Foundation Application Development – Extended through […]
Students frequently ask my opinion on which BizTalk Books will be most helpful. I have reviewed several books, and will recommend a few of them here. I haven’t really seen any terrible BizTalk 2006 books (and believe me, I have seen some terrible technical books in the past!), so this is really a ranking of several really good books. It should be noted that many of the books below mention BizTalk Server 2006 R2 only in passing, because they were all written prior to the release of R2. I do not know if updates are planned for them.
In the interest of full disclosure, I should mention that QuickLearn has received a slew of books from Apress that we occasionally pass out in classes (thanks, Apress). Also, Darren Jefford, the author of one of the other books, is a friend and has provided signed copies of books that we have given away at various conferences. Despite my affiliations, I hope to provide a fair assessment of the literature.
The top of my list is Professional BizTalk Server 2006, by Darren Jefford, Kevin B. Smith, and Ewan Fairweather, published by Wrox Publishers. "Wrox" is pronounced like "Rocks," which is exactly what this book does. It’s very telling that, as I was writing this post, Amazon has eight listed reviews, and all eight give the book full marks (five stars) – I would definitely give it the same. Because this book assumes a moderate level of existing BizTalk knowledge, it is definitely not a good book to learn BizTalk from scratch (it's a great companion book to our Deep Dive). Nevertheless, it's a book by three guys who have been there, done that, and own the tee shirt when it comes to BizTalk implementation. This is a book that I refer to frequently.
Coming in at a close second on my list of favorites is Pro BizTalk 2006, by George Dunphy and Ahmed Metwally, published by Apress. (These books share more than a similarity in their names!) This is also an excellent book with very similar coverage to the Wrox book (Deep Dive level). If you own either of these books, you’re in good shape. I prefer the writing style of the authors of the Wrox book, but you may like this one better. Either one or the other of these is great, but you probably won’t need both.
If you’re looking for a book for someone totally new to BizTalk, consider Foundations of BizTalk Server 2006, by Daniel Woolston, published by Apress. This book contains good, concise description of common BizTalk terms (BizTalk vocabulary on steroids), and is a great pre-class primer for QuickLearn's BizTalk Server Developer Immersion. If you've already attended any of QuickLearn's BizTalk classes, you will probably find this book overly simple.
If you've identified a problem in your design/development, and you're looking for a quick way to solve it, your best choice is BizTalk 2006 Recipes: A Problem-Solution Approach, by Mark Beckner, Ben Goeltz, Brandon Gross, and Brennan O'Reilly, published by Apress. This may not be the best book for learning BizTalk from scratch, but it's a necessity for every BizTalk shop. This book takes a no-nonsense approach to "Here’s the problem, now how do I fix it?", and identifies the implementation of the patterns necessary to solve the problem.
Although not a BizTalk book, per se, a good general overview of messaging and other integration patterns can be found in Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, by Gregor Hohpe and Bobby Woolf. DO NOT EXPECT TO LEARN ANYTHING ABOUT BIZTALK FROM THIS BOOK! I am recommending this book as an excellent resource about integration in general non-Microsoft terms; however, many BizTalk-related documents, available from Microsoft sources, reference the patterns revealed in this book. So do the BizTalk 2006 scenarios (more on these later, if you aren’t familiar with them). Gregor maintains a site http://www.eaipatterns.com that contains much of the information available in the book, but the book still makes a great paperweight, (it’s big and hardcover) J. I have been referencing it in my classes for so long that I thought I better mention it here as well.
We have documented and posted all the error messages for RFID, SSO, EDI and WCF for the event log. See the links below:
%u00b7 RFID: http://msdn2.microsoft.com/en-us/library/bb968047.aspx
%u00b7 SSO: http://msdn2.microsoft.com/en-us/library/bb899027.aspx
%u00b7 EDI: http://msdn2.microsoft.com/en-us/library/bb968069.aspx
%u00b7 WCF: http://msdn2.microsoft.com/en-us/library/bb899069.aspx
If there are more areas we need to document, please send us the feedback.