Hello Greg, > Wouldn't you also need to detect the > failure and retry the failed activity? Would you also want all subsequent > process instances to use the new endpoint, or would you expect each new > instance to try the original ep and fail over as well?
Once there is a failure calling a service endpoint, the process instance execution will be paused, the new endpoint will be written over the old ones and the processinstance will then be continued trying to call the last action (new calling for the new endpoint). This solution is a kind of "optimistic aproach" where service unavailability is mostly temporaly and the next call to the same service is often successful again. There is also a counter component who log the failing calls, once a service endpoints keeps failing serveral times it will be marked as "permanently unavailable" and a process-wide endpoint replacement will be executed, after this all subsequent process instances will follow the updated BPEL with updated endpoints (in the deployment descriptor). > If for some reason you cannot model the error handling in your BPEL > process (which would be my first choice), it sounds like you would be > better off capturing that logic elsewhere and using a fixed endpoint from > BPEL. You could hide your 'real', potentially changing endpoints behind > some other routing component (e.g. a camel route if you were running in > servicemix). Using a routing component sounds interesting, although I don't want to bloat the project with yet another component. But I will look into that solution. Thank you! Best Regards, Thuy > -----Original Message----- > From: Greg Lucas [mailto:[email protected]] > Sent: Tuesday, December 15, 2009 8:12 PM > To: [email protected] > Subject: Re: Extend InstanceManagement API to provide endpoint > manipulation > > Thuy, > > I'm not aware of any existing support for this. I'm not sure I fully > understand the requirements though. If the intent is to redirect a > failed > invocation to another endpoint then modifying the endpoint for an > active > process instance seems insufficient. Wouldn't you also need to detect > the > failure and retry the failed activity? Would you also want all > subsequent > process instances to use the new endpoint, or would you expect each new > instance to try the original ep and fail over as well? > > If for some reason you cannot model the error handling in your BPEL > process (which would be my first choice), it sounds like you would be > better off capturing that logic elsewhere and using a fixed endpoint > from > BPEL. You could hide your 'real', potentially changing endpoints behind > some other routing component (e.g. a camel route if you were running in > servicemix). > > ~Greg > > > > On Tue, 15 Dec 2009 11:16:00 -0500, Song Thuy Nguyen > <[email protected]> wrote: > > > Hi everyone, > > > > > > I'm quite new to Apache ODE and mailing lists, hoping for your help. > I > > have > > posted a similiar question in the user mailing list, but maybe here > is a > > better place to ask, as it has something to do with extending ODE. > > > > > > As the title says I'm looking for a way to change service endpoints > for > > BPEL > > process instances at runtime. That means that only one instance > should be > > affected by these changes, not the entire process and the deployment > > descriptor. By convention of the project I'm working on, it is not > > allowed > > to write a BPEL-process that looks up service endpoints at a registry > > service, put it in an variable and use it as the dynamic endpoint. > The > > reason is we want to provide a fault resistant BPEL process execution > by > > replacing failing or unavailabe service endpoints by working ones > with > > transparency to the process. So there should be no sign of the "fault > > handling" in the BPEL file. Failing services will be detected by a > > monitor > > component, but this is not my part. > > > > > > I have tried to look into the Management API doc for processes and > > instances > > to find a method that can provide a solution, but I had no luck. > There > > are > > only methods to get and set endpoints on a process-wide level, on a > > instance > > level however, those methods are not available. > > > > > > It seems to me that the only way to get such a functionality is to > extend > > the Instance Management API and write those methods myself. If this > is > > right, can someone please tell me where to start? I think there > should be > > Java objects representing each BPEL instance, and there are variables > > storing the endpoints, so if I change them, I would get the > > functionality I > > need , right? > > > > > > Or maybe there is already a built-in mechanism to do that but I > missed > > it? > > > > > > Any help or comment would be appreciated. > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4690 (20091215) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version > 4634 (20091124) __________ > > E-Mail wurde geprüft mit ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version > 4634 (20091124) __________ > > E-Mail wurde geprüft mit ESET NOD32 Antivirus. > > http://www.eset.com >
