Process Definition Error on Wait Event

Hi everyone,

We have an issue that is not specific to a specific module and is happening on process definitions indiscriminately.

The issue is with a process definition that is set up as below

It is a smaller version of the process definition by Sugar given here: https://support.sugarcrm.com/Knowledge_Base/SugarBPM/Capturing_How_Long_a_Record_Spends_in_Each_Status_Using_SugarBPM/

The issue is that when the action event triggers for the first time and it cycles back to the wait event, the wait event errors. There is nothing of note in the logs and I have checked the following:

-SugarBPMTm Scheduled Job is set to "As often as possible"

-In the pmse_bpm_flow table, the first wait event has a due date of x mins after the start events end date (as you would expect)

-The second wait event record when generates the due date and end date of the previous element are the same time stamp. But this errors as soon as it generates so may not be relevant. 

I cannot recreate this on any other site which suggests some form of customisation. But considering its not module specific and the logs are less than helpful I would appreciate any advice that can be offered

Parents
  • Hi Brady,

    Does the process still error on the second Wait Event occurrence if, strictly as a diagnostic test, you remove the Change Field Event?

    When something is not reproducible to support in a stock test environment but is reproducible in one instance containing customizations, we make a full copy (clone) of the affected instance, reproduce the issue in the copy, and then strip out customizations we suspect to be impactful until we can no longer reproduce in the clone. At the customization we remove that ends reproducibility, we see if we can isolate it to the customization specifically, and we try to determine what about it could have caused the issue.

    We look to logs including PHP error logs, sugarcrm.log, the pmse log, console when relevant, for clues in such cases. But, as you pointed out, there are times when the errors simply are not happening or not helpful, especially when customizations are involved.

    Regards,
    Patrick McQueen
    Director, SugarCRM Support

Reply
  • Hi Brady,

    Does the process still error on the second Wait Event occurrence if, strictly as a diagnostic test, you remove the Change Field Event?

    When something is not reproducible to support in a stock test environment but is reproducible in one instance containing customizations, we make a full copy (clone) of the affected instance, reproduce the issue in the copy, and then strip out customizations we suspect to be impactful until we can no longer reproduce in the clone. At the customization we remove that ends reproducibility, we see if we can isolate it to the customization specifically, and we try to determine what about it could have caused the issue.

    We look to logs including PHP error logs, sugarcrm.log, the pmse log, console when relevant, for clues in such cases. But, as you pointed out, there are times when the errors simply are not happening or not helpful, especially when customizations are involved.

    Regards,
    Patrick McQueen
    Director, SugarCRM Support

Children
  • Hi Patrick,

    I had previously tried to add a "Add Related Record" in between the action and the second wait to see if it was the action causing the second wait instance to fail but that did not work (Apologies I forgot to include that check in the original post)

    I have now tried your suggestion so that it now Starts, Waits, Gateway and then goes back to the wait directly. It still errors as soon as it hits the wait for a second time.

    We are currently working on a pre cloned stage site and there is only one logic hook on the application level, This has been removed and still has the issue. 

    Do you have any other ideas as to what might be causing the behaviour?

    Thanks

    Brady

  • Hi Patrick,

    Just to add to this I have added a second wait period into the flow. So now the first wait is the initial one and when it hits the loop, it uses the second one. 

    With this it allows the new wait period to trigger, following the gateway. However when it loops around a second time it errors. So it looks like there is something stopping the same wait element be used more than once?

    Thanks

    Brady