Geeks With Blogs
ErwinAI - Enterprise Application Integration (EAI) blog on BizTalk 2004, Visual Studio, and application integration

An orchestration was published as a webservice using the WSE 2.0 wizard. This seems to be operational on the test server.

The next step is being able to test our own webservice orchestration. So, within the solution, we created another project for consuming the webservice. The projects share underlying message types (avoiding conflicts due to multiple subscriptions when operating orchestrations from both projects at the same time), and the consuming orchestration is using the webservice definition as obtained from reading the published .ashx file (which contains the wsdl; we like to keep things simple ;-).

When trying to consume the webservice using the orchestration, I noticed in the HAT that the consuming orchestration succesfully called the webservice. The instance of the orchestration behind the webservice remaining in status “started”. Not much more was shown.

This situation gave me reason to look in the event log (application). XLANG/s errors cause the same sort of behaviour. This time, I saw a few errors generated by the webservice publishing side, and a few warnings by the consuming side. The most descriptive error told:

“The Messaging Engine failed to register the adapter for "WSE" for the receive location "/virdir/ws_pub.ashx". Please verify that the receive location is valid, and that the isolated adapter runs under an account that has access to the BizTalk databases.
”. Event ID 5734.

Some Google-results suggested that it would not be possible at all to consume a BizTalk-based webservice with an orchestration in BizTalk. Knowledge base article 910295 describes symptoms, cause and solution in detail. It looks as if it is working.


After some struggling, I decided to leave the idea of consuming the BizTalk-based webservice using BizTalk.

What is the problem? Both the webservice and the consumer are hosted by the same BizTalk instance. Publishing and consumption of the webservice do not cause the problems themselves. In my case, the webservice was based on an orchestration.

That means that on "either side" of the webservice, an orchestration is active using exactly the same message definitions. This causes problems when messages are passed through the webservice. Passing messages to send ports is problematic, because "multiple subscriptions are active".

I am not convinced that it is impossible to realize this, but I decided to spend no more time moving away from the destination. Instead, I built a simple client application in c# that works excellently. Look for some good guides on this topics in the weblogs.


Posted on Wednesday, April 5, 2006 9:11 AM BizTalk 2004 Hints, Tips & Tricks | Back to top

Comments on this post: BizTalk 2004 - No go: Consuming an orchestration based webservice with another orchestration

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Erwin Homan | Powered by: