BizTalk Server 2010 R2 Announced

In a previous post, I discussed Microsoft’s integration road map particularly related to Microsoft BizTalk Server.  The foundation of that post was based upon Tony Meleg’s presentation from the World Partner Conference.  The good news is that today, Microsoft has given us a glimpse into what is to come with respect to BizTalk Server.  Previously, Tony cautioned us that Microsoft will continue to support BizTalk and will introduce incremental changes to the platform.  Where as most of the innovation will occur in the Azure AppFabric space.

The next version of BizTalk Server is currently called BizTalk Server 2010 R2.  I suspect they are calling this an “R2” release since it is an evolutionary release that particularly focuses on platform alignment with Windows Server 8, SQL Server 12 and Visual Studio 11.  For those of you who do follow the BizTalk scene closely you may recall that BizTalk Server 2010 was originally called BizTalk Server 2009 R2 when it was in beta.  It was renamed to BizTalk Server 2010 prior to RTM.  So who knows if the BizTalk 2010 R2 name will stick but for now that is the name we will go with.

In addition to the platform alignment that I have already mentioned, we can look forward to some new features in the areas of:

• Adapter connectivity to new data sources including IBM Informix V11 and IBM IMS/DB V11
• Updates to industry schemas like HIPPA, HL7, SWIFT and SWIFTNet
• Improved Performance and Scalability
• Tighter integration with the Azure Service Bus
• Adjustment to licensing geared towards cloud hosting

Of the features mentioned, I certainly will not complain about improved performance and am happy to see tighter integration with Azure AppFabric.  I really hope that they introduce a smoother way of integrating with Azure AppFabric Queues and Subscriptions.

I am a little disappointed that there was no mention of fully supported REST endpoints, but it is early so I am hoping that Microsoft will surprise us with that feature.

I have only touched on some of the new features that will be available.  You can find the complete post from Microsoft here.

BizTalk: Adding BizTalk 360 to your Environment

For those that are not familiar with BizTalk 360, it is a Rich Internet Application (RIA) that allows you to monitor and maintain your BizTalk environment via a Web browser.  From what I can see, from a high level, there are a few components that you install in your BizTalk environment that make up the solution:

• Silverlight Application which can be accessed via a remote web browser
• WCF Service(s) that expose the operations to the Silverlight application
• A Windows Service that handles some of the monitoring and notification features
• A BizTalk 360 database that will store your configuration and audit/governance

My organization recently purchased a license and support from BizTalk 360.  In this blog post I plan on explaining some of the rational and features that influenced our decision.

Requirements

Over the past 5 years our BizTalk environment continues to grow.  With this growth comes more responsibility maintaining it.  Our current middleware team consists of both developers and administrators and therefore there is an on-call rotation that is used to handle the after hours support.  After hours support requirements are very binary; BizTalk’s infrastructure is either on or off.  This would include the core components like SQL Server, SSO, Host instances and applications being online.  We are not concerned if a single message is suspended.  The reason?  There is no one from the business available to consult with in order to correctly determine a resolution to the problem.

Also, in parts of Canada the IT Market is getting hot.  Let’s face it there is nothing fun, or cool about being on-call. Even though our environment is very stable, people felt that they were still tied down to their cell phone since we have Service Availability metrics to meet and when an issue occurs response time is very important.  As all BizTalk resources know, BizTalk doesn’t have to be down to get roped into “fire fighting” triage sessions.  Sometimes your large ERP or engineering systems go down and since BizTalk connects into them you are impacted as well. 

The company that I work for is very committed to employee retention and reducing the amount of on-call is a step in the right direction for reducing turnover and keeping employee morale high.

Solution

I know Saravana from the MVP program and at the last MVP Summit Saravana was showing MVPs and some of the BizTalk Product Group an early preview of what is now BizTalk 360.  My initial thoughts included what a nice looking application and some of the features fill a void left by the BizTalk Admin Console but I wasn’t convinced that I had an immediate use for it. 

