| Author |
Message
|
| Lex |
 Posted: Fri Nov 14, 2008 1:50 am Post subject: How to keep information in case of a Catch in a Try-Catch |
 |
|
Acolyte
Joined: 14 Nov 2006
Posts: 73
|
Hi there!
I'm working with WMB 6.0.
During the processing of a flow, i add in some case a tag in my XML that i need in case there is an error occuring later.
When debugging, my flow has effectively his new tag created, but when the error occur (and so when the flow travel to the catch part of my flow), the new tag suddenly disappear!
I think i'm missing something there and i'm asking for your help 
Thanks,
Lex |
|
| Back to top |
|
 |
| elvis_gn |
| Posted: Fri Nov 14, 2008 2:03 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi Lex,
So your message is rolling back to the catch and you are losing the tag you created...and you want to retain it...hmm...why didn't you put it into environment also ?
Regards. |
|
| Back to top |
|
|
| Lex |
| Posted: Fri Nov 14, 2008 3:11 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2006
Posts: 73
|
Thanks for the quick reply elvis 
What do you mean by putting my new tag into environment? |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Fri Nov 14, 2008 3:25 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi Lex,
It would be good if you could explain your business requirement a little better...I'm not sure if my solution is suited for your situation.
But in general I meant, fields that you need in the catch path on occurrence of exceptions, you should store them in the Environment tree right at the onset, so that on rollback the fields would be retained (Environment is not rolled back on exceptions).
Regards. |
|
| Back to top |
|
|
| Lex |
| Posted: Fri Nov 14, 2008 5:10 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2006
Posts: 73
|
Ok i'll try to explain the best i can.
We have a message flow which submit all incoming flow to different database.
We need to add a tag that indicates when the submission to a database is OK, so we added it just after the submission. We have this need because if the flow then fails to be submited to another application database, we don't want it to be submitted again to the other database.
We tried your solution, effectively we have the added tag after the catch, but the solution doesn't fill our requirement. Indeed, we have a web interface that allow us to monitor the flow processed, and that allow us too to send again a flow that failed to be properly processed. But we also need to have the information we added before when we submit the flow again, and actually we lose this information when the flow comes to the monitoring database 
Any idea? And thanks again for the help |
|
| Back to top |
|
|
| m4c0 |
| Posted: Fri Nov 14, 2008 5:17 am Post subject: |
|
|
Novice
Joined: 07 Nov 2008
Posts: 17
|
Quick doubt: do you need to send the message to all databases or just the one that matches a filter?
Anyway, if you need to reprocess the message in case of error, I guess a "failure" queue will help. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Nov 14, 2008 5:27 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| We need to add a tag that indicates when the submission to a database is OK, so we added it just after the submission. We have this need because if the flow then fails to be submited to another application database, we don't want it to be submitted again to the other database. |
This sounds like transactional behaviour, but implemented in message flow logic. Any reason why you are not using a transaction manager to enforce this rule ( and lots of similar ones )? |
|
| Back to top |
|
|
|
|
