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.

BizTalk 2010: Calling Dynamics CRM 4.0 Web Services

The project that I am on ran into a critical and somewhat embarrassing situation this past week.  As we moved from a single node project environment into a multi-node test environment we discovered that the Dynamics 4.0 Adapter cannot be installed on multiple BizTalk Servers in the same group.  Yes – you read that correctly.  I have never heard of this kind of limitation and struggle with the idea the adapter was actually made available without this feature.  You can read more about this limitation in the FAQ section here.

With this in mind, we needed to quickly make a 180 degree turn.  I had heard of other people calling the ASMX CRM Web Services from BizTalk via WCF Adapter.  The process of consuming these ASMX services is much like consuming any other Web Service.  That is until you start your application and get the dreaded 401 Unauthorized error. 

 

System.ServiceModel.Security.MessageSecurityException: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized

This seems like a pretty common error within the BizTalk and CRM forums.  However, I was not able find any resolutions to the issue.  It wasn’t until I started stepping through a .NET SDK sample that I realized that I was missing something and that was a required SOAP header.  For your convenience I have built an end to end sample that will walk through creating a Lead within a Dynamics 4.0 system. Keep an eye open for the Message Assignment shape where I assign this header.

• Once we have created a BizTalk project we need to “Add Generated Items” and then select “Consume WCF Service”

• Even though Dynamics 4.0 still uses ASMX style Web Services we can select “Metadata Exchange (MEX) endpoint.

• Enter the location of your CRM Web Service i.e. http://server/MSCrmServices/2007/CrmService.asmx and click on the “Get” button.

• Once the WSDL definition has been loaded, click the “Next” button to continue.
• Click “Import” to create your schemas and sample Orchestration.
• You should find that the following artifacts have been added to your BizTalk Solution.

• Our “main” schema is called CrmService_schemas_microsoft_com_crm_2007_WebServices.xsd.  Within this schema you will find all of the available Actions (Create/Update/Delete/Fetch etc) and the related entities (both custom and out of box).  In this scenario we are going to create a “Lead” within our CRM system.  So we can find the “Create” node and then scroll down and find the “Lead” entity.

 

• To keep things simple, I have created a little helper message that I will use in a Map to create an instance of this CRM Create message.

• Inside my map, I will simply map from this helper message to the actual CRM Request.

• With the building blocks in place, the next step was to update the  Orchestration that was generated for us.  Pretty standard stuff going on here.  We want to receive an instance of our “helper” message, transform it, send the request to CRM and then write the response to disk. 

• When we generated our CRM schemas, BizTalk also created a Port Type called “CrmServiceSoap” that contains all of the available operations including “Create”.

• Earlier in this post I mentioned that we need to set a SOAP header on the CRM Request message.  In order to do this we want to add a Message Assignment shape after our Transformation shape.
  
• Within this shape we want to set the following:

msgCreateCustomer (WCF.OutboundCustomHeaders) = "<headers><CrmAuthenticationToken xmlns=\"http://schemas.microsoft.com/crm/2007/WebServices\"><AuthenticationType xmlns=\"http://schemas.microsoft.com/crm/2007/CoreTypes\">0</AuthenticationType><OrganizationName xmlns=\"http://schemas.microsoft.com/crm/2007/CoreTypes\">YourOrganization</OrganizationName><CallerId xmlns=\"http://schemas.microsoft.com/crm/2007/CoreTypes\">00000000-0000-0000-0000-000000000000</CallerId></CrmAuthenticationToken></headers>";

• The two important settings are the “AuthenticationType” and the “OrganizationName” properties.    The Authentication property can take one of three values:
  • 0 – AD
  • 1 – Passport
  • 2 – Internet Facing Deployment
• Since this is an on-premise installation we will go with 0.
• The “OrganizationName” property becomes extremely important in multi-tenant configurations where you may have multiple organizations or departments sharing a CRM implementation.  Since we only have 1 organization in our deployment it is safe to just set our default value.
• It is now time to deploy and configure the BizTalk application.
• When BizTalk generated our CRM schemas and sample Orchestration, it also generated a Binding file.  When we import the binding file we will discover that two send ports have been created.  The first is a basicHttpBinding and the second send port uses a Custom Adapter with a Custom binding.  What is the difference?  Really it comes down to some addition security configuration that is available with the Custom adapter.

• Using these binding as is didn’t work for me.  I needed to change the WCF-Custom Adapter to use the basicHttpBinding.  I also had to make a few Security related changes including setting the Security “mode” was set to “TransportCredentialOnly”

• I also needed to set the “clientCredentialType” to “Windows”

• I wasn’t quite done here.  I also need to add an Endpoint Behavior.  In this case it was a “clientCredentials” behavior.  Within this behavior, I set “Windows” - “allowedImpersonation” = “Impersonation”

• At this point, I am ready to configure the rest of the application and start it.  Once started, I can process my sample helper message.
• Within my sample file, I have provided the following information.  Once processed by BizTalk, I expect this Lead to be created within our CRM system and the CRM response to be send to disk.

• The response from CRM is a GUID.

• Once we launch the Dynamics CRM GUI, I am able to find my Barry Sanders record. 

Conclusion

If you have high-availability requirements then I highly recommend abandoning the Dynamics CRM 4.0 adapter.  Currently, and I am not sure if there are any plans, CRM 2011 does not have an adapter so now is as good as time as any to make the move.   You can read more about CRM 2011 integration on Richard Seroter’s blog.  Also look for a chapter on CRM 2011 integration in our upcoming book.