Randomly duplicated item SLAs

[Blair5]

We SLAs set on our items, as well as our sc_tasks. When someone went to run a report for item SLAs, they noticed that there were quite a few duplicates. At first, I thought it could be because there was a 'current.update' in one of the business rules that was causing this. So, I removed that portion of the script in DEV and all seemed fine. However, when I moved this change to our SIT environment, it didn't fix the issue.

I went back to DEV and saw that the duplicate item SLAs never really occured there. Now that I moved the fix to SIT, I see that it happens a lot. However, it happens at random. I can submit the same item 10 times, and only 4 out of those 10 items have duplicated SLAs.

I'm hoping someone can help me. I've looked in the obvious places (at least, I think I have). Any help or direction is greatly appreciated.

Thank you.

[Blair5]

As per Service Now Support:


--------------------------------------------------------------------------------

2012-05-29 13:20:56 - Ben Shamsian (NOW) Additional comments
Solution Accepted by ben.shamsian

Closing Incident

--------------------------------------------------------------------------------

2012-05-29 13:15:55 - Blair Reinhart Additional comments
reply from: Blair_reinhart@glic.com

Ben,

Yes - close the ticket.

Blair Reinhart
Associate Developer, Corporate BTS and IT Security/Risk
Tel 610-807-6025
Mobile 484-225-5843
3900 Burgess Pl., Bethlehem, PA 18017
blair_reinhart@glic.com




The Guardian Life Insurance Company of America

www.guardianlife.com







From:

--------------------------------------------------------------------------------

2012-05-29 13:12:13 - Ben Shamsian (NOW) Additional comments
Hi Blair , The development team have no current plans to address this in the older "Fall 2010" SLA code. Also since there is a workaround and it has worked for you, we are asking if this ticket can be closed, Thank you very much

--------------------------------------------------------------------------------

2012-05-29 13:08:04 - Blair Reinhart Additional comments
reply from: Blair_reinhart@glic.com

It's linked to a PRB. How will we be able to track the PRB if this
incident is closed?

Blair Reinhart
Associate Developer, Corporate BTS and IT Security/Risk
Tel 610-807-6025
Mobile 484-225-5843
3900 Burgess Pl., Bethlehem, PA 18017
blair_reinhart@glic.com




The Guardian Life Insurance Company of America

www.guardianlife.com







From:

--------------------------------------------------------------------------------

2012-05-29 13:00:54 - Ben Shamsian (NOW) Additional comments
Thank you, can I close this ticket? Please let me know

--------------------------------------------------------------------------------

2012-05-29 12:55:56 - Blair Reinhart Additional comments
reply from: Blair_reinhart@glic.com

Ben,

Yes the work-around is in place and is working fine.

Thank you.

Blair Reinhart
Associate Developer, Corporate BTS and IT Security/Risk
Tel 610-807-6025
Mobile 484-225-5843
3900 Burgess Pl., Bethlehem, PA 18017
blair_reinhart@glic.com




The Guardian Life Insurance Company of America

www.guardianlife.com







From:

--------------------------------------------------------------------------------

2012-05-29 12:25:50 - Ben Shamsian (NOW) Additional comments
Hi Blair, Did the workaround worked for you? Thank you

--------------------------------------------------------------------------------

2012-05-15 06:16:59 - Blair Reinhart Additional comments
reply from: Blair_reinhart@glic.com

We are still testing the work around. I will close the ticket when we feel
that it has been tested thoroughly.

Thanks.

Blair Reinhart
Associate Developer, Corporate BTS and IT Security/Risk
Tel 610-807-6025
Mobile 484-225-5843
3900 Burgess Pl., Bethlehem, PA 18017
blair_reinhart@glic.com




The Guardian Life Insurance Company of America

www.guardianlife.com







From:

--------------------------------------------------------------------------------

2012-05-14 10:08:59 - Tony Bagalini (NOW) Additional comments
Hello,
Your incident is in the status of solution proposed and we feel it has been resolved or has a viable work around.
If this is correct and the solution is appropriate please accept the solution or if this is not correct please accept our apologies and reject the solution.
Thank you and have a great day!

--------------------------------------------------------------------------------

2012-05-11 14:52:44 - Tony Bagalini (NOW) Additional comments
Hello,
Your incident is in the status of solution proposed and we feel it has been resolved or has a viable work around.
If this is correct and the solution is appropriate please accept the solution or if this is not correct please accept our apologies and reject the solution.
Thank you and have a great day!

--------------------------------------------------------------------------------

2012-05-08 13:40:52 - Luis Reis (NOW) Additional comments

1. As a workaround, switch the 2010 SLA Engine "Process SLAs" business rule to "after", from "async", so that it finishes executing before the Workflow engine executes.

2. switch to the 2011 SLA Engine (but there are a handful of defects in the version they are running, so this may not be the current best option if they wish to stick with Aspen Patch 2 for the moment. When they are in a position to upgrade, Aspen Patch 4 - when it becomes available - or later would be where they want to go to, in order to switch.)