|
Home > Archive > BizTalk Server Orchestration > February 2005 > how are exceptions dealt with in orchestrations
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 |
how are exceptions dealt with in orchestrations
|
|
| biztalker 2005-02-16, 5:50 pm |
| Hi all,
This is a follow up to my previous question about dealing with unwanted
resumable messaging instances. Here is what I need to do: I need to send a
request to a web service in my orchestration (this is being done through a
request-response port). I wish to do this within a scope shape, so that if
any of the error conditions that I am watching out for arise, I can deal with
it appropriately. Once I have handled the exception in the orchestration, I
do not want to do anything else.
In regards to the above, I have a few questions:
1. What are the implications of setting the Transaction Type (for both the
orchestration and the scope shape) to none?
2. While I played around with an orchestration designed as described above,
I noticed that despite the exception being caught and handled, I get
resumable messaging instances in HAT (where the messaging instances are the
web service requests, that were already received by the web service). Why
does this happen? Would it have to do anything with a response not being
received from the web service?
3. If the resumable messaging instances mentioned in 2 do occur because of
the response not being received, and I don't really care about the response,
is there a way to do away with the messaging instances automatically without
me having to go to HAT to terminate them? Is there another way to design the
orchestration to deal with unreceived responses?
Any help with these questions will be much appreciated.
Thanks.
| |
| Neal Walters 2005-02-16, 5:50 pm |
| I just want to give you one thought and not address your whole question. I
hope it helps but it may not be of any interest to you...
When the web service gives an exception, if your retries > 1 (in the send
port definition), then the web service gets called over-and-over. If this is
an application type error, this seems rather ridiculous. If the web service
is down, you want the retries. I posted something about this a while back.
One thought was that any application errors could be returned as an XML
field value rather than an exception.
When you do get an port error, HAT shows the message as terminated. If
after the 5 minute retry, it succeeds, rather than HAT showing the original
message as terminated, and adding a new successful message, it actually goes
back and flags the original message as completed. I.E. you don't really
have a HAT log of the problems. You would have to go to Application Event
Log for that.
Anyway, hope that helps some.
Neal Walters
http://Biztalk-Training.com
"biztalker" wrote:
> Hi all,
>
> This is a follow up to my previous question about dealing with unwanted
> resumable messaging instances. Here is what I need to do: I need to send a
> request to a web service in my orchestration (this is being done through a
> request-response port). I wish to do this within a scope shape, so that if
> any of the error conditions that I am watching out for arise, I can deal with
> it appropriately. Once I have handled the exception in the orchestration, I
> do not want to do anything else.
>
> In regards to the above, I have a few questions:
>
> 1. What are the implications of setting the Transaction Type (for both the
> orchestration and the scope shape) to none?
>
> 2. While I played around with an orchestration designed as described above,
> I noticed that despite the exception being caught and handled, I get
> resumable messaging instances in HAT (where the messaging instances are the
> web service requests, that were already received by the web service). Why
> does this happen? Would it have to do anything with a response not being
> received from the web service?
>
> 3. If the resumable messaging instances mentioned in 2 do occur because of
> the response not being received, and I don't really care about the response,
> is there a way to do away with the messaging instances automatically without
> me having to go to HAT to terminate them? Is there another way to design the
> orchestration to deal with unreceived responses?
>
> Any help with these questions will be much appreciated.
>
> Thanks.
| |
| biztalker 2005-02-16, 5:50 pm |
| There is one reason why we do not want to use the retry option. If we receive
the timeout on receiving a response from the web service, our request will
get logged twice in the backend system tied to the web service (This is
something we do not want, since the backend system assigns a unique id to the
request. And we'd have duplicate requests in the backend system with unique
ids, something not desirable). I agree, that setting the retries would have
made life more easier. Any other suggestions, anyone?
"Neal Walters" wrote:
[vbcol=seagreen]
> I just want to give you one thought and not address your whole question. I
> hope it helps but it may not be of any interest to you...
>
> When the web service gives an exception, if your retries > 1 (in the send
> port definition), then the web service gets called over-and-over. If this is
> an application type error, this seems rather ridiculous. If the web service
> is down, you want the retries. I posted something about this a while back.
> One thought was that any application errors could be returned as an XML
> field value rather than an exception.
>
> When you do get an port error, HAT shows the message as terminated. If
> after the 5 minute retry, it succeeds, rather than HAT showing the original
> message as terminated, and adding a new successful message, it actually goes
> back and flags the original message as completed. I.E. you don't really
> have a HAT log of the problems. You would have to go to Application Event
> Log for that.
>
> Anyway, hope that helps some.
>
> Neal Walters
> http://Biztalk-Training.com
>
> "biztalker" wrote:
>
| |
| Nabeel Prior 2005-02-16, 5:50 pm |
| Have you tried setting the "Delivery Notification" property (may have the
name wrong) to "Transmitted"? If I remember correctly, this is only an
option for Dynamic web ports in an orchestration, but it's purpose is to
ensure that any errors that occur on delivery of a message are returned to
the orchestration?
--
Kind Regards,
Nabeel Prior
Web: http://www.brainjar.co.za
Blog: http://www.brainjar.co.za/blog.aspx
"biztalker" <biztalker@discussions.microsoft.com> wrote in message
news:E33166E3-AF04-4AF8-A60B-D7DFDB4997B3@microsoft.com...[vbcol=seagreen]
> There is one reason why we do not want to use the retry option. If we
> receive
> the timeout on receiving a response from the web service, our request will
> get logged twice in the backend system tied to the web service (This is
> something we do not want, since the backend system assigns a unique id to
> the
> request. And we'd have duplicate requests in the backend system with
> unique
> ids, something not desirable). I agree, that setting the retries would
> have
> made life more easier. Any other suggestions, anyone?
>
>
> "Neal Walters" wrote:
>
| |
| biztalker 2005-02-16, 5:50 pm |
| The web port is not dynamic. I was under the impression that a dynamic web
port could only be used for load-balanced set up. Where can I get more
information?
"Nabeel Prior" wrote:
> Have you tried setting the "Delivery Notification" property (may have the
> name wrong) to "Transmitted"? If I remember correctly, this is only an
> option for Dynamic web ports in an orchestration, but it's purpose is to
> ensure that any errors that occur on delivery of a message are returned to
> the orchestration?
>
> --
>
> Kind Regards,
>
> Nabeel Prior
> Web: http://www.brainjar.co.za
> Blog: http://www.brainjar.co.za/blog.aspx
>
>
> "biztalker" <biztalker@discussions.microsoft.com> wrote in message
> news:E33166E3-AF04-4AF8-A60B-D7DFDB4997B3@microsoft.com...
>
>
>
| |
| Nabeel Prior 2005-02-17, 2:46 am |
| Not necessarily. A dynamic port is simply a port where the transport
details are configured at run-time rather than at design-time. You
configure a dynamic web service port in your orchestration with an
expression shape containing a statement like the one below, where prtName is
the name of the logical port in your orchestration:
prtName(Microsoft.XLANGsBaseTypes.Address) = "http://server/webService.asmx"
Apparently, the DeliveryNotification property can be set on ports of "Speciy
Later" or "Dynamic" typing. So, without having to get into the details of
dynamic ports, you could use the "Specify Later" option, and set the
Delivery Notification to Transmitted and test your orchestration's error
handling like that.
More info: http://blogs.msdn.com/kevinsmi/arch.../03/172574.aspx
--
Kind Regards,
Nabeel Prior
Web: http://www.brainjar.co.za
Blog: http://www.brainjar.co.za/blog.aspx
"biztalker" <biztalker@discussions.microsoft.com> wrote in message
news:C78F8E70-F9B5-43DB-B7EF-ECF8B77A98A7@microsoft.com...[vbcol=seagreen]
> The web port is not dynamic. I was under the impression that a dynamic web
> port could only be used for load-balanced set up. Where can I get more
> information?
>
> "Nabeel Prior" wrote:
>
| |
| biztalker 2005-02-17, 5:51 pm |
| Thanks! I'll test it out.
"Nabeel Prior" wrote:
> Not necessarily. A dynamic port is simply a port where the transport
> details are configured at run-time rather than at design-time. You
> configure a dynamic web service port in your orchestration with an
> expression shape containing a statement like the one below, where prtName is
> the name of the logical port in your orchestration:
>
> prtName(Microsoft.XLANGsBaseTypes.Address) = "http://server/webService.asmx"
>
> Apparently, the DeliveryNotification property can be set on ports of "Speciy
> Later" or "Dynamic" typing. So, without having to get into the details of
> dynamic ports, you could use the "Specify Later" option, and set the
> Delivery Notification to Transmitted and test your orchestration's error
> handling like that.
>
> More info: http://blogs.msdn.com/kevinsmi/arch.../03/172574.aspx
>
> --
>
> Kind Regards,
>
> Nabeel Prior
> Web: http://www.brainjar.co.za
> Blog: http://www.brainjar.co.za/blog.aspx
>
>
> "biztalker" <biztalker@discussions.microsoft.com> wrote in message
> news:C78F8E70-F9B5-43DB-B7EF-ECF8B77A98A7@microsoft.com...
>
>
>
|
|
|
|
|