Send workflow emails based on date field

[ChrisHare]

User wants to create a document and specify a review date.  The workflow needs to send out an email 60 days before the review date and the day of the review date.  The catch is that the review date may change after the document is created.  I tried using a timer to wait 5 minutes and then called a java method we wrote to see if the date had changed but that was overloading the workflow manager because of the volume of active documents.  I could drop the timer and implement a java loop until the appropriate date but there are concerns this would move the pressure to the method server.  Is it possible to send emails based on a date attribute that can change without pressure to the system?

[ChrisHare]

Alternate option?  Put the notification process in a separate workflow.  The main workflow finishes and automatically kicks off the notification workflow.  I customize the edit GUI to check the review date on document check in.  If the date has changed, then terminate the running notification workflow and start a new one using the new date.  Anyone know the APIs for terminating/starting workflows?

[Florent]

With the few information you provide, I'm not sure to understand clearly how your worklow notification tasks are created.

I had a similar need and to achieve this, I created a custom scheduled queue. Maybe you can investigate this option, and update the relative scheduled tasks when the date is changed.

Anyway, if you wish to start a process from API, you should use WfEngineHelper.service.createProcess()

http://support.ptc.com/cs/wncdoc/110/wcapi/wt/workflow/engine/WfEngineService.html#createProcess-wt.workflow.definer.WfProcessDefinition-java.lang.Object-wt.inf.container.WTContainerRef-

[ChrisHare]

Thank you for a piece to my puzzle.  I tried to post a screenshot but it won't let me.

My current workflow is using a conditional, a timer, and notification robots.  The conditional simply checks the review date attribute of the document and compares it to today's date.

- If difference is zero or less, send the Review Required email and end the workflow

- If difference is 60 or less, send the Review Pending email, flip a boolean flag so I don't send it again, and go back to the conditional

- Otherwise, go to the timer and then back to the conditional

Timer was set to 5 minutes but that was overloading the workflow manager and other workflows were taking longer to process.  I've increased the timer to 24 hours but that could result in delay of email.  I could drop the timer and put a loop in the conditional with a 5-minute delay but there are concerns this will just shift the performance issues from the workflow manager to the method server.  OOTB the email robot has no timing options.  It just sends the email.  I have to control when it is sent somewhere else.  Like I said before, wouldn't be a problem if it was a static date but user wants to be able to change the review date (could be forward or backward).

[Florent]

I recently updated few workflows because of the same reason !

The workflow was designed as you described, and the BGMS was always running timers...

I suggest you to schedule the email posting and find a way to update (or delete and create a new one) the task when the user changes the review date.

[ChrisHare · Accepted solution]

My workload has forced me to simply increase my timer from 5 minutes to 24 hours in order to meet deadlines.  I did open a support case with PTC and got the following information.  Hopefully this will help someone else if they wind up in the same situation.

For anyone else looking at this post for a solution, the proposed answer is to have the main workflow kick off a notification workflow (where all the emails are scheduled and sent).  Add a listener to the document check in which will verify if dates have changed, terminate the running notification workflow, and start a new notification workflow.

"I’ve attached internal article CS64718 with information about using API to create and start workflow processes. Article CS20213 shows how to collect all workflow processes associated with a particular object. Article CS49682 shows how to then terminate the process once identified. I’ve also attached internal article CS21481 which shows how to determine the type of document to use as a conditional when building your listener."