Step Back Workflow Programmatically | Community
Skip to main content
J
jocamp
Level 3
October 16, 2015
Solved

Step Back Workflow Programmatically

  • October 16, 2015
  • 3 replies
  • 1840 views

How would you go about programmatically stepping a workflow back? I've used the WorkflowSession.complete(WorkItem, Route) like so -

List<Route> backRoutes = session.getBackRoutes(item); Route rte = backRoutes.get(0); session.complete(item, rte);

However, this code seems to split the workflow into 2 workitems while stepping back so that in my inbox i have the next step and the previous step.

If there's no way to avoid having the two steps, is it possible to delete/remove the unwanted WorkItem?

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by jocamp

    Ugh, alright figured it out, something simple of course. If anyone else experiences this -

    The problem was that my step B was a process assembler with two processes. The first one checked for the property and stepped back but the assembler went ahead and ran the next process. So the first process generated the A work item and when the second process finished, the C work item was generated.

    Should have double checked, it was actually that the "Handler Advance" checkbox in the process assembler step is automatically checked. This is what causes the duplicate work items.

    3 replies

    Scott_Brodersen
    Scott_Brodersen
    Level 8
    October 16, 2015

    So, if you have steps A - B - C in series, and you step back from B, you have inbox items for A and C? 

    thanks

    scott

    J
    jocampAuthor
    Level 3
    October 16, 2015

    Correct, A and C are participant steps while B is a process step which checks for a property on the payload. If it doesn't find the property it calls the code above.

    Edit: Just ran a test with only three steps like you described and it seems to be working as expected. Not sure why it's splitting like that in my larger workflow. Must be something funky with the OR split. I'll look into it more, thanks.

      J
      jocampAuthorAccepted solution
      Level 3
      October 16, 2015

      Ugh, alright figured it out, something simple of course. If anyone else experiences this -

      The problem was that my step B was a process assembler with two processes. The first one checked for the property and stepped back but the assembler went ahead and ran the next process. So the first process generated the A work item and when the second process finished, the C work item was generated.

      Should have double checked, it was actually that the "Handler Advance" checkbox in the process assembler step is automatically checked. This is what causes the duplicate work items.

        Terms & ConditionsAccessibility statement

        Loading footer...