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.
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?
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:
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.