Manually mark step as complete

761 views
Skip to first unread message

mgl...@gmail.com

unread,
Aug 6, 2014, 7:37:29 PM8/6/14
to camunda-...@googlegroups.com
There are times when a task fails and we 'fix' it outside of Camunda. Re-running the task is not possible because the work is already complete. How do I tell the process that the task is actually complete and it can move on to the next step. We don't want to cancel the entire process.

On the same sort of tack, is there a way to go into a process and 'suspend' just a task such that that task is skipped on future instances. For example we know that a task wont work and put in manual workarounds. We don't want to deploy a new version of the process but for a period of time we want one of the process tasks skipped. Is this possible?

Thanks,
Mike

Bernd Rücker (camunda)

unread,
Aug 7, 2014, 1:39:31 AM8/7/14
to camunda-...@googlegroups.com
Hi Mike.

There is no out-of-the-box-feature available - but what we do in projects
normally is: define some process variable which can be set (e.g. a Boolean
set to TRUE) which means that a certain activity is skipped. This might
include the activity-id.

And then you add a simple "if" statement to your delegates (maybe in a
common super class?) or - if you use expressions with Spring/CDI - you might
exchange the behavior of the ServiceTask to include this.

Then it is easy to set the variable e.g. via cockpit and retry a task which
now is skipped. You could even write a plugin for this to add a specific
button :-)

Cheers
Bernd
Consultant & Evangelist (www.camunda.org/community/team.html)
We are hiring: http://www.camunda.org/community/jobs.html




-----Ursprüngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von mgl...@gmail.com
Gesendet: Donnerstag, 7. August 2014 01:37
An: camunda-...@googlegroups.com
Betreff: [camunda-bpm-users] Manually mark step as complete
--
You received this message because you are subscribed to the Google Groups
"camunda BPM users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/camunda-bpm-users/10c4295e-c996-411d-b488-4e0349abff16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

mgl...@gmail.com

unread,
Aug 7, 2014, 1:58:58 AM8/7/14
to camunda-...@googlegroups.com, mgl...@gmail.com
Thanks Bernd.
Make sense and should be easy to implement.

Cheers,
Mike

webcyberrob

unread,
Aug 7, 2014, 5:04:11 AM8/7/14
to camunda-...@googlegroups.com
Hi Bernd I'd suggest a slightly different strategy...

I like to think of the engine semantics as guaranteed at least once task execution rather than at most once. Hence that being true, I'd prefer that the task or service was idem potent.

If you encode the ability to bypass a task in the process, then there's a risk that the integrity of the audit trail is compromised (history says the task was run but did it really?)

Hence I would advocate that idem potency is preferred over bypass...

Regards

Rob

Daniel Meyer

unread,
Aug 8, 2014, 12:33:21 AM8/8/14
to camunda-...@googlegroups.com
@Bernd, do you mean something like this:

With Spring or CDI it would be straight forward to implement an
interceptor with an annotation binding:

public class ConditionalSkipDelegate implements JavaDelegate {

@SkipTask("foo")
public void execute(DelegateExecution execution) throws Exception {

}

}

Where "foo" is the name of a process variable such that if the variable
is not null and has the boolean value "true", the java delegate is not
actually invoked but the invocation is skipped.
The history would still show that the activity was executed, it would
not have executed its actual behavior.

Daniel


Bernd Rücker (camunda)

unread,
Aug 8, 2014, 12:54:31 AM8/8/14
to camunda-...@googlegroups.com
More or less yes. I would not use an annotation though but use a variable
relating to the activity id - as you may use the same delegate on different
service tasks - and I normally want to shut down the service task - not the
delegate.

And I would do it with as less magic as possible - so everybody in the
project can understand what's happening there.

For history: You still have the skip variable in the history - so you can
still see that it is skipped. A cockpit plugin could even visualize that ;-)

-----Ursprüngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von Daniel Meyer
Gesendet: Freitag, 8. August 2014 06:33
An: camunda-...@googlegroups.com
Betreff: Re: AW: [camunda-bpm-users] Manually mark step as complete
--
You received this message because you are subscribed to the Google Groups
"camunda BPM users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/camunda-bpm-users/53E4530E.1040509%40camunda.com.

Daniel Meyer

unread,
Aug 8, 2014, 2:18:52 AM8/8/14
to camunda-...@googlegroups.com
Ok, makes sense.

Just to put a somewhat crazy idea out there: have we ever thought about interceptors at the process level?

<serviceTask id="foo" />

<serviceTask id="bar" />

<camunda:interceptor activityType="serviceTask">
  <camunda:script>
    if(activityInvocation.getExecution().getVariable('skip')) {
      activityInvocation.skip();
    } else {
      activityInvocation.proceed();
    }
  <camunda:script>
</camunda:interceptor>

Daniel

Daniel Meyer

unread,
Aug 8, 2014, 2:21:08 AM8/8/14
to camunda-...@googlegroups.com
Or, to be more in tune with your suggestion to include the activity id in the variable

<camunda:interceptor activityType="serviceTask">
  <camunda:script>
    if(activityInvocation.getExecution().getVariable('skip-'+activityInvocation.getActivityId())) {

Bernd Rücker (camunda)

unread,
Aug 8, 2014, 3:45:45 AM8/8/14
to camunda-...@googlegroups.com

Interessting idea – but from my point of view no priority as it is easy to implement without this feature already. So I have quite some stuff higher in my wish list :-)

 

Von: camunda-...@googlegroups.com [mailto:camunda-...@googlegroups.com] Im Auftrag von Daniel Meyer
Gesendet: Freitag, 8. August 2014 08:21
An: camunda-...@googlegroups.com
Betreff: Re: AW: [camunda-bpm-users] Manually mark step as complete

 

Or, to be more in tune with your suggestion to include the activity id in the variable

--

You received this message because you are subscribed to the Google Groups "camunda BPM users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.

Reply all
Reply to author
Forward
0 new messages