Here is a quick run through to the most common error(s)  you might face and resolution for the same.

1.Unable to load assembly "System.Web.DataVisualization" while building the ESB Portal

[Resolution] : Ensure that you have the Microsoft Chart Controls ( version 3.5 ) installed on your system by either verifying it from "Add / Remove Programs - Run APPWIZ.CPL" or simply checking the GAC for the presence of the missing assembly. If not install it from MS Chart Controls 3.

Installing this would ensure that you have the requires assemblies ( containing ASP.NET and Windows Forms Chart Controls) on your system, which the ESB Portal have a dependency on.

2."ESB Portal Error Information - UnHandled Exception" while browsing the ESBPortal

 [Resolution] : This could happen for a variety of reasons and the best way to troubleshoot is to m manually the following sites which are being accesses from within the ESB portal

Check this out- https://www.microsoft.com/en-us/download/details.aspx?id=35553

We have an official word from the BizTalk Product team for the BizTalk Server 2010 R2 TAP program.

BizTalk Server is Microsoft’s premier Integration and business to business communications server offering. This Technology Adoption Program (TAP) is for BizTalk Server 2010 R2, the 8th BizTalk Server release from Microsoft.

Please have your customers, partners and other prospective program participants fill out the nomination survey at:

https://connect.microsoft.com/Azure/Survey/Survey.aspx?SurveyID=14401

BizTalk Server 2010 R2 delivers enhancements in the following feature categories:

• Electronic Data Interchange

• Updated standards support
• IaaS offering
• Messaging
• Ordered delivery enhancements
• HL7 standards update
• Enhanced Visual Studio 2012, SQL Service 2012, Systems Center 2012 experience
• Support for SQL Server 2012 High Availability
• Integration with Windows Azure Service Bus and Workflow
• Addition of REST adaptor for integrating with Restful endpoints
• BizTalk Server Cloud IaaS offering for development and test scenarios

While more often than not , we always look for ensuring that no error comes up while running our scenarios but sometimes and as what happened in this particular instance ,in spite of inducing an erroneous condition to get my ESB Exception Send ports working I was not able to produce the error and soon I realized why.

I'll not get into what my scenario was since the reason behind writing this post has more to do with the this particular configuration setting in BizTalk WCF receive lcoations than anything else.

Whenever we publish our Schema's or Orchestrations WCF service , we always have a choice of creating a Receive Location with a particular type - WCF-basicHttp , WCF - Custom , WCF-WSHttp and so on.

As we see in this snap shot ,

We have got a property "Suspend Request Message on failure" - As the name implies , for whatever reason if the Request message is found to be erroneous by BizTalk , we have been given a option whether we would like that message to be suspended ( and available for subscribing to...) or not.

In a similar manner , if you want to have a control on whether the error details should be visible inside the failed Service instance , you have  a property available for that too - "Include exception details in Faults"

So just go ahead and enable this property and you will have your errors visible and available for subscription in  the form of suspended service instances.

In this blog I'll be showing how to setup the end point configuration for an incoming message in  the Business Rules Composer using  the vocabulary facts exposed by ESB 2.1.

So here goes the scneario - We have an incoming message which needs to be routed to an end point depending on the content of the message.

Please keep the following points in mind for this scenario

1. Since we are going to dynamically resolve the Itinerary using the message context, select the "ItinerarySelectReceiveXml" pipeline which comes "Out Of Box" with ESB Toolkit.
2. Inside the developer environment - itinerary Designer , select the Extender Component under which you have configured the BRE Resolver and set the property "UseMsg" as True - If it reamins at it's default value i.e False , at run time the message conent would not be sent to the Business Rules Engine and content based routing would not be possible.- Remember this is required only for the Content based routing scenarios and not needed if you are making decisons insdie your rule based on the the system promoted context properties.

Now assuming you have created your Business Rule IF condition based on the content of the message ( for e.g xpath of a given node) , this is how you need to set up the THEN condition and this applies specifically for the WCF based transport end points . Here I would be showing for WCF Sql Port

Remember that the

-  Properties that have been set in the actions inside the THEN pane are being exposed by the Out of Box vocabulary set that comes with the ESB Toolkit as shown below in the snapshot.

- The values that have been set for those proeprties need to be as it is there in the snap shot above and can be found in the Bindings fille that comes along when we Consume the Adapter Metadata at design time for importing the schema using the wizard. (Just remember that the WCF Action property value needs to be in {})

- In case you are doing content based routing using Business Rules Engine ( busienss condition is being evaulated using the content of the message ) ,  then you must ensure that you change the 'Document Type'  property is set to 'Microsoft.Practices.ESB.ResolveProviderMessage' while you are defining the vocabulary.

