New Class for BizTalk Administrators Goes Even Deeper than Ever Before

I think I can speak for everyone here at QuickLearn Training when I say that I am proud to announce the upcoming release of our BizTalk Server Administrator Deep Dive course! It has been a long labor of love in which I’ve invested an incredible amount of time including many late nights.

We are coming down the home stretch of development of this course, and I’m so excited that I wanted to share the three things about the course of which I am most proud.

A TRUE TECHNICAL DEEP DIVE

This class is a true deep dive into BizTalk Server technologies. Our primary goal for this class is to teach people how to be the best BizTalk Server administrators by teaching them more than how to do their job; we wanted to teach them how BizTalk Server does its job. I don’t want to reveal too much here but we have many detailed discussions about the internal mechanisms of BizTalk Server which provide greater understanding of why we do the things we do on Planet BizTalk.

This is the thing that makes me most excited for this class; I cannot wait to have these conversations with other experienced and interested BizTalk professionals.

PERFORMANCE TESTING AND TUNING

Everyone knows that performance testing and tuning is important in order to ensure that your BizTalk Server implementation is successful, but sadly there is very little practical guidance showing you how to do it. We spend about three days of the course focusing on running performance tests, identifying performance bottlenecks, and eliminating those bottlenecks. We look at how you can improve performance by changing hardware, reconfiguring network infrastructure, optimizing the underlying Windows Operating System, and other ancillary services. We also walk you through a variety of advanced configuration options for BizTalk Server databases and hosts.

This is where we’ve spent the most amount of time designing the course. I’ve personally spent weeks running performance tests so I can better understand how these changes affect performance and so I can prove to you the impact that a particular optimization might have.

Performance Monitor

ANALYZING THE IMPACT OF THROTTLING

I have one word for you: Throttling. Other than the MessageBox database I cannot think of single component in BizTalk that can have greater impact on performance than throttling. I know it is so clichéd now, but Stan “the man” Lee once said “With great power comes great responsibility”. The sad reality however is that there are so many people who’ve shirked all their responsibility when it comes to throttling.

I have enough faith in my fellow BizTalk professionals to believe that this is not because of carelessness or a general disregard for efficiency but instead stems from a lack of understanding; which isn’t surprising considering the amount of documentation and guidance coming out of Microsoft. We’ve worked hard to create the most comprehensive explanation of throttling including practical information that will finally demystify it forever.

Rate-Based Throttling

CLOSING THOUGHTS

I hope that this small insight into the upcoming BizTalk Server Administrator Deep Dive course has sparked your interest in the course. We are currently in the process of testing labs and editing slides and expect to have the course ready later this summer.

You can expect to see it on our calendar starting in July 2014. It will be offered publicly allowing anyone from anywhere in the world to attend remotely or if you prefer you can attend in-person at our state-of-the-art training facility based in Kirkland, WA.

BizTalk Server 2013 Beta Released

It’s finally happened!! Microsoft has officially opened a public beta for BizTalk Server 2013. The beta bits can be downloaded here.

Here are my personal top 5 new features of BizTalk Server 2013. I know that many of my customers have been asking for some of these features for a while.

  1. Too many new adapters to keep up with
    • Integration with RESTful services – new BizTalk adapters provide CRUD operations using REST endpoints.
    • New and Improved SharePoint adapter – Previous SharePoint versions did not support client-side API calls so the BizTalk Adapter required installing a special web service on the SharePoint front-end server(s). SharePoint 2010 and the soon-to-be-released SharePoint 2013 both support client-side API calls. The new BizTalk Adapter for SharePoint takes advantage of these client-side APIs to provide an easier, more seamless integration experience.
    • Azure Service Bus integration – adapters to connect to Azure Service Bus endpoints
    • SFTP adapter – If I had a dime for every time someone asked about an SFTP adapter…
  2. ESB Toolkit 2.2 – while the internals of the ESB Toolkit is largely untouched, the latest release boasts a better configuration experience, and full-fledged support.
  3. Dynamic send port configuration – You can now specify which adapter handler your dynamic send port will use rather than being stuck with the default handler.
  4. Artifact Dependency Tracking – The BizTalk Server Administration console provides better explanation of dependencies among artifacts (for example, orchestration X requires: schemas Y and Z).
  5. General Performance Improvements – Significant changes under the covers has improved the performance of send port when using ordered delivery as well as the mapping engine

