Hi,

I've published a simple schema as a web service using the wizard. I'm trying
to review possible error scenarios and coming up with a few problems relatin
g
to errors being returned to clients of the service.

If I send a message with a malformed SOAP header or the body content does
not match the WSDL the message appears to get sent to IIS and that's it. No
error is returned to the client and no error is logged in the event log.

If I define the the location as request/response I see no way of defining
what the response should be with both success and failure scenarios.

Is the solution to use Orchestrations to define the responses? Would this
add anything to the handling of malformed SOAP messages?

Thanks for any help
Paul

[ Post a follow-up to this message ]

when a millformed message is sent via web service, ASP.NET is kicking it
back, in other words BTS doesn't get the chance to pick it up. there is a
couple of solutions for that
- Use SOAP extensions to log the in/out requests. thankfully it is by
default with the web service genreated by BTS (Check the source code)
- Handle error tradtionally in ASP.NET server app error handler (on error)
event in globabl class and log whatever you need.


You won't be able to get orchesteration this way because BTS will not pickit
up, unless you make a dramtic change to your schemas to allow xsd:any
element which might be helpfull but very harmful in everything else

Kal

"paularundel" <paularundel@community.nospam> wrote in message
news:EA4B2F56-4C41-4AD3-A029-2DD50E0F20C2@microsoft.com...
> Hi,
>
> I've published a simple schema as a web service using the wizard. I'm
> trying
> to review possible error scenarios and coming up with a few problems
> relating
> to errors being returned to clients of the service.
>
> If I send a message with a malformed SOAP header or the body content does
> not match the WSDL the message appears to get sent to IIS and that's it.
> No
> error is returned to the client and no error is logged in the event log.
>
> If I define the the location as request/response I see no way of defining
> what the response should be with both success and failure scenarios.
>
> Is the solution to use Orchestrations to define the responses? Would this
> add anything to the handling of malformed SOAP messages?
>
> Thanks for any help
> Paul
>
>

[ Post a follow-up to this message ]

Thanks for your quick response.

The main issue is that if an incorrect message is received and doesn't make
it to the message box, I want to respond to the client informing them of the
error.

I've tried some tests with a standard .NET web service in comparison with
the Biztalk Generated Service (i.e. it inherits from
Microsoft.BizTalk.WebServices.ServerProxy.ServerProxy).

For a malformed SOAP Action both return a SOAP fault as expected.

However if the SOAP message itself is malformed only the standard .NET
service returns a SOAP fault.

I'm still looking at it ...but any hints where I may be going wrong would be
appreciated.

cheers,
Paul











"Khaled M. Hnidk - MVP" wrote:

> when a millformed message is sent via web service, ASP.NET is kicking it
> back, in other words BTS doesn't get the chance to pick it up. there is a
> couple of solutions for that
> - Use SOAP extensions to log the in/out requests. thankfully it is by
> default with the web service genreated by BTS (Check the source code)
> - Handle error tradtionally in ASP.NET server app error handler (on error)
> event in globabl class and log whatever you need.
>
>
> You won't be able to get orchesteration this way because BTS will not pick
it
> up, unless you make a dramtic change to your schemas to allow xsd:any
> element which might be helpfull but very harmful in everything else
>
> Kal
>
> "paularundel" <paularundel@community.nospam> wrote in message
> news:EA4B2F56-4C41-4AD3-A029-2DD50E0F20C2@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]

You didn't go wrong perse, that is a standard .NET behaviour. to get around
that and return your own faults. you will need either SOAP extension or to
handle error on APP_on error event in the global class

Kal


"paularundel" <paularundel@community.nospam> wrote in message
news:18307AA6-C6F9-4BB7-94C8-335684929073@microsoft.com...[vbcol=seagreen]
> Thanks for your quick response.
>
> The main issue is that if an incorrect message is received and doesn't
> make
> it to the message box, I want to respond to the client informing them of
> the
> error.
>
> I've tried some tests with a standard .NET web service in comparison with
> the Biztalk Generated Service (i.e. it inherits from
> Microsoft.BizTalk.WebServices.ServerProxy.ServerProxy).
>
> For a malformed SOAP Action both return a SOAP fault as expected.
>
> However if the SOAP message itself is malformed only the standard .NET
> service returns a SOAP fault.
>
> I'm still looking at it ...but any hints where I may be going wrong would
> be
> appreciated.
>
> cheers,
> Paul
>
>
>
>
>
>
>
>
>
>
>
> "Khaled M. Hnidk - MVP" wrote:
> 

[ Post a follow-up to this message ]

hi,

I've made some progress. The web service code generated by the BizTalk
wizard sets the SoapDocumentMethodAttribute OneWay to 'True'. From the sdk
this implies that the service will send a HTTP 202 message back to the clien
t
before the web service method itself is called. If I set the OneWay flag to
'false' SOAP faults are returned for malformed SOAP messages. Is there a
reason why BizTalk sets the flag to 'True' rather than the default 'False'?

As I'm begining to find, fixing one quirky BizTalk issue causes another.
With the OneWay flag set to 'false' any message that now fails validation in
the pipeline, raises events properly, but no response is returned to the
client. How do I now respond to the client with validation failures?

Anyone from MSFT help respond to this?

cheers for any help
Paul

ps. I'd probably be able to understand this better if I could find the
Microsoft.BizTalk.WebServices.ServerProxy documentation espically as the
Microsoft.BizTalk.WebServices.ServerProxy.ServerProxy.Invoke method also has
a OneWay flag.



"Khaled M. Hnidk - MVP" wrote:

> You didn't go wrong perse, that is a standard .NET behaviour. to get aroun
d
> that and return your own faults. you will need either SOAP extension or to
> handle error on APP_on error event in the global class
>
> Kal
>
>
> "paularundel" <paularundel@community.nospam> wrote in message
> news:18307AA6-C6F9-4BB7-94C8-335684929073@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]