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 respons
e
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 report
s
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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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 port
s
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 the
m
> 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... 
>
>
>

[ Post a follow-up to this message ]

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:
> 

[ Post a follow-up to this message ]

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... 
>
>

[ Post a follow-up to this message ]

Yes, that could be a workaround, but it's a bit tedious if the services chan
ge.

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 bin
d
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 fin
d
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 onl
y
> change the ip/url when you use it? That way you only get one in the genera
te
> 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... 
>
>
>

[ Post a follow-up to this message ]