Although not available yet, I’m also excited that a new Azure VM with the BizTalk Server 2013 Beta is on its way.

I’m also pleased to announce that QuickLearn Training is diligently working on new versions of all of our Developer and Administrator BizTalk Server courses designed for BizTalk Server 2013.

BizTalk Orchestration Port Bindings

There are a lot of conflicting ideas out there regarding orchestration/logical port binding options for BizTalk server. In this post I want to provide a short description of each option and some best practices for use.

· Specify Now/Specify Later

These two are commonly referred to as Static bound ports. Both of these options will require that the orchestration port is associated with a physical port before the orchestration can be enlisted or started. The difference between the two lay in the creation of the physical port.

Specify Now requires that you specify the configuration of the physical port inside Visual Studio before the orchestration assembly is compiled. The physical port configuration is baked-into the assembly and will be created in the run-time environment automatically when the assembly is deployed. This is considered the worst port binding option as the created physical port will have the same configuration each time the assembly is deployed. Also, the name of the automatically created port is pretty ugly.

Specify Later is essentially the same in function, but the definition for the physical port is done exclusively in the BizTalk Server Administration Console. This provides more flexibility for port configuration, such as having multiple logical ports connected to the same send port or binding the logical send port to a send port group. This is the more acceptable form of static binding, but shouldn’t be overused especially in cases where subscribers are likely to change over time.

· Direct (Partner Orchestration)

This enables two different orchestration models to communicate with one another. The two orchestration ports must use the same port type. A send port in orchestration A will publish the message to the MessageBox and a receive port in orchestration B will subscribe to the message. The logical ports used for this type of communication will not be displayed in the orchestration configuration options in the BizTalk Server Administration Console. The biggest concern when using this form of binding is that the connection between the two orchestrations is static and can only be changed through modifications to each orchestration and then recompiling.

· Direct (MessageBox database)

This option provides the purest use of the publish/subscribe architecture. A logical receive port that uses this binding will have a subscription that includes only the MessageType used by the logical port operation and the conditions defined in the Filter Expression of an Activating Receive shape. This means that potentially ANY process can feed that orchestration.

A logical send port that uses this binding will publish the message and assume that there is at least one subscriber for it, but there could be many subscribers (i.e. orchestrations, send ports, or send port groups). Assuming that the right subscriptions exist; this type of send port could feed any other process.

Things to beware of: (1) Invisible Subscriptions – there’s no reliable way to see which processes will feed your orchestration or which processes your orchestration will feed; even across application boundaries. (2) “Infinite” loops –the orchestration publishes a message that creates a new instance of the same model, which will publish a message that creates a new instance of the same model…

Upsides of Direct bound to the MessageBox: (1) Very loosely-coupled design – there are no direct dependencies or static relationships between publisher and subscriber. (2) Rip and replace-ability – with appropriate project partitioning, an orchestration could be replaced without affecting upstream or downstream processes.

· Direct (Self-Correlating)

This option exists to enable “callbacks” to the parent orchestration from a child orchestration when the Start Orchestration shape is used. The parent passes an instance of the logical port as a parameter to the child orchestration during invocation; therefore providing the callback channel used by the child to send a message back to the parent later on in the process.

· Dynamic

This option only exists for send ports. Dynamic ports enable you to assign the address used for transmission of the message on an instance-by-instance basis. Typically an orchestration will include a resolution mechanism that determines the address used for that instance and assigns it to the message being published by the logical dynamic port. Logical dynamic ports are bound to physical dynamic ports which look at the previously set address information to know which adapter and address to use for transmission.

This seems like the coolest of the send options but I’ve seen a lot of overuse around the dynamic send ports (especially in the ESB toolkit). The line in the sand I use for deciding whether to use it or not is this: “Do I know the address before I get the message?” If yes, use static physical send ports and role links. If no, ask “Does the message tell me where to send?” If yes, uses dynamic send port. If no, sounds like a big problem.

The perfect example for using a dynamic send port is this: I have a form on the internet; people fill out the form and click Submit. The submitted message is received into BizTalk where some processing is done. At some point during that processing I need to create an email that is sent back to the person that submitted the original message. I can create an orchestration that looks at the email inside the submitted message and assigns it as the address used by that later send.

I hate to see addresses statically stored in custom databases or configuration files and then assigned as the address of a dynamic send port. It really just creates an extra layer of management.

