Hi, Martin. Thank you for quick and constructive answer.
> Let's go back to the reason why we implemented forked workflows: > We wanted to be able to reuse existing workflows > (i. e. cert issuance and publication) in other workflows > without rewriting most of the workflow itself in a new workflow definition. > The workflow engine does not support "sub-procedure" workflows, > hence we developed the forking concept. I am not sure it was the only reason. I will cite some devel-list mails to clear up my point of view. (mail texts are in double quotes below) First time it was commited here: http://sourceforge.net/mailarchive/forum.php?thread_name=41573.129.35.231.1.1158322005.squirrel%40129.35.231.1&forum_name=openxpki-devel [OpenXPKI-devel] 506: Forking workflows From: Alexander Klink <ak-ml2...@cy...> - 2006-09-15 12:06 ... "This is useful so that the parent workflow can decide whether to create the child workflow normally (using CreateWorkflowInstance), so that someone has to explicitly trigger the start of the workflow (for example if it is an important certificate issuance). The other possibility is to start the workflow using ForkWorkflowInstance, which autoruns from the WAITING_FOR_START state, so that the workflow can possibly be run without any user interaction whatsoever." ... Later bulk request processing appeared and the problem of user notification: only one notification must take place in the case of successful termination of all the CSR-CertIsuue paires. So the interprocess communication came. The last child must know that it is really the last and that all the others are terminated OK. See also a letter from Alex on the devel-list: http://sourceforge.net/mailarchive/forum.php?thread_name=000801c7ba50%2415c54bb0%24020010ac%40int.ipmce.ru&forum_name=openxpki-devel Re: [OpenXPKI-devel] ldap and workflow From: Alexander Klink <ak-ml2...@cy...> - 2007-06-15 11:36 ... " > But the CSR workflow is waiting for the certificate_isuue > in the same way the certificate issue is waiting for ldap-public. The difference is that the cert request workflow is designed not to care whether cert issuance finishes after waiting for it or later, it can update its state once the user views the workflow. This has no parallel in the cert issuance - ldap publication connection." ... I would say the main problem is not a "sub-procedure" but "waiting" for some workflow events. Can we avoid it? Or use a special smart master-workflow-monitor to check the database periodically for some events in slave-workflows. Sergei suggests to do it at the moments when the processor load of the server is below the certain level. > Write a new Workflow Activity (similar to ForkWorkflowInstance). > Lets call it ExecuteWorkflowInstance. > In the context parameters of ExecuteWorkflowInstance > we pass the desired Workflow type name > and possibly some mapping instructions which context values > of the parent workflow should be passed to the child workflow. > Now the activity creates a new workflow instance of the desired type. > The ExecuteWorkflowInstance activity now calls the necessary activities > in the sub-instance. The sub-instance will likely contain mostly > autorun states (as it is the case in the current candidates > for forked instances), but this would not strictly be necessary. > The ExecuteWorkflowInstance could handle calling activities > on the sub-instance itself. > Once the sub-workflow finishes, > the ExecuteWorkflowInstance activity is done > and allows proceeding to the next top-level workflow state. Well, we already have all the instruments: "ExecuteWorkflowInstance" = "CreateWorkflowInstance" + "ExecuteWorkflowActivity" This way we are testing workflows. But do we need to synchronize some workflows' actions? "ExecuteWorkflowInstance" is not enough in that case. > A second, related task will be some logic to clean up > or re-instantiate stalled workflows > (e. g. after a server shutdown or unexpected error). > I see problems with automatic detection and reaction - > how do you determine if a workflow has been left > in a stalled state deliberately or if it stalled due to an error...? I do not know details on workflow exceptions, workflow persistence and workflow rollback in the case of errors. Need to learn more about it. Maybe setting the workflow to some special 'Exception' state instead of throwing an exception is a correct approach to trace the errors? > We're also thinking about rebuilding the whole dang user frontend. > Let's face it, the web UI sucks and badly needs to be redone... I hope Julia and Sergei have some ideas :-) Best regards, Petr Grigoriev ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