While I was in Sweden in June, with Richard Seroter,  promoting the book I contributed to, I ran into Saravana again and checked out the progress his start-up made on the product.  Once again I was impressed with the tool but wasn’t sure how I would use it.

Come July and some more concerns about the on-call situation arose and this turned on a light bulb in my head about how we could use BizTalk 360 to help support our environment after hours.  We already have contracted resources that focus on after-hours support for our core infrastructure: Servers, SAN, Network etc.  I thought what if I could piggy back on this existing agreement?  Knowing that I didn’t need BizTalk Experts to keep an eye on my servers after hours, remember the type of service I am looking for is binary: on or off.  BizTalk 360 provides this visibility in a couple ways:

• Dashboard – By looking at this type of screen if is very obvious which artifacts are up and which are down.  Enabling these artifacts is a pretty easy action to perform so I don’t need to pay to have BizTalk Experts monitoring after hours.

 

• Notifications – My company also uses SCOM for monitoring BizTalk and we will continue to do so even with BizTalk 360.  But the feature that I like about BizTalk 360 is the Health Summary email notification that you can configure.  I can now subscribe this after hours team to periodic notifications where they can quickly, and easily, determine the health of the environment.  I don’t want these people logged onto my BizTalk servers hitting F5 all night inside of the BizTalk Admin Console.  Using these email notifications frees them up to work on other things but also provides the visibility that we need.

(Sample email notification – note I have added the black marks to retain some privacy)

Another area that is important to me is the Audit and Governance features that exist.  When trusting a 3rd party to provide support it is very nice to have an audit of what actions took place during support periods.  It protects both the client and the service provider and is a win-win all around.  This is a feature that has been missing from the BizTalk Admin Console that could benefit many organizations.

Overall the process of procuring the BizTalk 360 application has been very positive.  When I first tested out the product there were a few features missing that I really wanted.  Saravana took the time to review them over a Live Meeting, took my high priority needs and was able to provide me with a build on a committed timeline.  Some of my feature requests involve clustered host instances so if you use clustered host instances in your environment – you are welcome!

The BizTalk 360 team is very committed to the product and their customers.  It has been refreshing to work with a company that is so motivated.

Conclusion

Something that I have learned through this process is to always keep your eyes open to new trends and tools.  I find Twitter really helps in this regard by following likeminded individuals.  You don’t need to deep dive on every new technology that you see but it is important to know that it exists as you never know when your requirements may change and you can benefit from it.  Case in point my situation that emerged this past summer.

BizTalk: /n Software Read Only (S)FTP Locations

Another /n Software feature that I recently learned about involves Read Only FTP locations.  The idea behind this feature is the the source system does not want you to remove the file once it has been downloaded.  This could be for a variety of reasons including the file may be available to multiple consumers or the source system would like to archive the file once it has been consumed.

Read only FTP locations is a new supported scenario with BizTalk 2010.  /n Software has supported this scenario for at least a few years.  You can enable this feature by simply specifying the Delete Mode as Never on a Receive Location that is using the /n Software adapter.

So this is all very intriguing,  I am sure,  but it is pretty obvious so why does this deserve a blog post?  The reason for the blog post is to discuss a lesser known property called DownloadCacheFile. After scanning your receive location you will discover that this property is not visible.  This property is exposed through the Other property.  Within this property we can specify DownloadCacheFile=c:\myCacheFile.txt

As files are processed they will be added to this file and a record is kept so that they are not downloaded in subsequent polls of the (S)FTP location.

In the BizTalk 2010 implementation, Microsoft is using a database to store this type of information where as /n Software has chosen the file route.  Time will tell how well this feature works.  I would imagine that there is an upper limit where the file becomes so large that it slows performance or potentially corrupts.

Also note that if you are using a Clustered host instance to host your FTP Receive locations, this file should be in a shared storage location so that the Clustered host instance has access to it no matter which Server it is actively running on.

