Hi Alex, Sent: Wednesday, June 13, 2007 2:04 PM Alexander Klink wrote:
>> The main thing was to write a stand-alone package performing the >> ldap operations and call it from workflow actions. >> This way all main ldap operations can be tested automatically. > Sounds good. But what LDAP server do you want to test it against? I > believe it is possible to set up a test server using Net::LDAP::Server, > but it seems like it involves a good amount of work ... I am using OpenLDAP as described in the draft. > ................................................................. As an > immediate solution, I'd suggest you use looping and sleeping until the > child finishes (which was in earlier workflow definitions, see for example > http://openxpki.svn.sourceforge.net/viewvc/openxpki/trunk/deployment/etc/templates/default/workflow_def_certificate_signing_request.xml? revision=646&view=markup > This should be combined with a check whether the child fails (see SCEP > workflow). Still, this might lead to an infinitely looping workflow > if the child does not end up in state 'SUCCESS' or 'FAILURE' for some > reason ... Yes, I tried that approach but looping happens time by time. May be it is worth to put ldap-publishing workflow steps inside the certificate_issue workflow. But the CSR workflow is waiting for the certificate_isuue in the same way the certificate issue is waiting for ldap-public. Another idea is to use the conditional branching via the result of action - - this workaround is described in Workflow.pm but I did not try it. It is described here http://search.cpan.org/~jonasbn/Workflow-0.26/lib/Workflow/State.pm#Resulting_State and sounds like this: "You can also have multiple return states for a single action. The one chosen by the workflow system will depend on what the action returns. For instance we might have something like: <state name="create user"> <action name="create"> <resulting_state return="admin" state="Assign as Admin" /> <resulting_state return="helpdesk" state="Assign as Helpdesk" /> <resulting_state return="*" state="Assign as Luser" /> </action> </state>" >As for your other problems mentioned in your document, about 1) and 2): > are you sure you have a recent Workflow.pm? I believe I solved these > exact problems in 0.25/0.26 ... If so, can you please set the Workflow > log level to DEBUG and send me a copy of your openxpki.log so that I can > try and debug it? Yes, I have the recent Workflow that is the problem and that is why I decided not to use looping for the time being. As far as I remember 0.25/0.26 problem was that the condition did not checked again in the loop and the result of the previous check was used instead. Before 0.26 infinity looping happened ALWAYS. After 0.26 it happens TIME by TIME. I'll try to reproduce it and catch the log messages. Best Regards, Petr Grigoriev P.S. Sorry for mixing things up and sending mail to svn instead of devel. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
