3 Replies Latest reply on Jan 27, 2016 8:22 AM by florian1

    Issue with "Pausing" Workflow - Heat 7.x

    jnewman@seyfarth.com Rookie

      I am currently having an issue, have called support and have been told that we don’t have a lot of options.  We use Service Catalog entries in a centralized onboarding and offboarding process that’s initialized by the Service Desk.  Specifically, with the off-boarding (termination) process, I have two Date/Time parameters in the process.  One is a 30 day wait and the other is a 90 day wait.  These are hidden Date/Time fields on the form that are calculated as Dateadd(Day, 30, CurrentDateTime).  Simple enough.  The process then “waits” for these dates to pass and then additional workflow kicks off.  EVERY NOW AND THEN, I am asked to extend the period (i.e. someone says I need more than 90 days to review, etc.)  I’ve tried to go in and actually edit the parameter in the ServiceReqParam table, and this has worked, meaning I CAN edit the parameter, however the workflow still kicks with the old date. 


      Does anyone know how to edit a parameter (workflow) while it’s currently still running?

        • 1. Re: Issue with "Pausing" Workflow - Heat 7.x
          florian1 Expert

          Hi Jeremy,


          you can do this by adding some fields to the ServiceReq BO:


          1) Add 3 fields to your ServiceReq business object

          - TerminationDate: datetime

          - hasTimeoutChanged: bool, default: false

          - isOffboardingSR: bool, default: false


          2) Add a tab to your ServiceReq Layout

          - include the TerminationDate field

          - visible: isOffboardingSR


          3) Modify your workflow

          right after START:

          - isOffboardingSR: true

          - TerminationDate = <TimeoutDate from Step2>



          If hasTimeoutChanged = True -> repeat the wait element (don't forget to reset it to "False"!)

          If Timeout reached -> go to next step:


          Please beware that you have to technically avoid loops in here (different ways to do so)!



          4) Add a client-side BusinessRule:

          - If TerminationDate is changed -> hasTimeoutChanged = true


          5) Modify the timeout from within your SmartClient to the date needed.

          --> When you change your timeout in the newly created ServiceReq tab, the BusinessRule will set hasTimeoutChanged to True. The workflow instance will reach "ok" and reenter the wait-block and waits for your modified date.



          The disadvantage of this procedure is that your original termination date won't be overwritten.

          You could do this with SQL afterwards though.

          • 2. Re: Issue with "Pausing" Workflow - Heat 7.x
            jnewman@seyfarth.com Rookie

            Florian, this is great, I appreciate the time in your response.  I just got a chance to take a look at the process and noticed that you mentioned "...You could do this with SQL afterwards though..."  What do you mean by this?  From what you are saying, modifying SQL would be a much easier option and something that I have dabbled in before, albeit, unsuccessfully.  Our original idea was modifying the ServiceReqParam values in SQL, which we attempted and this did NOT work (meaning, I set a date of 2/1/2016 for our 90 day wait param and the workflow still kicked it after 1/1/2016).  Make sense?

            • 3. Re: Issue with "Pausing" Workflow - Heat 7.x
              florian1 Expert

              If you only modify the ServiceReqParam table the workflow engine won't recognize it as it is already running.

              I'm pretty sure this could work somehow (using Frs_ops_workflow_timer and/or frs_data_workflow_instance) but wouldn't recommend it technically as this

                  - can cause data inconsistencies.

                  - will force you to manually stop and restart the workflow engine (to avoid Deadlocks etc.).


              With the last sentence I was referring to something else:

              The technically "cleaner" way would be the way I described it. The only disadvantage here is that your submitted termination date (=ServiceReqParam) does not neccessarily match the workflow instance's value (=ServiceReq->"TerminationDate") anymore when you manually changed this value in your SmartClient.

              -> so if your original Service Request's termination date (=ServiceReqParam)  needs to display your modified TerminationDate (ServiceReq->TerminationDate) you will have to update ServiceReqParam once, e.g. like this:

              UPDATE ServiceReqParam

              SET ParameterValue = TerminationDate

              FROM ServiceReq sr

              INNER JOIN ServiceReqParam srp ON sr.RecId = srp.ParentLink_RecID

              WHERE ServiceReqNumber = <yourSRNumber> AND ParameterName ='<yourTerminationParameterName>' AND ParameterValue != TerminationDate


              Hope that's more clear now.