Model Update - Process Flow Reevaluation?

Topics related to the LSPS Engine and the management of running processes.
Forum rules
Make sure every topic contains information about your LSPS version and if relevant also your server OS, client OS, database name and version, and application server name and version.
neil.lee
 
Posts: 14
Joined: Wed Jul 23, 2014 4:38 pm

Model Update - Process Flow Reevaluation?

Fri Mar 20, 2015 8:09 pm

I'm working on troubleshooting a Model Update issue in LSPS 2.7.1427. A picture's worth a thousand words, so:

1-PreUpdate.png
1-PreUpdate.png (62.98 KiB) Viewed 7333 times

This was the process before the Model Update (or rather,the important part). Note that on the left the flow was Parallel Gateway -> Exclusive Gateway -> Default Path -> Exclusive Gateway -> Parallel Gateway (Stopped Here) -> End

2-PostUpdate.png
2-PostUpdate.png (61.4 KiB) Viewed 7333 times

This was the process state immediately following the Model Update. Note that the left flow has changed significantly. Rather than a single path, the updates process has a Parallel Gateway -> Parallel Gateway -> 2 Exclusive Gateways/Subprocesses/Exclusive Gateways -> Back to the Original Parallel Gateway.

One thing to note is that the "last" Parallel Gateway is "lit" post-Update since the process flow had reached that point prior to updated.

3-Current.png
3-Current.png (61.37 KiB) Viewed 7333 times

This is the current process state. Processing has continued until the "other" flow (through Confirm Platform Setup) that leads into the last Parallel Gateway has completed. However, the process will not complete. I suspect this is because of an issue with the last Parallel gateway. Perhaps it's expecting three flows to enter before it's completed but only two have reached it (the original flow and the single path post-update)? Otherwise, it may not be detecting/recalling the past flow that led into it since that part of the process was removed/overhauled?

I'd appreciate any input that you can provide regarding this issue. If there's a programmatic method for resolving the issue, that'd be extremely helpful. Otherwise, I suspect that yet another model update will be required to somehow coerce the Parallel Gateway to allow the processes to flow forward.
Last edited by neil.lee on Fri Mar 20, 2015 8:40 pm, edited 2 times in total.

neil.lee
 
Posts: 14
Joined: Wed Jul 23, 2014 4:38 pm

Re: Model Update - Process Flow Reevaluation?

Fri Mar 20, 2015 8:17 pm

Additionally, I have a related question regarding an unintentional model update that occurred. This one's more of a "out of curiousity" question, though:

4-PreUpdateSubproc.png
4-PreUpdateSubproc.png (23.75 KiB) Viewed 7332 times

The original process was fairly simple: start, determine the platform type, have a subprocess run, end. In this case, the process was "in" one of the platform subprocesses when it was Model Updated.

5-PostUpdateSubproc.png
5-PostUpdateSubproc.png (36.49 KiB) Viewed 7332 times

The updated process is significantly more complex: start, allow 0-4 different variations of Platform Setup to occur, end.

My question: In the updated process, the only "lit" item is the Subprocess. Or rather, it's probably the case that whatever active task/signal within the Subprocess was running prior to the update is active post-update. However, post-process update, am I correct in assuming that it's impossible for this process to ever complete because the final parallel gateway will be waiting for ~4 flows in and only one will ever arive?

As a broader question: Upon model update, is the (prior) process flow reevaluated beyond ensuring that whatever active tasks/signals/etc. remain active post-update? Thanks in advance for any information that you can provide.

Radovan Cervenka
 
Posts: 48
Joined: Mon Feb 27, 2012 2:47 pm

Re: Model Update - Process Flow Reevaluation?

Mon Mar 30, 2015 3:03 pm

Hi,

yes, the problem is that the model update mechanism does not sufficiently solve adding new flows and injection of tokens to them in processes that continue execution also after model updating. This insufficiency can, however, be solved by tricky models that allow to inject tokens to "death" flows later. The pattern can look like this:
TokenInjection.png
token injection pattern
TokenInjection.png (18.62 KiB) Viewed 7295 times


Here, the flows leading to a parallel join gateway are enriched by catch signal intermediate events (marked by A and B in diagram) that can be used to generate tokens by signals. Each intermediate event should catch a different signal in order to achieve disambiguation during token injection.

I suggest to update models of halted processes by this pattern and then send appropriate signals to achieve continuation of tokens behind waiting parallel gateways. When you reach the state that there are no such waiting processes, you can update all processes to the originally desired model.

I know, this is not a very comfortable way. Just for your information, we plan to change LSPS model update to a more flexible mechanism allowing much better manipulation of tokens; but this will take some time to be included in one of next product releases (soonest in LSPS 3.1).

neil.lee
 
Posts: 14
Joined: Wed Jul 23, 2014 4:38 pm

Re: Model Update - Process Flow Reevaluation?

Mon Mar 30, 2015 4:08 pm

Thanks for the information. We had considered a process based solution, such as catching the "restarted" process flow at the Start event and using an exclusive gateway to route the flow back where it should be, but the idea of using signals injection is both novel and preferable. I'm guessing that the signals would be initiated through a separate maintenance process or through new variables (Boolean flags) added during the model update?

I'll definitely keep this pattern in mind if a process update requires it in the future. For now, the current model update issue was resolved via a daily maintenance process that queries the database and triggers an Achieve Goal level Deactivate condition when appropriate. It's not ideal from an auditing or process flow perspective, but it should work in this specific context (one where no additional processing or assignments would occur in the process flow after the "stuck" point).

Radovan Cervenka
 
Posts: 48
Joined: Mon Feb 27, 2012 2:47 pm

Re: Model Update - Process Flow Reevaluation?

Tue Mar 31, 2015 9:20 am

neil.lee wrote:I'm guessing that the signals would be initiated through a separate maintenance process or through new variables (Boolean flags) added during the model update?

Yes, signals can be produced by a separate process or from management console's expression evaluator (using the sendSignal function) if number of stuck processes is quite low and you need individual approach to each of them. Alternately to signals, also boolean variables and conditional intermediate events can be used, but they will influence execution context (which is not a tragedy); however, a larger problem is that they can be changed only from the model instance itself, not from "outside" as signals can be.

neil.lee
 
Posts: 14
Joined: Wed Jul 23, 2014 4:38 pm

Re: Model Update - Process Flow Reevaluation?

Tue Mar 31, 2015 4:24 pm

Radovan Cervenka wrote: Yes, signals can be produced by a separate process or from management console's expression evaluator (using the sendSignal function) if number of stuck processes is quite low and you need individual approach to each of them. Alternately to signals, also boolean variables and conditional intermediate events can be used, but they will influence execution context (which is not a tragedy); however, a larger problem is that they can be changed only from the model instance itself, not from "outside" as signals can be.


That's a valid observation regarding the potential problems with boolean variables. In the (hopefully unlikely) event that we encounter a similar model update issue in the future, I'll definitely suggest the "signal injection" approach. It'd also completely slipped my mind that sendSignal could be called from the expression editor, which is much simpler than creating a one-off maintenance process in cases where there will be no additional models that need to be signaled.

Thanks again for the information.

Return to Management

Who is online

Users browsing this forum: No registered users and 1 guest