BizTalk: Configuring /n Software’s SFTP Adapter for Public/Private Key Security

I was recently involved in a project that required secure FTP connectivity between my organization and a partner organization.  We continue to leverage /n Software’s SFTP adapter as we are still running BizTalk 2009 in production and we also find that our partners tend to leverage Secure FTP using SSH (SFTP) as opposed to FTP over SSL (FTPS).  BizTalk 2010 now includes an FTP adapter that supports SSL so we are likely to continue to use the /n Software adapter based upon SSH requirements even once we upgrade to BizTalk 2010.

I am very far from being a Security/Certificate expert so I did learn a few things being involved in this project.  Hopefully if you have Secure FTP requirements that you will find this post helpful.

 

Generating Public and Private Keys

In my scenario, our trading partner required us to provide them with our Public key.  They wanted us to generate Private and Public keys.  They would then take our public key and install it in their SFTP server.  To generate these keys I simply used GlobalScape’s CuteFTP 8.3 Professional.

Note: Your mileage may vary here.  There are some requirements that were enforced by our Trading partner including the Key type and the number of bits required for encryption.

1. Click on Tools -> Global Options

2. Click on Create identity file

3. Use DSA

4. Provide a Passphrase

5. Enter a location for files to be generated and ensure the key length is set to 1024

Configuring BizTalk Receive Location

Since the Receive Location configuration is a little lengthy I am going to break it down into the various sections.

SFTP

Pretty basic settings here dealing with when we want to Delete, what file masks we want to look for and the folder on the remote SFTP server that we want to navigate to once we have successfully established connectivity.

SSH

The first area to focus on in the SSH section is the SSH Accept Server Host Key.  When you set the Accept Any  to Yes the SSH Accept Server Host Key property will revert to Any.  I equate this action with when you try to connect to an SFTP server using a client like CuteFTP.  You will get prompted with a dialog asking if you would like to accept the public key being pushed from the SFTP server.  The way I understand how this works is that this public key will get validated against your private key.  Should everything match up you should be able to establish a connection.

The next property to focus on is the SSH AuthMode.  We want to set this value to be Public Key.  There are a few different options when it comes to setting the Authentication mode.  One includes setting a password but for this particular partner they wanted to use Public Key authentication.  When we set this value we then need to provide the location of our private key which happens to be called Identity (without a file extension).

To provide our Private key we need to click on the ellipse button.

 

We will now be prompted with a dialog that allows us to select our Private key from a variety of sources.  In my scenario I wanted to select my key from the file system.  In order to do so I needed to select the PEM tab and then browse to my key.  Since I have enabled my key to use a password I need to provide a password and then I can click the Open button.  Once I did this my private key would appear in the TextArea box and I can click Ok.

The rest of the configuration deals with some connectivity details including the name of the FICTICOUS Host and a SSH User (a tribute to Steve Jobs who has recently stepped down from being Apple’s CEO) .  The SSH Port is using the default port of 22  and even though it appears as if I have provided a password that is the default mask provided by the adapter.

 

Conclusion

So as much as people love to talk about the cloud these days and using the Service Bus and WCF bindings, the bottom line is that companies continue to rely upon “legacy” technologies such as SFTP.  In my scenario, this trading partner is a very large institution so it is not as if they are a little “Mom and Pop” shop. 

BizTalk 2010 Training Kits now available

Both Developer and Administrator Training Kits have been recently released.  Inside of these training kit you can expect functional Virtual Machines, with the BizTalk software installed, training module documents and PowerPoint presentations.  This is the content that you would typically find in a Microsoft Official Curriculum course.  The best part about these kits is they are made available for free.

I had the opportunity to collaborate with Jerry Anderson from Pluralsight on the Administration course.  My contributions primarily focused on Module 6: Monitoring a BizTalk Environment with System Center Operations Manager (SCOM).

The BizTalk 2010 Developer Training Kit was released back in July and is available here.  The Administration course was released on August 21 and can be found here.

