Update a running BPM

[Guest Paul Alexander]

This is fairly urgent....

 

Until this morning I've been able to go in to a 'suspended' BPM and update something to get it working again.

However, this morning I've tried to go in to a process which I know isn't set up correctly (I created this a few months ago but forgot to add a specific setting so the call doesn't move forward correctly. I've fixed the originating BPM but any requests which were logged before I made this change are not working correctly) but I'm getting the error that I cannot save a running process instance - which I've always been able to do in the past. This means that I can't now do anything with these requests...can this be fixed so that I CAN update a running request please? 

 

[Adrian Simpkins]

Hi Paul

I am getting a different error when trying to update an existing BPM today -  Error: decision ("s1"/"decision-871260cb") parse: at 2/10: "Uncaught SyntaxError: Unexpected token )" return [() == true, (true) == true]; })()" ------------------------------ (function()( var outcome=false;if(global{"inputParams"]["outcome"]) {outcome = global["outputParams"] ["outcome"];}else {outcome = global["flowcode"]["outcome"];} return [() == true, (true) == true]:})()

Might be linked

 

[Gerry]

Hi @Paul Alexander

Thanks for posting.  We have had an interesting internal conversation about this one.  Editing a running process (that is, one that has not Failed), a workflow in suspended state is simply waiting for something, is considered a running process.  Editing running  processes is actually a very bad idea that *could* cause all sorts of unpredictable results, and I want to be honest with you and say we are very uncomfortable with the fact that customers could potentially cause themselves problems by us allowing this.  In fact, even in its experimental guise we intended (although obviously made a mistake) that you could only ever edit failed processes, not running (suspended) processes.  The capability to do any editing was only ever added as an "experimental" feature, and specifically should not be used in production environments for this reason (see attached image for the related experimental option).  Recently we have taken that out of experimental status and implemented as intended, 

For this reason we have some reluctance to simply re-enable this, so I wanted to get an understanding how how important this is, and to see if its an option for you to edit the master and simply restart the process (which is far safer to do). 

Would be interested in your thoughts?

Gerry


 

[Gerry]

@Adrian Simpkins

Not sure this is the same problem, but can you tell me what you are doing to get that error?

 

Gerry

[Adrian Simpkins]

Hi Gerry

I have raised it to Get Support and Viktor is looking at it  Just thought it might be linked as I am having issues updating existing live BPM's today - error message is on the other post under my name

Thanks ! 

[Guest Paul Alexander]

Hi @Gerry

I can definitely understand where you're coming from...and I think that maybe explaining how I got myself in to this predicament in the first place may help explain why it's been such a godsend to be able to update a running process..

I changed the resolution part of a few processes so that, once resolved, the request would wait for a Status Change for a few days and, if nothing happened, it would then close the request.

BUT, I forgot to add a 'From Status' option in the Wait for Status Change node, and this means that the process just skips past this option, and reopens the ticket. 

I've updated this in the 'parent' process, so any new requests will work correctly. However, the tickets created before I discovered this fatal flaw obviously need to be updated, otherwise these requests just will not resolve. 

If you have a better way of dealing with these open requests I'm all ears, but, as I can't now update a running process I can't get these open requests to resolve. 

 

 

I am VERY careful to try not to break anything while updating a running process, but I can definitely see how it COULD cause more problems than it solves. I've been updating these requests for about a month (a few a day) so I'm hoping that there aren't many more left to deal with, so hopefully this won't be a problem for us for much longer.

 

Hopefully that gives you an insight as to the 'why' we've been doing this.....

 

thanks

 

Paul

[Gerry]

@Paul Alexander

Thanks for the explanation, we will look at the options and see what we can come up with, we have discussed internally and will look to re-enable this kind of ability. will take a couple of weeks though before anything can get into production. 

Gerry

[Guest Paul Alexander]

Hi @Gerry

Thanks for that...but, in the meantime, how can I get the requests (mentioned above) which WON'T resolve (because of me making a mistake in creating the BPM!) to resolve please? All it needs is the 'from status' in the Suspend - Wait For Change node to have a 'from status' added.

Without doing this these requests just keep looping and not resolving properly...

 

thanks

 

Paul

[Gerry]

@Paul Alexander

I am not sure what options there are really, apart from perhaps cancelling and re-logging those calls which is not ideal.  how many of them are you talking about?

Gerry

[Guest Paul Alexander]

@Gerry

Luckily there only seem to be a few of these left to go...so only one or two a day for the past couple of days and hopefully that number will fizzle out over the next couple of days. 

Victor has said that I can log the requests directly with him as and when they happen so he can sort them out on a one to one basis. So it's all good....thank you. 

[Gary@ADL]

wasn't aware we could do this! sorry if im late to the party but this could be pretty useful for us in some scenarios, for example for our change requests we have named approvers, if a member of staff leaves, and they were a named approver on a request, this means we cannot complete the change as it fails on the stage that the user is named in, normally we'd just raise another as you can, but can be a bit embarrassing having to ask the execs to re-approve changes they have already signed off,

 

cheers  

[Steve Giller]

@Gary@ADL That's a slightly different scenario - and you may be relieved to hear that the owner of an Authorisation can reassign it to another User.

So if you ensure that Authorisations are owned by the System Administrator then even in the unusual situation of multiple Users leaving or changing roles at the same time, you can sign in as the System Administrator and reassign the Authorisation to their replacement or whoever has taken over responsibility for Authorising that Change.

[Gary@ADL]

thanks @Steve Giller will bear that in mind for next time