Well this issues bombed on me when I was preparing for a BizTalk - ESB demo  for one of the customer and again I found that the fault message was the one which really made it such a time consuming issue.

Nevertheless I thought of sharing with the community as it might just save you a couple of hours in crunch situation.

While I was configuring my "Receive Location" with the OOB pipeline "ItinerarySelectReceiveXml" , under the Resolver Component  "ESB Itinerary Selector" ,  the "Resolver Connection String" for Business Rule (Rule being used for resolving the itinerary) was specified incorrectly  with forward slash " // "instead of " \\ " which was causing the error and yes the Error message was'nt helpig me either.

There was a failure executing the receive pipeline: "Microsoft.Practices.ESB.Itinerary.Pipelines.ItinerarySelectReceiveXml, Microsoft.Practices.ESB.Itinerary.Pipelines, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "ESB Itinerary Selector"

Reason: Parameter name cannot be null or an empty string.
Parameter name: key

So simply put , correct the format to " BRI:\\ " and error would be resolved. ( I was using a Business Rules Resolver and hence I have a 'BRI' prefixed to the Connection String ,so have your connection string as per the resolver you need to use).

Keep Biztalkingggg...

Here is a notofication for a critical update for fixing the Leap year issue in BizTalk Server 2006 R2 and 2009 versions.

Important : BizTalk Server 2006 and 2010 versions are not affected by this bug.

EDI Leap Year hotfix: BizTalk 2009 and BizTalk 2006 R2

If using EDI in BizTalk 2009 and BizTalk 2006 R2, install the EDI leap year hotfix before 2/29/12:2435900   FIX:" Invalid Date" EDI interchange error occurs in BizTalk Server 2006 R2 or in BizTalk Server 2009 if a data element contains a leap date value

BizTalk Server 2009:

There are two ways to get this fix:

 Option 1: Install any BizTalk 2009 Cumulative Update. KB 2555976 lists the available cumulative updates:

 Option 2: Install the stand-alone fix by clicking View and request hotfix downloads at the top of KB article 2435900.

 BizTalk Server 2006 R2

There are two ways to get this fix:

Option 1

1. Install BizTalk 2006 R2 ServicePack 1.
2. Install BizTalk 2006 R2 Service Pack 1 Cumulative Update 3.
3. Install leap year fix (3.6.2230): https://support.microsoft.com/kb/2435900

PS: It is recommended to install CU3 before applying the fix as there are many other dependent binaries that get
updated and it is in the customer’s best interest to be on the latest supported
platform and minimize troubleshooting efforts.

Option 2

Install the stand-alone fix by clicking View and request hotfix downloads at the top of KB article 2435900.

Note BizTalk Server 2010 is not impacted by this bug.

While I was playing around with the Windows Server App-Fabric Caching Service , I came across a very strange issue.

Well strange because what I was trying to do was one of the most basic things I could have done in App-Fabric - Creating  a new Cache in a recently configured Cache on AppFabric Component.

While I was trying to create a new cache though the App Fabric Cache Power-Shell Command-lets

 New-Cache -CacheName NewCache -Secondaries 1 -TimeToLive 15

Once I executed the command I came across an unexpected error :

  CategoryInfo : NotSpecified: (:) [NewCache], DataCacheExceptionFullyQualifiedErrorId : ERRPS009,Microsoft.ApplicationServer.Caching.Commands.NewCacheCommand

Well there was hardly any information available in the error message through which I could have got any indicators towards what the error might be , one of the very informative trainig video helped me in finding the error.

The reason why I faced this error was because I was not connected to any network and the reason why the presence of a network is critical, is mentioned below :

The API's in the back-end that the Power-Shell command-lets uses , are basically the wrapper over the WCF based components that uses "NetTcpBinding"as a binding to communicate across  the cluster ( cache server nodes).Hence the for the communication to happen the minimum requirement is to have  a Network Adapter ( and I did not have a network connection when I face this error)

In case a network is  not present once can install / enable the "Loop-back Adapter" from the "Network and Sharing Adapter" . By enabling this the WCF based calls would be able to go through the TCP/IP stack and  would like a charm.( And this what I did)

Hope that would help a few !!!

 Thanks

  Amit

In this post I'll be talking about how to make BizTalk 2010 ( Should work well with 2006 R2 , 2009 as well) with Dynamics AX 2009 using AIF based WCF Services

I am sure some of you might have done or seen the same happening through AIF based Adapter where the effort mostly lies on configuring the Adapter with set of properties (some of them eventually becoming the context properties) but since WCF is the way to go I would be focussing on how to achieve the same through the AIF based WCF Services.