Enjoy!!!

BizTalk 2010: Line of Business Systems Integration Book has been released

For the past 10 months I have been involved in a project with 4 other talented individuals.  This project was a little different than the projects that I have been involved with in the past.  While other projects have always had some sort of documentation deliverable, documentation, in the form of a book was the main deliverable this time around.

While many BizTalk books exists, we felt there was an opportunity when it came to discussing Line of Business integration with BizTalk Server 2010.  With the amount of talent involved in this book, I am very confident we have filled some of the void that exists on this topic.

I would like the thank the following authors for their tremendous efforts:

• Richard Seroter
• Sergei Moukhnitski
• Thiago Almeida
• Carl Darski

I also want to thank our Technical Reviewers who spent a lot of hours reviewing our content and definitely increased the quality of the book:

• Ben Cline
• Stephen Thomas
• Mick Badran

You may now find the book available on the Packt Publishing site and on Amazon.com.

Sample Chapter available for upcoming BizTalk LOB Book

I see that Packt Publishing has included a link to a sample chapter in our upcoming book called Microsoft BizTalk 2010: Line of Business Systems Integration.  The sample chapter selected  is: Integrating with Dynamics 2009.  You can read more about the book here and can find the sample chapter download here.

I don’t have a publish date but I expect it to be imminent.  The content has been provided to the printer.  I will update this post once a publish date is available.

BizTalk Server still has a pulse

While this information is now well known and has been covered by both Richard Seroter and Saravana Kumar, I wanted to throw my 2 cents out there as I was away on vacation when this information was released. Now that I am back, I have had some time to watch Tony Meleg’s presentation from the  2011 World Partner Conference. I have a feeling that this “talk” will be one of those that is referenced for years to come.  Much like we continue to bring up certain “Scott Woodgate” talks.

 

A New Platform is born

For the past couple years, Microsoft has put significant emphasis on cloud computing and providing software and platform services that run in Microsoft’s data centers.  From a platform perspective, these investments have been made to Azure.  Today we have capabilities  to run Web and Worker roles, SQL and Azure Storage, Caching and relay messaging in a production environment.

Microsoft continues to invest in this platform and is increasing the amount of capabilities that are provided in this platform.  We are now starting to see some of the “middleware” capabilities being introduced in the form of CTPs that include Workflow, Pub/Sub and Queues.  A future CTP will showcase additional “integration” capabilities including pipelines that will host message transformations.

 

New Platform’s impact on BizTalk

It has been very clear that Microsoft is betting on the cloud and as a result all new software investments will occur in the cloud first and then make its way to on-premise. The first example of this strategy was the release of CRM 2011 which was available in the cloud prior to making its way into on-premise.  

To align with Microsoft’s cloud strategy, some tough decisions had to occur in order to include BizTalk functionality in the cloud.  A key area that had an impact on BizTalk’s ability to move to the cloud was in the area of Workflow.  A decision had to be made as to which “Workflow-ish” technology Microsoft would pursue between Windows Workflow Foundation and Xlang.  The driver for this decision was Microsoft’s desire to reduce the amount of duplication of efforts across their platforms.  As you can see from Tony’s presentation, Xlang did not make the cut.  In my opinion, it makes sense to decide upon Windows Workflow as it can be used outside of BizTalk and is already used in other platforms like CRM and SharePoint.   Tony does mention in his presentation that removing the Xlang Orchestration engine from BizTalk is like performing a major heart surgery and will take several years to fulfill.

Microsoft also has aspirations of ensuring symmetry between cloud and on-premise versions of its software.  The current BizTalk architecture just didn’t provide a good fit especially when consider the desire to reduce the duplication of efforts across platforms.  It was pretty clear that Workflow would be the engine of choice being a .Net based technology and its adoption by other platforms.

