Skip to main content
A
AntonioVillanue1-Visitor
1-Visitor
August 12, 2017
Question

I'm back...again. The return of the New Village Crier!

  • August 12, 2017
  • 3 replies
  • 2923 views

PTC recommends that you keep an eye on the queues. Workflows are heavily dependent on queues to function.  There is good reason. Take for example this very useful OOTB expression robot:

workflowrobot.png

This robot sets the state of all the changeables on an EC.  The helper code from PTC will fail if items are checked out.  Users being users, often complete tasks with check out objects causing this robot to fail.  It is very tempting to just continue the failed task in the Process Manager or set the state manually.  This will leave the failed expression in the queue as a ticking timebomb, waiting for you to accidentally restart it.  What's the harm in that you ask? Let me tell you what happens...

So you have a queue that looks like this:

queue.png

You are having workflow issues and PTC Tech Support recommends you restart all these Severe tasks (robots may be in another queue, I forget which, oh and BTW, this did happen).  The workflow has finished and your change notice is released as well as the changeables.  When the task is resumed, it can now complete, and it does, setting your changeables from Released to Under Review. Nice. But wait...there's more.  Since this is a workflow, it starts re-executing the next task from that position in the workflow. The workflow rises from the dead and comes back to life.  WorkItem tasks are sent out again and users get all confused. What's worse, you've lost data integrity since released data can start changing on you.

 

The takeaway - put some error checking around set state robots or bots that can fail (redirect to user task to try again) and never blindly restart queue processes without knowing what they do.  Clear out failed robots that you continue past so they are gone for good.

    3 replies

    B
    BjoernRueegg17-Peridot
    17-Peridot
    August 14, 2017

    I see your point and also share some of your thoughts. But since 10.0??? (or 10.1) we implemented some business rules to exatly wait until all rules are good. Otherwise the workflow can't go on.

     

    This rules can be checkedout objects, missing line numbers, parent child phase check, part document checks, etc. Since we implement such rules, most of the workflows run smoothly and we won't need to restart any workflows.

     

    And if you restart the workflow, you have to terminate the current one, otherwise things like you described are happening. 

    D
    Darquise12-Amethyst
    12-Amethyst
    January 28, 2021

    How do you create a rule in the workflow to ensure that the object has been checked in?

    A
    AntonioVillanue1-VisitorAuthor
    1-Visitor
    August 14, 2017

    Just got to 10.2 and Business Rules are high on my list. In my example, the workflow was closed but the "severe" task that was skipped remained in the queue. Perhaps it has been fixed. Will keep an eye out for it.

    Terms & ConditionsAccessibility statement