So here it goes :

Prerequisities from AX side

Before one can go about consuming the service ,  the AIF based WCF Service must be explicitly exposed from the AX ( Read this https://technet.microsoft.com/en-us/library/dd309574.aspx  and  https://technet.microsoft.com/en-us/library/aa834369.aspx)

The WCF Service by default is set up on the 'basicHttpbinding' which does not allow overriding the 'HeaderInfo' which is again a prerequisite for communicating through WCF Services whether through BizTalk or any vanilla .Net Client.Hence one needs to edit the web.config for the service to set it up on 'wsHttpBinding''. Read in detail here https://msdn.microsoft.com/en-US/library/cc652581.aspx

Follow the instructions below to edit the web.config ( C:\Program Files\Microsoft Dynamics AX\50\AifWebServices)

1. Under the <bindings> tag, add a <wsHttpBinding> tag, which includes a child <binding> tag.

2. In the child <binding> tag, set the name attribute to a unique value, such as wsHttpBindingAuthAif.

3. In the <service> tag for your service, set the binding attribute to wsHttpBinding.

4. In the <service> tag for your service, set the bindingConfiguration attribute to wsHttpBindingAuthAif (or the unique name that you chose earlier in the <binding> tag).

Finally the Web.config should be looking like this :

Web.Config

<configuration>

...

 <system.serviceModel>



 <bindings>

 <wsHttpBinding>

 <binding name = "wsHttpWindowsAuthAif" />

 </wsHttpBinding>

 </bindings>

...

 <services>

 <service behaviorConfiguration = "serviceBehaviorConfiguration"

 name = "Microsoft.Dynamics.IntegrationFramework.Service.SalesOrderService">

 <endpoint address = "" binding = "wsHttpBinding" bindingConfiguration = "wsHttpWindowsAuthAif"

 bindingNamespace = "https://schemas.microsoft.com/dynamics/2008/01/services"

 contract = "Microsoft.Dynamics.IntegrationFramework.Service.SalesOrderService" />

 </service>

 </services>

...

 </system.serviceModel>

</configuration>

BizTalk Side

Every requests that goes to AX must be targeted towards a particular Destination End Point  that must have been pre-configured from the AX side. Every request that goes to AX must have the Destination End point specified so that the Requests are directed towards the correct end point. This is how the basic Header looks like :

<headers>

 <MessageId xmlns="http:=//schemas.microsoft.com/dynamics/2008/01/services">{FFF3E75E-A75C-4228-ABF0-8E3EA2483EB4}</MessageId>

 <SourceEndpointUser xmlns="https://schemas.microsoft.com/dynamics/2008/01/services">MDSDEMO\Administrator</SourceEndpointUser>

 <SourceEndpoint xmlns="https://schemas.microsoft.com/dynamics/2008/01/services">BizTalk</SourceEndpoint>

 <DestinationEndpoint xmlns="https://schemas.microsoft.com/dynamics/2008/01/services">CEU</DestinationEndpoint>

</headers>

So the bottom line is that one must always ensure that this Header  information should always be present in the outbound message that goes out of the BizTalk Orchestration to the AX.

Now we all know that all the fields that are the part of the Header ,are not availble as a Context Proeprties ( If we use AIF Adapter , the adapter schema exposes these as context properties for us to use directly not not with directly exposed WCF Services)

So this is where one of the WCF Adapter Context Propeties comes to use ,which helps us set the HeaderInfo within the context of the BizTalk Message. - WCF.OutboundCustomHeaders

So briefly starting from scratch the following steps need to be followed on the BizTalk Side:

1. Import the AX Service meta-data using the "Consume WCF Service Wizard" that would import all the required Schema Files and port bindings along with the MultipartMessage Types and ports inside a newly created Orchestration

2. Once you have got all the schema in place , create your own message using the Multi Part message types , and before you send it out. Set the Context Property : WCF.OutboundCustomHeaders in an assignment shape within the 'Construct Message Shape'

MsgCreateAxItemDataRequest(WCF.OutboundCustomHeaders) = @"<headers><MessageId xmlns=""https://schemas.microsoft.com/dynamics/2008/01/services"">{FFF3E75E-A75C-4228-ABF0-8E3EA2483EB4}</MessageId><SourceEndpointUser xmlns=""https://schemas.microsoft.com/dynamics/2008/01/services"">MDSDEMO\Administrator</SourceEndpointUser><SourceEndpoint xmlns=""https://schemas.microsoft.com/dynamics/2008/01/services"">BizTalk</SourceEndpoint><DestinationEndpoint xmlns=""https://schemas.microsoft.com/dynamics/2008/01/services"">CEU</DestinationEndpoint></headers>";

Here the message 'MsgCreateAxItemDataRequest'is my Outbound Message and this the message where the Header Info needs to be put on . Here in the code snippet above, I have used  the same HEADER INFO that I have shown at the start

You may modify the Field Values depending upon your business requirements and can also have your way in setting this but the value this Context Property ( WCF.OutboundCustomHeaders  ) would have is the String representation of the XML.

3. Another important piece of information I wanted to highlight was that while importing the metadata from the Service ( with wsHttpBinding) , the port bindings ( bindings that you are going to import on to your WCF Send Port) are incomplete ( possibly some bug with the WCF Service Consumption wizard ) and hence you may have to set up the bindings on your own. I am attaching a binding file (WCFPortBindingsWsHttpBindingForAX.bindinginfo.xml) for the port bindings I had setup that worked well but still one may have to do some modifications depending upon the need.

Hope this post would help..Happy BizTalkinggg !!!

WCFPortBindingsWsHttpBindingForAX.bindinginfo.xml

While many of us might not face issues implementing this , it should help those  (and save time) who might be struggling to get this going.

To start with , recently we had a requirement of securing (exposing over SSL) a WCF Service with WsHttpBinding ,which I had developed exposing a Business Interface Orchestration. To secure the service means the

• The communication should be over https
• No Anonymous access should be disabled over the Virtual Directory.

For authentication scheme we would target Windows / Basic Authentication

Now coming back to the stuff - There are two parts to this :

• Enabling the Virtual Directory / Application in IIS to communicate over SSL.

1. Hooking a certificate to the Root Web Site to meet the requirement for SSL
2. Making the required changes in the associated web.config of the Virtual Directory.

• Configuring the BizTalk Receive Location to set the required Security Level to match that of the Virtual Directory.

The steps would be targeted towards BizTalk Server 2010 / IIS 7.0

 Enabling the Virtual Directory / Application in IIS to communicate over SSL

Enabling SSL on IIS 

This would be a pretty straight step that we might be doing for enabling communication over SSL for any other website on IIS 7.0 . For more info / help on this refer to https://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7/#IISManager

Adding User Account to BizTalk Appication Users

This is an important step and often missed by people.

Please do not forget to add the User Account (Under which your client is running. For e.g. AppPool user in case of a Web Application or Sharepoint hosted Application ) to the BizTalk Group -  "Biztalk Application Users"

Modifying Web.Config 

This is the most crucial part of the entire exercise and the one everyone seems to be missing on and face issues ( or at least I faced a lot)

To enable HTTPS following modifications need to be done in the web.config :

Open the web.config of the Virtual Directory

1. Comment out the 'mex' binding so that finally it looks like this

<services>
 <!-- Note: the service name must match the configuration name for the service implementation. -->
 <service name="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance" behaviorConfiguration="ServiceBehaviorConfiguration">
 <!--<endpoint name="HttpMexEndpoint" address="mex" binding="mexHttpBinding" bindingConfiguration="" contract="IMetadataExchange" />-->
 <!--<endpoint name="HttpsMexEndpoint" address="mex" binding="mexHttpsBinding" bindingConfiguration="" contract="IMetadataExchange" />-->
 </service>
 </services>

If we don't comment out  'mex' binding we would get an error like this when we try to browse the service ( The one which killed most of my time)

Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service

       2.    Modify the Service Behaviour -> serviceMetadata section to enable https and disable http ( By Default  it's like this httpsGetEnabled="false" httpGetEnabled ="true") so that post modification is should be like the following

 <serviceBehaviors>
 <behavior name="ServiceBehaviorConfiguration">
 <serviceDebug httpsHelpPageEnabled="true" httpHelpPageEnabled="false" includeExceptionDetailInFaults="false" />
 <serviceMetadata httpsGetEnabled="true" httpGetEnabled ="false"/>
 </behavior>
 </serviceBehavior>

    With the default settings when we try to browse the service , we would probably be getting the followign error :

   Could not find a base address that matches scheme http for the endpoint with binding WsHttpBinding. Registered base address schemes are [https]

Configuring the BizTalk Receive Location to set the required Security Level to match that of the Virtual Directory

Here , assuming that you would have created a Receive Location in your BizTalk Application using the BizTalk WCF Service Publishing Wizard  while publishing the Orchestration as a Service , all we need to do is open the Receive Location - > properties and configure the WsHttpBinding Security settings  as shown below .

While here I have selected the credential type as Windows , choice rests with you on what authentication scheme you want to keep , but always remember the fact that whatever scheme you keep here , the same should be set up on the IIS virtual Directory too.

Hope this helps...Till that time HAPPY BizTalkinggg....