version: 8.5p1
Workitem having expirationDate and wakeupDate as pastDate, once we ran the check expire workitem task , it should move the workitem to archival, but it’s not happening, just its setting the expiry state to the workitem
workitem is creating by LCM flow, while creating workitem we are setting the expiryDate and wakupDate to the workitem using interceptor script.
Any reason to for this??
Hidden Text
@Anjan_dummeda When you run the Check Expire Workitem Task, what do you see in the task result?
can you post/recheck the code in you interceptor script?
Regards
Ankush
check expiration task will run daily at 10AM, Its showing count of the work items
@Anjan_dummeda Seems you are working in a QA environment based on your screenshot. Could you please execute the task manually and let us know the result?
Also, are you using timeMachine to change dates for some testing?
@neelmadhav through timeManchine its working… but through check expired workitem scheduler its not working, just its setting the expired state..
Hi Anjaneyulu. Since the task counts the work item and changes it to state="Expired", the schedule and dates are being detected correctly.
The issue might be that the interceptor sets expiration and wakeUpDate directly, but does not configure the standard NotificationConfig that drives LCM escalation processing. NotificationConfig is only created when workItemHoursTillEscalation is present on the Approval step. Without it, the Check Expired Work Items task would not be able to process the work item through the standard expiration path. (Ref)
It might be worth trying the standard approach instead. Configure the Approval step with:
<Arg name="workItemHoursTillEscalation"
value="ref:workItemHoursTillExpiration"/>
<Arg name="workItemEscalationRule"
value="Expire Work Item"/>
<Arg name="workItemEscalationStyle"
value="escalation"/>
Then create Expire Work Item as an Escalation type rule:
return null;
Returning null should expire the work item through the standard processing instead of reassigning it. (Ref)
If you try this approach, I would suggest removing the direct setExpiration(), setWakeUpDate(), saveObject(), and commitTransaction() from the interceptor so that two different expiration mechanisms do not conflict. Testing with a new request should confirm if this resolves the archival. Also worth double-checking that Approval is selected under IdentityIQ Configuration > Work Items > Work Item Archives. (Ref)
Hi @punna0001 , thanks for the insight, but why its archiving via timeMachine configuration?
