|
Home > Archive > BizTalk Server Orchestration > June 2005 > Mixed One-Way and Solicit-Response Operations
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Mixed One-Way and Solicit-Response Operations
|
|
|
| We are struggling with the following problem:
We need to call a web service that has two methods (operations), one with
only a request parameter (One-Way) and one with both a request and a response
parameter (Solicit-Response).
Now, the solicit-response call is easy, we added the referenced port type
and called it with "late binding" (specify later). The problem is, that we
can't call the one-way port. Everytime we call it, the requests arrives at
the web service, but as it doesn't send a response, BizTalk fails and reports
an error in the receiving pipeline ("body part is null").
Does anybody know how to mix one-way and solicit-response methods in such a
scenario?
Every comment is of great help!
Kind regards,
Alex
| |
| Matt Milner 2005-06-07, 5:57 pm |
| Without looking I am guessing here, but can you create two different ports
in your orchestration, each with the same web port type, and then bind them
to two different physical send ports, one that is one-way and one that is
two-way. This should work for you.
Matt
"Alex" <Alex@discussions.microsoft.com> wrote in message
news:CFC21426-8C07-4A48-B736-1354CC90E8C6@microsoft.com...
> We are struggling with the following problem:
>
> We need to call a web service that has two methods (operations), one with
> only a request parameter (One-Way) and one with both a request and a
> response
> parameter (Solicit-Response).
>
> Now, the solicit-response call is easy, we added the referenced port type
> and called it with "late binding" (specify later). The problem is, that we
> can't call the one-way port. Everytime we call it, the requests arrives at
> the web service, but as it doesn't send a response, BizTalk fails and
> reports
> an error in the receiving pipeline ("body part is null").
>
> Does anybody know how to mix one-way and solicit-response methods in such
> a
> scenario?
>
> Every comment is of great help!
>
> Kind regards,
> Alex
| |
|
| Well, the problem is that the web port type always contains both operations
and thus is a two-way port. So even if we create two separate ports in the
orchestration, after deployment, we just can bind physical two-way send ports
to it. Or at least, the BizTalk Explorer in Visual Studio just displays
two-way physical ports for binding (would xml export, manual change and
re-import of the binding help?).
Alex
"Matt Milner" wrote:
> Without looking I am guessing here, but can you create two different ports
> in your orchestration, each with the same web port type, and then bind them
> to two different physical send ports, one that is one-way and one that is
> two-way. This should work for you.
>
> Matt
>
>
> "Alex" <Alex@discussions.microsoft.com> wrote in message
> news:CFC21426-8C07-4A48-B736-1354CC90E8C6@microsoft.com...
>
>
>
| |
| Matt Milner 2005-06-18, 2:47 am |
| Having two operartions does not make it a two-way port. Having two
operations that are both solicit/response would make it a two way port.
You'll need one of the operations on the web service to be marked as on way.
I could still see you having trouble since the port type itself will show up
as request/response. This may be tough to get past without splitting the
service up. Does the compiler complain if you just send and don't receive? I
imagine it does. Sorry I couldn't be more help.
Matt
"Alex" <Alex@discussions.microsoft.com> wrote in message
news:C0EF8D53-E01F-42F5-83ED-032F9437B7EB@microsoft.com...[vbcol=seagreen]
> Well, the problem is that the web port type always contains both
> operations
> and thus is a two-way port. So even if we create two separate ports in the
> orchestration, after deployment, we just can bind physical two-way send
> ports
> to it. Or at least, the BizTalk Explorer in Visual Studio just displays
> two-way physical ports for binding (would xml export, manual change and
> re-import of the binding help?).
>
> Alex
>
>
> "Matt Milner" wrote:
>
| |
| Niklas E 2005-06-22, 5:51 pm |
| I guess it is not only to change the orchestration or some other file, but
it is sent to the configuration-DB? Perhaps you can as a workaround create a
local WS with only one method with the same interface locally and then only
change the ip/url when you use it? That way you only get one in the generate
if it has a bug only allowing one type per WS.
Best regards
Niklas Engfelt
"Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
news:eJ8eDx7cFHA.2420@TK2MSFTNGP12.phx.gbl...
> Having two operartions does not make it a two-way port. Having two
> operations that are both solicit/response would make it a two way port.
> You'll need one of the operations on the web service to be marked as on
> way. I could still see you having trouble since the port type itself will
> show up as request/response. This may be tough to get past without
> splitting the service up. Does the compiler complain if you just send and
> don't receive? I imagine it does. Sorry I couldn't be more help.
>
> Matt
>
>
> "Alex" <Alex@discussions.microsoft.com> wrote in message
> news:C0EF8D53-E01F-42F5-83ED-032F9437B7EB@microsoft.com...
>
>
| |
|
| Yes, that could be a workaround, but it's a bit tedious if the services change.
Just to clarify things again:
I am consuming a web service from within an orchestration. This web service
has both a one-way and a two-way method. When I add a web reference to it,
Visual Studio adds three schemas and a port type to the project. Note that
the port type has a request-response communication pattern.
After deploying the project, I created a solicit-response send port and
bound it to the orchestration. The BizTalk Explorer does not allow me to bind
a one-way port to it. So far, so good.
Now what happens when I invoke the orchestration:
If I specify the default XML pipeline as the send port's receive pipeline,
BizTalk reports the following error to the event log:
There was a failure executing the receive pipeline:
"Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source:
"Microsoft.BizTalk.Pipeline.Components" Receive Location:
"http://localhost/WebService1/Service1.asmx" Reason: Body part is null.
HAT now contains a not resumable message of type OneWayMethod.Response. Note
that no such schema exists.
Now, if I change the receive pipeline to PassThruReceive, BizTalk reports
The "SOAP" adapter is suspending a message coming from Source
URL:"http://localhost/WebService1/Service1.asmx". Details:"Response message
submission failed.".
and then
The Messaging engine failed to process a message submitted by adapter:SOAP
Source URL:http://localhost/WebService1/Service1.asmx. Details:Could not find
a matching subscription for the message.
HAT contains now two messages of this mysterious type, one not resumable
(routing failure), the other resumable (messaging).
Is there anyone who could confirm this as a bug or provide another
workaround as the one suggested below? And where does this response message
type come from?
Thanks in advance
Alex
"Niklas E" wrote:
> I guess it is not only to change the orchestration or some other file, but
> it is sent to the configuration-DB? Perhaps you can as a workaround create a
> local WS with only one method with the same interface locally and then only
> change the ip/url when you use it? That way you only get one in the generate
> if it has a bug only allowing one type per WS.
>
> Best regards
> Niklas Engfelt
>
> "Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
> news:eJ8eDx7cFHA.2420@TK2MSFTNGP12.phx.gbl...
>
>
>
|
|
|
|
|