Forum OpenACS Q&A: Workflow Explanations

Collapse
Posted by defunct defunct on
Hi All,

Who knows quite a lot about workflow?

I have a requirement to use this, but more importantly I'm trying to combine that with some fairly thorough acceptance testing.

The problem is that workflow is quite involved, quite complex and unusual in that its designed to be used in conjunction with other packages.

I am finding (without trying) lots of errors, glitches, inconsistencies and 'features' and I need to identify which ones are genuine and which are behaviours I'm seeing because I've not set something up properly etc...

The docs with it are OK, but... does anyone have any better docs (even if they're still in development) or some more complete examples of how workflow should be applied?

Also, I am correct in thinking that the workflow admin pages/app should be self-contained in that they should operate without an visible errors out-of-the-box? Its not entirely clear whether the admin package requires manual coding before it works.

Thanks
Simon

Collapse
Posted by Don Baccus on
The workflow admin pages should work without manual coding.  I have fixed some errors in it but may've introduced some on the PG side in doing so as I've concentrated on the Oracle side.

I've worked fairly extensively with workflow and while I think the underlying ideas are good and that it represents and excellent first effort, there's a lot that needs to be done to make it as useful as we envision it to be.

If you've got time to post the list of stuff you've found/are finding I'll be willing to comment on them and would be interested in hearing Lars's opinions, too (since he wrote it!) and also comments from others who've used it.

Collapse
Posted by Lars Pind on
Simon,

Workflow was never quite done as envisioned. As with a lot of other ACS 4 things, the plug was pulled. And, also consistent with the rest of ACS 4, I grossly underestimated the amount of effort it would take to finish it the way I'd envisioned.

So that's probably why you find it lacking in many respects. Because it is.

Your thinking is correct, that it shouldn't break (there might be a graphviz issue, did you install graphviz or instruct it to not use graphviz?).

I'll be happy to bounce ideas back and forth and tell you all about the intentions that went into the design, as well as the ideas I have for where I think it should go.

Collapse
Posted by defunct defunct on
Lars/Don,

Be happy to feedback/SDM and so forth and I'll do that as I step through workflow more methodically...

I would also be keen to understand what the overall intention is for workflow and also where you feel current deficiencies lie but...

In the first instance it would be useful for me to get the right perspective for the purposes of testing.

I can test things individually and do the 'this query errors' routine, but to know whether the package is performing properly I need to understand what this actually means.

The docs are OK but a little light on the details.

By way of example its not entirely clear (coupled with my 'thickness') what the intention of roles is and how they should be properly used. Suppose I want a workflow where items in an 'unassigned' place can be picked up by people with a certain role. Once someone has picked it up and started the first taks, other future tasks should be assigned automatically to the same person, until a decision point changes that. Looking at the docs/screens, it seems that this should be posisble without coding, but that seems to suggest a role for each individual assignee, which is not ideal. This may just be my misunderstanding of the package, but I guess you can see what I'm driving at.

Do you have, or can you give and more detail on how to acheive more specific things? I think the docs are lacking some concrete examples.

Also, yes I did install the graphing tool (slightly newer version) and thats working ok.

Cheers
Simon

Collapse
Posted by Kevin Crosbie on
Hi Simon,

I posted a few weeks ago asking how to do things in the workflow.  Lars sent me this reply:
https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=00044x&topic_id=11&topic=OpenACS

Overall, I would say that it is a little difficult to see exactly what is going on and when to write callbacks etc.  I ended up doing as much as possible in the graphics editor, then going into the code that the system had dumped and modifying that to call procs like automatic assignments.

For instance, I was unable to find a place to fill in details for the wf_context_role_info table without actually going in and changing the workflow create script myself.

This is just my perspective as someone who had never used the Workflow module before and learned how to use it.

Take a look at the above link, I found it extremely useful as a starting ground for using the workflow module.

Collapse
Posted by Don Baccus on
Lars ... it would be great if you could spend a half-hour or so writing up a quick sketch of your ideas as to where workflow ought to go.

There's a lot of interest within the project in making workflow be a truly useful part of the toolkit.  It's useful today but as you say, it's incomplete and the incompleteness makes using it a bit frustrating.  Since you designed and wrote it I think having your thoughts as a base for discussion would be very useful.

Graphviz doesn't do a very good job of graphing complex Petri nets BTW.  It's certainly nicer than having no graph at all, though.

Collapse
Posted by Lars Pind on
Did you all find the /doc/acs-workflow/future-plans.html document, which outlines some of the more far-fetched ideas I had?

As for roles, it's probably easiest to explain by using the ticket-tracker as an example: The roles here would be "Submitter" and "fixer". Possibly also "triager", if you have some person first who triages and does the assigning. And possibly a "QA" role, if you have a QA step at the end.

In the simple two-role submitter-fixer case, you'd have the "submit ticket" (okay, so submit probably wouldn't be a task, but still), "clarify problem" and "verify fix" tasks assigned to the submitter role, while the "fix" and perhaps some other task would be assigned to the "fixer" role.