Another area that is at the top of customer’s “ask list” was more flexible messaging options.  While BizTalk’s current durable messaging is a core requirement for many customers, the ability to by-pass durable messaging in order to increase performance is a core requirement for others.  We have the ability to perform non-durable messaging with WCF and WF today so once again this is a natural fit over trying to change the existing BizTalk messaging engine.

Platform end state

Below is an image that I snagged from Tony’s presentation.  It represents the new platform’s “end-state” in terms of capabilities.  Within this diagram you should be able to find existing BizTalk capabilities and their alignment to the new platform including:

• Adapters
• Rules
• Pub/Sub
• Transformations
• Pipelines
• BAM
• TPM

We also have some enhancements or new capabilities not found within BizTalk natively like Caching, Web Apps, Workflow and the new Composition Model and AppFabric App Manager.  I have discussed a few of the Composition Model and AppFabric Manager on my other blog http://www.MiddlewareInTheCloud.com and am looking forward to “BizTalk” app development being able to leverage these features.  I was reminded of the convenience of the Composition Model when I recently deployed a BizTalk application to multiple servers that included deploying Web Services.  The BizTalk deployment model could be optimized in my opinion when it comes to distributed deployments. Yes there are tools that help like MSBuild and the BizTalk deployment framework but it should be simpler.  I would love to see the simplicity that the AppFabric Application model provides to “BizTalk” applications.

 

Timing

Tony asks people to “lower expectations” and “think long term”.  Microsoft recognizes that they will not be able to move existing BizTalk functionality to this new platform in either the cloud or on-premise any time soon.  It will take multiple releases to achieve the goals of the platform.  Their timeline is somewhere around 5 years.  In the mean time Microsoft is going to continue to release versions of BizTalk Server.  Yes, you read that right…BizTalk is not dead.  However, Tony cautions that we will not see a lot of innovation being baked into the new BizTalk bits.  The updates to BizTalk server will be to align to updated platforms like Windows Server, SQL Server and Visual Studio.  Updates may also include bug fixes or key customer asks that are reasonable to implement.  However,  the innovation will occur in this new platform.

In the short term, we will see features of the new platform being rolled out in the form of CTPs.  We shouldn’t expect the new middleware features to hit production until sometime in 2012.

(another image that I swiped from Tony’s presentation)

Migration

As we move from our existing platform to the new platform, we should be expect some pain.  Obviously Microsoft will take reasonable steps to ensure of smooth transitions to the new platform but we can expect some challenges along the way.  There will not be an “easy button”.

 

Guidance  (my opinion – take it as is without warranty)

The first piece of advice is: DON’T PANIC.  It is still early and nothing is written in stone at this point.  Microsoft has mentioned that this is a long term strategy and it will take multiple releases to address the vision.  In the mean time they will continue to support and release more BizTalk.  From a personal perspective, I am responsible for a Middleware team at a good sized Energy Distribution provider.  We run BizTalk 2009 and I can confidently say that our business runs on top of BizTalk.  If BizTalk goes down, many parts of our business slow down if not grind to a halt.  We have been making significant investments in BizTalk for over 5 years.  My intentions are to continue use BizTalk.  We have an upgrade planned in the next 8 months and that will be a BizTalk upgrade.  Most likely 2010, but if a newer v.Next release miraculously appears we will consider it.

From a developer perspective, this news is a bit of a wake up call.  It is time to start diversifying your skill set.  Microsoft is providing initial looks at this technologies through CTPs.  Get involved!  Download the bits, try them out and get familiar with some of the new concepts and models.  I don’t think there is any reason to be really nervous though.  The underlying core integration skills that you have built up over the years will not be for nothing.  Some of the terminology will change, the toolset will probably change but many existing integration patterns will continue to exist whether there is a “cloudy thing” or not.  If anything, I think there will be a lot of new opportunities for developers with Microsoft Integration skill sets.  There will be a lot of existing BizTalk –> New Platform migrations that will need to occur in the next 3-10 years.  Who better to work on these projects than people with BizTalk experience who have adopted the new technology.

