Grep the log for all lines containing the rpc id (0004980524). You'll see that the error is caused by filter MYIT:SR Expected Completion Date:Calculate and it tries to execute Application-Bus-Time-Add 1506443824 1 4 SGP000000000168 SGP000000000168 but SGP000000000168 does not exist.
SRM Expected Completion Date calculation gives some information on the workflow.
Maybe the SGP000000000168 has some workdays/holidays configured but the name isn't correct anymore?
Do you intentionally use turnaround time in your SRD?
it is not about your support group. there is a parameter mistake here. Since you've defined turnaround time in your SRD, it is trying to calculate Expected Date using business hours. And it is doing this by invoking the process command "Application-Bus-Time-Add".
Command parameters are as below:
Application-Bus-Time-Add $TIMESTAMP$ $Turnaround Time$ $Time Unit$ $HolidayTag$ $WorkDayTag$
and in your log, it populates the parameters with following values:
Application-Bus-Time-Add 1506443824 1 4 SGP000000000168 SGP000000000168
1506443824 --> TIMESTAMP
1 --> Turnaround Time
4 -->Time Unit
SGP000000000168 --> Holiday Tag
SGP000000000168 -->WorkDay Tag
As you see, it is populating Holiday Tag and WorkDay Tag parameters with support group ids. It was supposed to be populated with Business Time Holiday name or ID. It is giving the error "Entry does not exist in database" because you don't have a Business Time Holiday with the name "SGP000000000168"
This filter is called during a service operation on form "MYIT:SR Expected Completion Date" but I couldn't see the filter calling that service action in your log.
Since this filter has the runif qalification as --> ('Turnaround Time' != $NULL$)
You may set the turnaround time to NULL in your SRD as a workaround.
However, We need to see the filter which is calling this service action in the logs in order to understand why/how service action is being called with incorrect parameters.
Could you resolve the issue? If so, please explain how you did so others can use that knowledge and mark the discussion as Answered with the most helpful answer.
I noticed you have SLM activity right before the 302 error. More specifically SLM:EventSchedule. Take a look at this KA: KnowledgeArticle - BMC
I had been seeing the same issue where a an UPDATE is issued to a SLM:EventSchedule record by user activity but the record was deleted by the escalation mentioned in the KA before the user-triggered UPDATE statement was issued to the DB.