Hi Tammo, It may sound hard indeed, but for what you said, it does look feasible as well. I will see what I can do with this and in some point in the future, give you guys a feedback. Who knows if it will turn out to be and extension like Adaptive ODE :)
Cheers, On Thu, Oct 13, 2011 at 6:33 PM, Tammo van Lessen <[email protected]>wrote: > Hi Rafael, > > this sounds like a typical research project ;) ODE is not designed to > properly support this, since, as you know, allowing adhoc changes to > already running process instances opens a can of worms. > > However, here is how it could go: > > In ODE, BPEL processes are compiled into a serializable OModel, which is > basically an optimized representation of the process model, each > activity got an id. During runtime, the process model is loaded and when > the process model is started, runtime classes (in most cases the > activity name in uppercase) will be instantiated. These classes > implement the execution semantics of the activities. Eg sequence > compiles to OSequence, which is during runtime evaluated by SEQUENCE. > This basically looks for child activities, gets the first one, creates > an UPPERCASE instance of that and delegates the execution to the virtual > process machine. Once it is completed, the control is given back to > SEQUENCE, which looks for the next activity, creates an UPPERCASE > instance and so on. The object graph of these UPPERCASE classes is > serialized and persisted to make the engine robust. So much for the > theory. If you want to change the process model, it should be possible > to change the OModel in parts that have not yet been processed by the > UPPERCLASS instances. Changing those is probably much more difficult, > since you then may need to change the state of such classes as well. > Basically it depends on your use case, but it could worth a try. No > warranties, however :) > > I hope that helps a bit, > Tammo > > On 13.10.2011 15:46, Rafael R. Aschoff wrote: > > Hello all, > > > > I am not very familiar with the ODE source code and was looking for a way > to > > change the workflow during runtime. > > > > I would like to know if someone has an advice on that, where should I > look? > > > > More precisely, I want to change the internal logic of a BPEL process > based > > on some monitored events. > > > > On a second phase, I would like to change the logic just for a particular > > user instance, which means that future calls to the BPEL process will not > > perceive the changes. > > > > > > For what I have seen so far, to change future logic I could try to > > manipulate the output of the ODE BPEL Compiler. I do not know if I could > do > > the per user instance, but it seems possible for future executions. > > > > In order to control the logic per user, I guess I would have to use the > > Process Management API, but I could not find any information of the > > possibility to change the execution instance itself. > > > > > > > > > > Best regards, > > -- > Tammo van Lessen - http://www.taval.de > -- Rafael Roque Aschoff Ph.D. Candidate School of Informatics City University London Phone: +44 (0)20 7040 3252 http://www.city.ac.uk/informatics<https://outweb.city.ac.uk/owa/redir.aspx?C=46ed6fba36974fff8e39ae128d622ebe&URL=http%3a%2f%2fwww.city.ac.uk%2finformatics>