First look at Azure AppFabric June (2011) CTP

Recently Microsoft has released another Azure AppFabric CTP.  This particular one focuses on Azure “AppFabric Applications” or otherwise known as “Composite Applications”.  The goal of Azure AppFabric Applications(as I see it) is  to build, deploy and manage multi-tier applications as a single logical entity in Windows Azure.

Coming from the BizTalk world I am very familiar with distributed applications.  Some of the challenges in developing and maintaining these types of applications is understanding all of the moving parts that are involved in these solutions.  AppFabric Applications is a step in the right direction as it provides a holistic view of our “stuff” that makes up a distributed application including Web Applications, Custom and 3rd party Services, Service Bus capabilities (Relay/Queues), Workflow and Storage(DB/Blob/Table). 

Managing, and understanding,  different application/solution tiers independently can be a bit of a nightmare.  One of the features of AppFabric Applications the ability to automatically generate a diagram that describes all of the core components of our distributed application and the related dependencies.

If we take a look at a diagram that describes one of the sample solutions we can quickly discover what our solution is made up of.  In this case we have a Web Application that will push data to an AppFabric Queue.  In turn we have a service that pull this data off of the queue.

So at this point you may be thinking “whoopee” I can draw that in Visio in 2 minutes.  Well Visio will not be able to deploy this entire solution to the cloud in the matter of a few mouse clicks.  Once this application is in the cloud we then have the ability to provision our various tiers by “turning a knob” or in this case pulling down a menu to select the amount of instances we require.

Another nice benefit is that we can trace and instrument our entire solution from once place.  This is another pain point of distributed systems.  There is usually logs all over the place that have to be aggregated to get a sense of the performance and health of an entire application.  This is another benefit of using Azure AppFabric Composite apps.

Unfortunately my experience with this technology is only in the Local Development fabric as I am currently waiting to get access to the “Labs” environment in Azure.  But if you check out some of the resources that I have outlined below you can see some demos of the Management features available in the Cloud.

Summary

Benefits:

• Ease of deployment
• Greater developer productivity
• Effortless scale
• Centralized managed and monitoring

CTP includes

• AppFabric Developer Tools
• AppFabric Application Manager
• Composition Model
• Support for running Custom Code, WCF and WF

What you need

Windows Azure AppFabric CTP SDK and Windows Azure AppFabric Tools for Visual Studio

Resources:

Before you start, I recommend watching the following videos:

• Channel 9 announcement video 
• Alan Smith’s webcast
• TechEd 2011 North America video

I also suggest you take a look at the Tutorials and Samples.

The Samples that are available include introductory apps like a StockQuote app that has a Web Front end and then consumes a back end service  to a Contoso Pizza application that includes a Web Front End that consumes a back end service which leverages some WF workflow.

Closing

This new CTP has me really intrigued.  I plan to investigate further and will blog more about my findings.

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.

Internal BizTalk Conference

Prior to the MVP Summit, Johan Hedberg and Mikael Håkansson stopped by Calgary and participated in a Mini-BizTalk Technical conference for my company and three other sister companies.  In addition to their presentations we had a round table discussion to find out how the other companies are using BizTalk and had two other presentations; one by myself and another by a colleague Luciano Barbieri.

 

Below you will find links to the various sessions.  I wish I would have recorded these sessions  as the demos were excellent.  Maybe next time.

• Johan Hedberg – BizTalk 2010 and Mapping best practices
• Mikael Håkansson – BizTalk Performance
• Luciano Barbieri – Automating BizTalk Builds
• Kent Weare – Extending your enterprise via BizTalk 2010 and the AppFabric Service Bus

Catching SOAP Faults from CRM 4.0 Web Services

A natural follow up to my BizTalk 2010: Calling Dynamics CRM 4.0 Web Services post is one that deals with the Exceptions, or Faults,  that these Web Services may return.  When using the CRM 4.0 Adapter, the adapter would take care of handling SOAP exceptions and bundling them up into a CRM Response message that had a Return Code and Error Nodes.  Whether your operation was successful or not, you could always expect the same type of response message from CRM.

