Yossi Dahan [BizTalk]

Google
 

Saturday, June 21, 2008

UK SOA/BPM user group meeting

The first meeting of the UK SOA/BPM user group is just around the corner on the 17th of July.

You can find all the details here

See you there.

Labels: , ,

Friday, June 20, 2008

Failed to register adapter <...> for receive location

Everyone gets this error in the event log every once in a while -

The Messaging Engine failed to register the adapter for "<...>" for the receive location "<...>".

Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases.

Mostly I get this when I publish a new BizTalk web service and forget to selected the correct application pool (using windows service 2003).

Often this comes up when setting up an XP (or Vista) workstations for the first time and forgetting to sort out ASPNET permissions.

Sometimes it is simply a typo in the receive location's url, or a problem the script that was supposed to enable it, all of those are pretty much suggested through the event log entry message.

But earlier this week I had another case, one which never happened to me before (and, arguably, shouldn't have happened at all, but if it did for me, there must be another idiot who would do the same! :-)), and that one is not mentioned in the message -

I have published an orchestration web service, selected the correct application pool and made sure the receive location was enabled but still this error would be logged.

What I didn't do (I blame it on having a cold) is to actually create an instance of the host under which the receive location is configured to run; I had a host configured and selected but no host instance...

Labels: , ,

Saturday, June 14, 2008

The lost property

You've created your pipeline component, added a few public properties for good measure (to make it a bit more flexible of course).

You went on to create a pipeline with your component, set all the properties you've introduced and deploy it to BizTalk Server.

You then configure a port to use the pipeline (and the contained component) and test your scenario. all is sweet.

But then - you decide to add one more property to your component.

You quickly go and change the component, adding the public property you've missed, and, if you're anything like me, you decide to skip the whole: update pipeline, remove from port, undeploy, redeploy, re-configure port etc. and simply GAC the updated component planning to set it's value through the admin console to save the pain (and time).

However, when you open the port in the admin console and going to set the newly added property in the pipeline configuration you are into a surprise - your new property does not appear in the UI.

You double check everything - check your code, re-build, re-gac and re-open the admin console, but it's all the same - the property is simply not there. you bang your head against the wall. twice.

And then it hits you - it's not the component! it's the pipeline!

A pipeline "source code" is essentially an XML document. pipeline components, and their properties, are XML fragments within this XML.

When you add a component to the pipeline, its information, including all known properties (and their values) are added to the pipeline's XML.

And yes - you've guessed it right - when you're editing a pipeline's configuration through the admin console, the source of the generated UI you see is that XML, not the actual components' assemblies in the GAC.

If, like me, you have just GAC-ed a new version of the component and went to the admin console to configure it, you're up for a disappointment as your newly added property will simply not be there.

you will be forced to re-deploy the pipeline (unless you are happy to change xmls in the management database, that is - and you shouldn't be).

Labels: , ,