Yossi Dahan [BizTalk]

Google
 

Wednesday, July 26, 2006

WebService call from an orchestration anomaly

We have stumbled into this strange behaviour a few weeks ago, but now Microsoft I believe confirmed this to be an unexpected behaviour so I've decided it's a good time to post it -

We have a web service we're consuming from within an orchestration in BizTalk.
This web service has two methods - one is two way and the other one way (it does not have any return value)

We use the SoapDocumentMethod attribute on the web method to make sure it is a true one way web method ([SoapDocumentMethod(OneWay=true)])

When we add a web reference to this web service from the orchestration we get a web port generated with two operations as expected, one is a request-response and one is a One-Way (send only).

However, strangely enough, when we send a message out through the one way port we get a routing failure message in the message box.

What happens is that because the web service has a two way web method it is using a two way send port, for both these operations, the expected behaviour is for the SOAP adapter to realise one of the methods is a one way only call and to not expect, or return to the message box a response message. However, as the case appears to be, the SOAP adapter does seem to be returning a message to the message box even when no response was actually received, or indeed expected.

Sunday, July 23, 2006

Developing pipeline components to promote properties

A friend asked me today a question that highlighted this once again so I thought, although quite a few posts have been written on the subject, it might be worth mentioning it again.

The question was asked after he looked at this sample and was quite simple really - "Why do I need to worry about developing complicated custom pipeline components to manipulate promoted properties when I can promote properties through the schema or even use distinguished fields in my orchestration?" (well, it's not an exact quote - but that was the meaning, trust me..)

The first thing to remember, generally with BizTalk, not limited to this issue alone, is that you don't always have an orchestration.

It is easy to forget sometimes, especially if you've been doing a lot of orchestration development, that BizTalk is very useful even without any orchestration in sight. personally I did many projects that barely used them.

There are many reasons to use orchestration, but many others why not to, I guess that the obvious rule of thumb is that unless you actually need a workflow, you should question yourself whether you actually need an orchestration.

Which brings up the first point - sometimes all you have to go with is the pipeline, in which case distinguished fields are not useful.

The second point for promoting properties in a custom pipeline component is when you don't
actually want to have a schema for the incoming message (a lot has been written on this, so I'll leave it as a statement only here) or indeed when the incoming message is not xml (and is not parsed to one); in both these cases you will need to have custom logic to determine what to promote, and how to promote it.

Same applies when the rules for promotion are not simple, for instance if they are conditional, or if you need to promote a single instance of a repeating element etc. such cases are not supported by the property promotion declaration in a schema.

Of course you're still limited to promoting a single value to a single promoted property, but you have much more freedom as to how you get this value through custom code.

So - the bottom line is that in many cases you do need to write custom pipeline components to promote information to the message context.

A warning here - while very efficient and effective, custom pipeline components should be written with care - mainly you must ensure they are taking a streaming approach rather the

Thursday, July 20, 2006

Promoting properties through custom a pipeline component

I suspect that many developers, especially ones starting with BizTalk, see mostly BizTalk through orchestrations and see much less the messaging aspects of it.

A friend asked me today a question that highlighted this once again so I thought, although quite a few posts have been written on the subject, it might be worth mentioning it again.

The question was asked after he looked at this sample and was quite simple really - "Why do I need to worry about developing complicated custom pipeline components when I can promote properties through the schema or even use distinguished fields for my orchestrations?" (well, it's not an exact quote - but that was the meaning, trust me...)

The first thing to remember, not necessarily related specifically to this issue, is that you don't always have an orchestration.

It is easy to forget, especially for someone who has been focused on them for a while, that BizTalk is very useful indeed without a single orchestration in sight.
Personally I did many projects that barely used them, and still gained great benefits from BizTalk Server.

There are many reasons to use orchestrations, but quite a few why not to as well. I guess that the obvious thumb rule is that unless you actually need a workflow, there's little to gain from an orchestration.

Which brings up the first point - sometimes all you have to go with is the pipeline, in which case distinguished fields are not useful.

The second point for promoting properties in a custom pipeline component is when you don't actually want to have a schema for the incoming message (a lot has been written on this, so I'll leave it as a statement only here) or indeed when the incoming message is not xml (and is not parsed to one); in both these cases you will need to have custom logic to determine what to promote, and how to promote it.

Same applies when the rules for promotion are not simple, for instance if they are conditional, or if you need to promote a single instance of a repeating element etc. such cases are not supported by the property promotion declaration in a schema.

Of course you're still limited to promoting a single value to a single promoted property, but you have much more freedom as to how you get this value through custom code.

I can think of a few more reasons, but the bottom line is that in many cases you do need (or want to, or should) to write custom pipeline components to promote information to the message context.

A warning here - while very efficient and effective, custom pipeline components should be written with care - mainly you must ensure they are taking a streaming approach rather the

Tuesday, July 11, 2006

cannot resolve imported 'messagetype'

As we all know it is best practice not to include both schemas and orchestrations in the same process.

So we didn’t. We have an orchestration in assembly A which then defines a message type that uses a schema from assembly B.

We then wanted to call that orchestration from an orchestration in yet another assembly (Assembly C), passing in a message of the type we’ve defined.

In order to avoid duplication of message type definition we’ve marked the message type in Assembly A as public and added a reference from Assembly C to Assembly A so we could use it to define our message in the calling orchestration.

When we compiled the process we got the following error: “cannot resolve imported 'messagetype'

The error occurred because while we had a reference from Assembly C to assembly A to resolve the message type definition, we did not have a reference to assembly B which includes the actual schema used by this type.

I wish the error was clearer as it took as a short while to figure out the cause of the problem, but once you do figure out what's the cause it all makes sense.

Thursday, July 06, 2006

Generics bite again

Generics have proved to be quite useful, and are being used quite frequently in our project.
While I love them as a .net developer, from an integration perspecitve they provde to be a bit of a pain.

I've blogger previously about our problems with web services. today I've bumped into another scenario we can't use when generics are involved - using .net classes as message type.

Try complie an orchestration that uses a .net class with generics and you'll get the ever so useful error message "Unknown system exception" at compile time.