Introducing BizTalk360 Troubleshooter

We automated as much of the installation step as possible in our BizTalk360 MSI file. But there are certain things that will require user input, and a MSI installer shouldn’t modify certain things in your server. Example: Granting rights to the service account for certain tables in BizTalkMgmtDb database, Changing the IIS authentication scheme, adding […]

The post Introducing BizTalk360 Troubleshooter appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar

The Messaging Engine failed to register the adapter for "SOAP"

The Messaging Engine failed to register the adapter for "SOAP"

While configuring an web service generated using the BizTalk Web Services Publishing Wizard using WCF-BasicHttp adapter you might get the following error message

The Messaging Engine failed to register the adapter for "SOAP" for the receive location "/XXXX/XXXXXXXXRequestResponse.asmx".
Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases.

BizTalk 2010 gives you two ways to expose your Orchestrations as a service one using the SOAP adapter (BizTalk Web Services Publishing Wizard) the other using the WCF adapter (BizTalk WCF Service Publishing Wizard). When you use the BizTalk Web Services Publishing Wizard you generate a web service with a .asmx extension. When you use the BizTalk WCF Service Publishing Wizard you generate a web service with a .svc extension.

Usually during an upgrade it is recommended to expose your orchestrations via WCF using the BizTalk WCF Service Publishing Wizard.  But using the WCF Publishing Wizard would change the URL for the service from .asmx to .svc. Which would mean a larger impact in terms of communicating to all the clients that use the service about the change in the URL.

As you know BasicHttp binding in WCF is compatible with asmx. So one of our clients had published the orchestration using the Web Services Wizard (asmx) and while configuring the receive location used the WCF-BasicHttp binding to receive the messages. That’s when this error will show up.

When you publish an orchestration using the Web Services Wizard (asmx) it internally uses an assembly from the SOAP adapter to construct the BizTalk message. So the Host needs to have permission to load the SOAP adapter. In this case we had our Host as a receive handler for the WCF-BasicHttp Adapter alone and not the SOAP Adapter.

To get around this situation you must add your HOST as a new Receive/Send Handler for the SOAP adapter as well (even though you are using the WCF-BasicHttp Adapter to receive the messages).

To conclude

1. Do upgrade to the WCF Adapter but use the BizTalk WCF Service Publishing Wizard

2. The BizTalk Web Services Publishing Wizard is meant to be used with the SOAP Adapter

3. If you use the BizTalk Web Services Publishing Wizard and configure the Receive Location to using WCF-BasicHttp binding you will need to grant the HOST permission to load both the WCF-BasicHttp and SOAP Adapters.


Blog Post by: Shinva

First Look at a Windows Azure Bill for BizTalk Server 2013

First Look at a Windows Azure Bill for BizTalk Server 2013

With the release of BizTalk Server 2013 on Windows Azure Infrastructure as a Service (IaaS) we have a new way to license BizTalk Server.  We can now license BizTalk Standard and Enterprise on a pay per hour basis.  This opens up a wide range of opportunities for dealing with short lived and bursting scenarios.

What does I bill using these pay per hour features look like?  See below. 

I used 3 hours of both a Standard and Enterprise edition of BizTalk Server. 

Using the pay per hour model is currently only supported using the pre-built images.  So if you wanted to have pay per hour Virtual Machines already connected to a BizTalk Group, you could create a new Virtual Machine using the pay-per-hour image and then join it to your group.  Once joined, Delete the Virtual Machine.  If you need that Virtual Machine back again, just create the Virtual Machine using that Disk.  This way you are up and running in about 3 minutes and only changed for the storage space until you need the extra processing ability.

Is anyone using BizTalk in IaaS now in a pay-per-hour basis?

BizTalk orchestration direct binding and routing failures/PersistenceExceptions

BizTalk orchestration direct binding and routing failures/PersistenceExceptions

Most developers who have worked with BizTalk for a while will realize the benefits of using direct bindingon orchestration ports to improve flexibility and loose coupling. What is not often realized is that using direct rather than specify later port binding comes with a bit of a trade-off in that the increased flexibility results in […]
Blog Post by: Johann