I hope this helped you out on your future BizTalk endeavors, and always remember it doesn’t matter the binding option you use logical ports are only used for communication between orchestrations and the MessageBox database.

New BizTalk 2010 Training from QuickLearn

Last year was a busy teaching year for me. I taught 35 BizTalk training courses to over 385 BizTalk developers and admins around the world. I received lots of great feedback from our students on ways to improve on our BizTalk Server training. This has resulted in complete rewrites of our BizTalk 2010 Developer Immersion and BizTalk 2010 Developer Deep Dive to make our BizTalk Server 2010 courses even better than ever. Here is a summary of what’s new in these two classes…

BizTalk 2010 Developer Immersion

This class is still intended for students who are new to developing BizTalk Server solutions. However, we have re-written all of the hands-labs to provide a less-traditional end-to-end scenario that I think students will really enjoy working with. We’ve also abandoned the use of step-by-step instructions in later labs. Essentially, we show students how to perform a task one time and then make the assumption that they will be able to repeat the process on their own as they progress through the course. This learning style changes the dynamic of the labs and requires students to apply what they have learned instead of just following written instructions. This makes the lab experience more challenging and much more rewarding.

Also, we have added optional challenge labs for students who want to dive deeper into more advanced BizTalk development topics during open lab time or by remoting into our lab environment after hours. For example, we have challenge labs for students who want to learn about EDI integration, how to process HIPAA healthcare documents, how to write application deployment scripts, and many more. We have also added new modules that cover tracking and troubleshooting of BizTalk run-time errors and BizTalk project planning and management.

BizTalk 2010 Developer Deep Dive

In the past we have had some problems with the leveling for the Deep Dive class. We kept getting too many students with little or no experience with BizTalk, who were not prepared for an advanced BizTalk course. As a result, students were often left behind or the instructor had to water down the training to meet their needs.

After much deliberation we finally decided that it was time to make the Deep Dive class exactly what it should be, very advanced! In this class we absolutely hit the ground running. There’s no time for “introduction to…” conversations. We assume that students already know everything that is taught in the BizTalk Immersion class and crank the dial to 11 with over 30 hands-on labs! We cover all the fun things in BizTalk like: custom components (pipeline and functoids), loosely-coupled orchestration patterns (call/start orchestration shapes, direct-bound ports), convoys, calling pipelines in orchestrations, failed message routing, and more. In fact, this is probably the most fun I’ve ever had while teaching a BizTalk class.

Whether you are new-to-product or a seasoned BizTalk developer, we have the best training to fit your needs. Check out 2011 training calendar for upcoming classes.

kick it on DotNetKicks.com

Building Expert Series training for BAM

Over the past month I’ve been working really hard on our new BizTalk Expert Series class for Business Activity Monitoring. I have to say that I’m really excited to start teaching it. In three days, we manage to cover almost everything one could want to know about BAM. The most interesting part of it for me is the data consumption lab. I’ve never been very fond of the BAM Portal. It’s nice, but certainly not something that I’d like to parade in front of a CEO of a big company. Don’t get me wrong, the capabilities are awesome, but the way it looks and some of its behaviors aren’t the best. In the consumption lab, we examine how to create custom consumption models for BAM data using PerformancePoint, SQL Reporting Services, and an AJAX based web site. I’d never worked with PerformancePoint before and I was surprised by how easy it was to create a dashboard based on the BAM OLAP cube.

Resuming Suspended Messages

Last week while teaching the BizTalk Developer Immersion, I was demoing how to resume suspended messages using the BizTalk Group Hub. I submitted six messages while my send port was stopped, so all the messages were suspended. I was foolishly trying to show my students that if I resumed the message, it wouldn’t be processed because the send port was in a stopped state. I resumed the message and it disappeared, actually, it went out through the send port. This confused me, I had six suspended messages, I resumed one and it was processed so I only had five. But why? I couldn’t figure it out, the port is stopped, the message shouldn’t be processed but if one went through why not all of them. I was stumped, then it occurred to me. If I were in production there are dozens of scenarios where I could have dozens or hundreds of messages in the MessageBox waiting for my send port to start, but before I actually start it all up, I want to send a few specific messages as a test. By stopping the port I can see all the messages that the port subscribes to and choose which ones should go through. So now I think it’s pretty cool.