<ns0:Response xmlns:ns0="http://schemas.microsoft.com/crm/BizTalkAdapter/Response">

<Header>

<ReturnCode>1</ReturnCode>

<ErrorCode />

<ErrorString />

<Retryable />

</Header>

Now that we are not using this adapter anymore we need to be able to catch our own exceptions coming out of CRM.  If we don’t perform these actions below(or similar actions) we can expect an error message like the following.

 

Inner exception: Received unexpected message type 'http://schemas.xmlsoap.org/soap/envelope/#Fault' does not match expected type 'http://schemas.microsoft.com/crm/2007/WebServices#CreateResponse'.

The issue is we have a Solicit Response Send Port in which  we are sending a typed Request message into CRM and are expecting a typed Response message in return.  When we encounter a SOAP Fault, a typed message is being returned, it just isn’t what we are expecting.  In order to avoid these situations, we need to perform the following actions within our BizTalk solution. 

Note: these actions are not specific to CRM, but may be used in other Web Service scenarios.

• Create a multi-part message that includes a part that is of type BTS.soap_envelope_1__1.Fault.  You will find this schema in the Microsoft.BizTalk.GlobalPropertySchemas assembly.

• Right mouse click on your selected operation and select “New Fault Message”

• Select the Message Type to be the value of our Multi-part message that we just created.

• Add a scope around your send/receive shapes.  The transaction type can be “None” and the Exception Object Type should be set to the Fault that we just created within our Operation.

• So while technically this is defined as a message, within our current scope exception handler it is actually an object.  So if we wanted to dump the contents of this message to the Event Viewer we could perform the following actions by assigning the message to an XML Document and then getting the OuterXml so that we can send this text into the event viewer.

• At this point we can stop if we are so inclined.  If we wanted to actually use this information in our CRM Response message we can assign this “exception” object into an instance of a message that is of the same type (our multi-part message). 

 

• We then can use a Message Assignment shape to assign this object into an instance of our message.

• Now that we have a typed message, we can use this message in a map to instantiate an instance of our CRM Response.  To keep things simple I am just going to concatenate the faultcode, faultstring and faultactor values and assign to the CreateResult node.  If we wanted to get the actual details out, we will need to write a .Net helper method or use XSLT to extract this content out since we have an untyped “Any” node.

• After all of these changes, our Orchestration should look like this:

• We can now deploy our application and test it.  In order to generate a SOAP Fault, I am going to send in the same message as in my previous post, but this time I am going to make the First Name to be greater than 50 characters.

• Now when we process this message, we will not get an unhandled exception or suspended message.  Instead, we will see an informational message in our event viewer that contains the details that we are interested in.

• Also, we will send this error information to a folder in the form of a CreateResponse message that will include some SOAP Fault details.

<ns0:CreateResponse xmlns:ns1="http://schemas.microsoft.com/crm/2007/CoreTypes" xmlns:ns2="http://microsoft.com/wsdl/types/" xmlns:ns3="http://schemas.microsoft.com/crm/2006/Query" xmlns:ns0="http://schemas.microsoft.com/crm/2007/WebServices" xmlns:ns4="http://schemas.microsoft.com/crm/2006/Scheduling" xmlns:ns5="http://schemas.microsoft.com/crm/2006/WebServices" xmlns:ns6="http://schemas.microsoft.com/crm/2006/CoreTypes">

<ns0:CreateResult>soap:Server - Server was unable to process request. -</ns0:CreateResult>

</ns0:CreateResponse>

 

Note: some other blog posts mention using an XPATH statement, within our WCF Send Port,  for both types of messages that we are expecting; typed CRM response and SOAP Fault.  In my scenario, this step was not required since I am expecting a typed SOAP Fault exception object within my Scope – Exception handler.