I am experiencing an issue with the update of the reference date in a Wait shape within Pega Constellation 25.
Requirement:
A user completes a form where they define a deadline date for accepting invitations. Both the parent case and its child cases include a Wait shape in the flow. This Wait shape is configured as a Timer, using a Reference Date/Time that points to a property containing the user-defined deadline.
Up to this point, the functionality works as expected.
Issue:
The problem arises when the deadline date is modified. According to the requirement, the date should be editable at any time before it is reached. While the property value is successfully updated, this change is not reflected in the Wait shape. The assignments created based on the original date remain unchanged and continue to follow the initial schedule.
Question:
How can the updated date be propagated to the Wait shape so that the existing assignments are recalculated and aligned with the new deadline?
Whenever an assignment reaches a wait shape, there is an instance of assignment queued to a Queue Processor pyProcessSLA with scheduled time as the time mentioned in wait shape, So, if we update the property it just updates its value in the case but the initially queued instance is still with the old date. So, we need to update the value in the queue instance as well. For updating it, there is an existing activity pxAdjustSLATimes. This activity is generally for updating SLAs but it can also be used in this case as in the backend wait time is simply SLA with deadline time configured with the value selected in wait shape, In the post processing of your optional action in which this date is being updated, call this activity with the required parameters. Pass the updated value into DeadlineOverrideDateTime parameter of this activity. This will update the assignment with new deadline and also update the queue item with new scheduled time.
@VVNagaSaiN Thank you for the solution provided. I have also identified that restarting the stage updates the Wait shape, and I am unsure which approach is more suitable in this scenario.
Yeah, that is another solution. You can choose depending on your use case. If you want to simply provide an optional action and don’t want the case to move back and forth you can go for adjusting SLA.
If restarting a stage does not impact your life cycle, (like you don’t have any other steps before wait shape in that stage) then you can go with simply restarting the stage. But in future, if you decide to add any steps to that stage before the wait shape, you need to carefully write the logic to skip those steps and directly jump to wait when stage is restarted.
Constellation or Traditional UI, this is the same required solution.
Like you @HalynaK2 I’d prefer to do this via case management than an activity.
It has the added bonus of allowing you to insert other triggers/events/processing as part of normal case management if there are additional things that need doing.
This includes things like History / Audit events, like the fact this was wait shape was created (again)
You can look to increment a counter of how many times it was changed
You could look to create an additional audit of all the changes that are made
It also recreates the full wait shape logic, in case you have changes there.
Instead of restart stage, you could have an optional alternative stage to change to. This could have all that logic for waiting.
Like @VVNagaSaiN has said, it all depends on the requirements. In my experience projects tend to start asking for 1.1-1.3 and more, so I like the case management approach to handling it.
