Question
Pegasystems
US
Last activity: 17 Jul 2017 11:12 EDT
why doesn't my SLA activity run ?
Hi. I copied one of the PegaSample flows into my own ruleset, and then made my own service rule and sla activity, and edited the assignment shape to refer to my service rule, but my sla activity never runs. In fact, I eventually see an error for my work on the work list that says "Error: Agent SLA Open" . Do I need some special privilege to be able to have my own SLA activity ?
Thanks. /Eric
***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.
Accepted Solution
Pegasystems Inc.
US
Hi Eric,
There is a heavy-handed way to address the behavior you have described and a better-practice way. The heavy-handed way is to notice that a data-admin-requestor object refers to access group prpc:agents, and change that reference to your own access group. It works, but it is not a great solution since it affects other people on the system.
The better-practice way is to create a subclass of the pegasample class in your own ruleset and copy the flow into that class (you can leave your service level rule in the original pegasample class).
The reason this works and the original flow does not work is explained by the following: basically, the ruleset of the class of the work object is used for determining the access group, so by making your own class, your class ruleset will be yours and not the system ruleset.
Pegasystems Inc.
US
Hi Eric,
Great question. On behalf of the Pega Support Community, I just wanted to let you know that we've seen that it's been a while since you posted this. I'll look around to see if I can find someone who might be able to continue this discussion with you. In the meantime, maybe this bump will help bring it to the attention of other community members.
Thanks.
B.
Accepted Solution
Pegasystems Inc.
US
Hi Eric,
There is a heavy-handed way to address the behavior you have described and a better-practice way. The heavy-handed way is to notice that a data-admin-requestor object refers to access group prpc:agents, and change that reference to your own access group. It works, but it is not a great solution since it affects other people on the system.
The better-practice way is to create a subclass of the pegasample class in your own ruleset and copy the flow into that class (you can leave your service level rule in the original pegasample class).
The reason this works and the original flow does not work is explained by the following: basically, the ruleset of the class of the work object is used for determining the access group, so by making your own class, your class ruleset will be yours and not the system ruleset.
Pegasystems
US
Thanks Kip. Copying the flow into my ruleset worked, but it still seems to me that merely putting the service rule and the service activity in my own ruleset should have been enough. Also, I really don’t want a copy of the flow in my own ruleset since if the flow is then changed by Pega, my unwanted copy will eclipse those changes.
Shouldn’t Pega look at the ruleset of the service rule and/or the service activity for determining which access group to run the sla under, rather than only looking at the ruleset of the class ?
If you agree, how should we report this issue ? I don’t think I need an SR, since I am unblocked now, but I do suggest the behavior is not currently the best.
Thanks again for your response. /Eric
Pegasystems Inc.
US
Eric,
Glad to hear Kip was able to get you out of your jam. And your point is well taken. I agree that we don't need to raise an SR for this, but the Pega Support Community is always looking for valuable input like this from our members.
At the moment, we do not have features in place to officially manage and track such feedback within the community itself. As part of the Community Staff though, I can capture your feedback and communicate it internally.
In the meantime, since Kip's reply did, in fact, resolve your issue, would you be OK with marking it as the "Correct Answer"? We are constantly working to grow our knowledge base and indicating when a question is answered is very helpful to our effort.
Thanks.
B.
Pegasystems
US
Sure, we can mark Kip’s as “correct answer”. I am using “reply” in my outlook email for these last few replies, and unless there’s a way to mark it as “correct answer” in email, it will have to wait until I’m actually back in that real forum to mark it, unless you want to mark it for me. Thanks again for the help. /Eric
Pegasystems Inc.
US
I'll let you do the honors Eric. Before you do though, I just wanted to make sure you saw Jim's reply. Does that shed any more light on your issue? As with many things, there can often be many right answers to a question. While you can only mark one response as the "Correct Answer", you also have the ability to mark other responses as "Helpful Answers". We encourage you to do so as you continue participating in the community, as it both helps provide clarity to the discussion when other members read it and rewards members who step up and participate.
Updated: 17 Feb 2015 15:04 EST
Pegasystems Inc.
US
Perhaps I do not understand the problem correctly, but it sounds to me like the problem is that the Access Group used by the SLA agent (Pega-ProCom / ServiceLevelEvents agent) does not have Eric's application RuleSet in it. Rather than changing the Requestor (Data-Admin-Requestor) instance, can't you just update the Agent Schedule (Data-Agent-Queue) instance for the Pega-ProCom agent to run with an access group appropriate for the application? If you don't do this, all of the agents will have trouble finding application level rules.
Pegasystems
US
>>> can't you just update the Agent Schedule (Data-Agent-Queue) instance for the Pega-ProCom agent to run with an access group appropriate for the application? If you don't do this, all of the agents will have trouble finding application level rules.
I guess it depends on the ruleset setup for developing the app. One setup might be that there's two developers working on the app, one with private ruleset dev1R and the other with dev2R . When each is ready to check in their changes, they might copy their latest to the appR ruleset. Certainly you're right , Jim, that the appR ruleset should be in the agent scheduler's ruleset list so that any agent servicing the app (including, of course, the SLA agent) will see the appR ruleset.
However, the developer using the private dev1R ruleset doesn't want other users seeing that ruleset, but that developer does want to test SLA activities that are in that ruleset.
It still seems to me that in the SLA's attempt to switch to the correct access group during servicing, which attempt it does make, it makes most sense for it to choose an access group containing the ruleset of the service rule (and / or the service activity) than merely choosing an access group containing the ruleset of the work class.
>>> can't you just update the Agent Schedule (Data-Agent-Queue) instance for the Pega-ProCom agent to run with an access group appropriate for the application? If you don't do this, all of the agents will have trouble finding application level rules.
I guess it depends on the ruleset setup for developing the app. One setup might be that there's two developers working on the app, one with private ruleset dev1R and the other with dev2R . When each is ready to check in their changes, they might copy their latest to the appR ruleset. Certainly you're right , Jim, that the appR ruleset should be in the agent scheduler's ruleset list so that any agent servicing the app (including, of course, the SLA agent) will see the appR ruleset.
However, the developer using the private dev1R ruleset doesn't want other users seeing that ruleset, but that developer does want to test SLA activities that are in that ruleset.
It still seems to me that in the SLA's attempt to switch to the correct access group during servicing, which attempt it does make, it makes most sense for it to choose an access group containing the ruleset of the service rule (and / or the service activity) than merely choosing an access group containing the ruleset of the work class.
Granted, if all developers did check-outs directly from ruleset appR in the above example, then putting appR in the agent scheduler's ruleset list would be a fine way to solve it. However, there are reasons to want each developer to have their own ruleset as well (such as dev1R in the above example). One reason I can think of is for debugging rule-utility-functions, whose checked out versions aren't even seen by the operator who checked them out, and hence a developer would want to check in their code to the dev1R ruleset and not the appR ruleset so that during testing no one else can "see" the new version of the function yet.
A second reason would be for testing SLA activities. My understanding is that if I have an activity checked out, although my interactive session sees the checked out version, the SLA session won't see it since it is logged in as "system", not my operator id. So to test my activity, I'd need to check it in, but I don't want to check it in to appR where other developers stumble on it, so I want to check it in to my dev1R ruleset.
Thanks. /Eric