I come back to a common theme of mine -- see Recovering from Pega rule cache issues (DRAFT)-- anything that is cached, that in extenuating circumstances needs to be pruned, that isn't primary data (rules, cases, etc) should be manageable: easily browseable and deletable.
[changed subject -- replaced "clearing out" with "analyzing" - June 22, 4:11pm]
***Updated by moderator: Lochan to close post*** This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Short of SMA, I don't believe there are any tools for deleting System-Queue-ServiceLevel instances. I'm not sure I understand the concern. Are these items in the broken queue or just valid SLAs you've decided you don't want to see run? Theoretically, you should be reviewing the broken queue regularly to both clear out items in there and more importantly, understand how they got into that state and to address the issue so it doesn't happen again. Queue items are data instances so they shouldn't be cached. If you remove a queue item from the database before the trigger deems it a valid item to process, it should never run. You should be able to create reports on that table and manipulate it via activities. If you have a reason to mass delete SLA items, that should be doable via bulk processing, although without knowing your business case, I'd caution against doing bulk deletes of queue items since it opens the door for all sorts of problems if you are too liberal in selecting what items to delete.
Mike - I generalized the subject line to be more clear.
Consider, if you will, that the confluence of our design and an bulk data load leads to thousands of ServiceLevels scheduled all for the same time.
I only discovered this by combing through the records manually (this begs a separate request -- that it should be trivial in Pega to define automated summary report definitions based on the property structure -- clustering by date fields and other fixed-selection fields).
Maybe I want to delete them because they were scheduled in error. Or maybe we want to reschedule them. Either of them we could do more easily in the primitive SQL world, but, since this is a BPM application, I'd like a control panel, showing cluster reporting, easy selection, delete or reschedule actions, and auditing.
Fair enough. I don't believe there is anything out of the box that does what you're talking about. You could definitely build something yourself that would allow you to do this. It would also be a great enhancement to the product. I'll ask around to see if I can get that added to someone's backlog, although if it's something you really want, you'd probably have more luck talking to your account executive. They have much more weight with product owners than I do.