Question related to very long term processes

Question

I'm implementing a form in workspace that manages approvals for a real estate group. There will be a form/process for new building locations and one for renewals. The form and workflow for new buildings locations and renewals is the same - the only difference is that for renewals I want to use the same form as was initially used as the input for the process (so that the user doesn't have to rekey data). I've been puzzling over how to set this up. The approach I'm currently working on involves saving the form as a PDF and then allowing this to be injected into the renewal process from a watched folder. This is close to working, but I can see a few major problem with it; specifically 1: it requires that the user save/manage PDF documents outside of workspace 2: it will not work if the form or the form schema changes at all - and this is quite likely since the interval from the forms initial approval to its use in the renewal process could be several years.
I want to ask whether anyone can suggest a better approach. One idea that I have is to, at the end of my approval process, simply assign the form to a special "archive" work group. This assignment step would then have a route leading back to the "top" of the approval process. This would potentially give workspace users the ability to review old forms online and re-submit them. I have a few questions about whether this approach would work:
-> Would it be a problem having a workflow that basically never ends? My main concern is that I'm not clear on whether, when a workflow process is running, it take up system memory or is simply managed as a record within the database? We don't anticipate a large volume of use - only a few hundres forms a year - but I'm concerned that having hundreds of running processes could present a memory issue.
-> When the person managing the renewal assigns the work item in the "archive" queue to themselves, would it be possible to force the system to consider that individual to be the process creator? The reason that this is important is that I have a number of process steps in which the form is assigned back to the creator - but the original creator would not likely be the person initiating the renewal.
-> Would having running processes cause issues with any server upgrades/migrations, or would it be easy to migrate the running processes if we ever had to migrate to a new server or upgrade the LiveCycle software?

Answer 1

Hi Jeff
A long set of questions, no wonder no-one has been game to answer... :-)
Better approach? Maybe. I would extract the data from the form at the end of your first process into a database table. Then, when you start the other process, pre-populate the form from the same data. You will obviously need some kind of "primary key" to identify the old form in the new process. My 2c. If you do use the old form to populate the new, that's generally okay, as long as you only add data to the schema, not remove or change it.
The special Archive group would work. Once a task has been assigned to a user (or a group), it just sits there. It's a record in the database, it doesn't take up any memory or cpu. The group queue could get very full though, and it might be hard to find particular forms.
I think you can just assign the creator process variable to a new value. However, I also think it's probably a bad idea. Instead, just create a string variable called "new_creator" (or whatever). Assign the user id of the user who completed that task to new_creator. Then, in subsequent user steps, assign the step to Xpath instead of creator, and select /process_data/@new_creator.
Upgrades shouldn't be a problem, since the task data is stored in the database, and generally the database survives upgrades. (It would be wise to take a backup, as always:-)
Howard
http://www.avoka.com