The point is, you can group together tasks (transitions), and say "these tasks should all be done by the same person or group of people".

Another example: an RFP. The "vendor" does this, the "purchasor" does this, etc.

A very quick outline of what I envisioned with workflow: I want to let people build packages like the ticket-tracker, like bug tracker, or other packages that involve a workflow as a significant component, to easily build that, and get a superb user interface almost for free. How's that for a goal? :)

Another side goal is to make it super easy for packages that just need some really simple approval type mechanism to do that.

Hm. Very vague and hand-wavy. Will try to say something clearer some day.

Collapse
Posted by Don Baccus on
Did you all find the /doc/acs-workflow/future-plans.html document, which outlines some of the more far-fetched ideas I had?

Yeah, I was thinking you might have even further-fetched ideas lurking in your mind :)

I haven't read that in awhile so will go revisit. One thing that's been on my mind is integration with permissions rather than total dependence on the party mechanism for deciding who can do what within a workflow. I don't recall that being in your future-plans doc but might be wrong (so I'd better re-read it, huh? :)

Collapse
Posted by Kevin Crosbie on
I'm using the workflow with the ticket-tracker now, and I think it's great once you get over a few hurdles at the beginning.  It really removes the hastle of trying to recode the ticket-tracker every time you want a new one with a slightly new requirement.  Well done on it Lars!

I'm currently trying to write a module that will allow you to add custom fields to other modules(I'm not 100% if that's been done before)  I think this would be another valuable addition to modules like the ticket-tracker.  If I get it to any stable stage, I'll make it available.

Collapse
Posted by defunct defunct on
So essentially then, if I had two individuals both performing the same role, they would both see new tasks for that role as they appear. i.e. if I wanted to assign the next task to the same person as performed the previous task, automatically, then this would be a coding step i.e. it can't be done via the i/f without specifically naming an instance of a user
Collapse
Posted by Lars Pind on
Don,

Yes, better integration with ACS core is something that should definitely happen. The whole notion that a workflow process definition is an object type is flawed (you have to do DDL to create a new process, you get lots of tables, you have unique name problems, etc., etc.). I'd like to get away from that.

The only reason I did it like that originally was that I desperately wanted the ACS Objects skinny table data storage for the case attributes, but that never worked too well anyway.

Also, I forgot if I mentioned that in the future-plans doc, but I also wanted to look into storing the process definition differently, e.g., as an XML document in a CLOB instead of in lots of different tables. Not sure if it makes things that much easier, but it did seem at the time like it would buy me some flexibility in storing multiple revisions of the same process, copying and distributing processes, etc.

Also, acs_rels should probably be used for assignments.

All in all, you're right, that this was originally designed when the core was yet very incomplete.

Collapse
Posted by Lars Pind on
Simon,

I think the answer is no. You might get away with assigning the role to whomever finishes the current task, and assign the next task the same role. Should work.