[groakes]

Wise colleagues,

I have a process which is working well in production. However, as user requirements change the process has grown to a point where it makes sense to split this into sub processes. While splitting the process diagram into three (or four) individual sub-processes is a relatively simple affair, I do have a few questions.

Firstly, is there an easy way to map the variables Out and In (these sub-processes will be Synchronous). There are quite a lot of variables that go to build up a cumulative record so there would be a large amount of effortinvolved to map these one at a time.

Secondly, I am wondering about the best strategy to put the new process(es) into production. My thinking is to leave the current process in place but remove the "Start" event so it doesn't appear in the New Case menu. Then add the new process(es) so that new cases are started with it. This will allow cases running in the old process to complete naturally. That way the users don't have to think about which version they are using and I don't have to worry about any cases being caught in limbo. When all the cases in the old process eventually complete I can then delete that process (assuming of course that all the data remains in the database).

This option does mean though that I will have to scrape the bottom of my barrel of SQL skills to sort out some KPI reports that get generated from Metabase every month.

So I'm wondering - is there an easy way to map the variables and, does my migration strategy make sense.

Thanks
Greg

[amosbatto]

If you are using the Community Edition, there is bug with synchronous subprocesses. Both the parent case and child case appear in the inbox. You can change the MySQL trigger to fix it. See: viewtopic.php?f=41&t=710184&p=795888&hi ... ss#p795922

Firstly, is there an easy way to map the variables Out and In (these sub-processes will be Synchronous). There are quite a lot of variables that go to build up a cumulative record so there would be a large amount of effortinvolved to map these one at a time.

There is no easy way. If you want a list of variables, you can query the SUB_PROCESS.SP_VARIABLES_OUT and SP_VARIABLES_IN fields, but you need to use PHP's unserialize() function to turn into an array.

Secondly, I am wondering about the best strategy to put the new process(es) into production. My thinking is to leave the current process in place but remove the "Start" event so it doesn't appear in the New Case menu. Then add the new process(es) so that new cases are started with it. This will allow cases running in the old process to complete naturally. That way the users don't have to think about which version they are using and I don't have to worry about any cases being caught in limbo. When all the cases in the old process eventually complete I can then delete that process (assuming of course that all the data remains in the database).

Deleting the Start event will work. Another way to do it is to go to the Properties of the current process and select the option "This is a sub-process" which simply prevents it from appear in the list when the user goes to Home > New Case. That way users can't start new cases in the process, but they can complete existing cases.

ProcessMaker won't let you delete the process if you have any cancelled or paused cases (yes, it's a bug). It is best to leave process and add " (deprecated)" to the title, to remind the process designer.

[groakes]

Thanks for the advice (and the warning) Amos.
Is there any timeframe for a bug fix to address the Inbox issue?

cheers
Greg

[amosbatto]

It's been reported and its status is "In review". It probably won't be fixed by next release.