I would like to replace an Advanced Agent with a Job Scheduler rule. However, I am having trouble getting the Job Scheduler rule to run like the other OOTB jobs, my job does not even appear in my list of jobs from the Admin Studio portal.
Here is my configuration of the Job Scheduler rule:
-Enable job scheduler = yes; associated node types = RunOnAllNodes; Schedule = multiple times a day every 5 minutes; context = Access group of 'App:Administrators'; Activity = sets a log message; Application is Jboss
Any advice on troubleshooting this would be great!
Looks like you need to add your access group to the AsyncProcessor requestor type. Might be a good practice to set aside a "Batch" access group and reference that in the requestor type rather than "Administrators", unlike what you see in the attached screen shot. :) Once you add your application access group, and refresh the Job Scheduler display in Admin Studio, your job *should* show up in the list,
You can read a bit more on the AsynchProcessor requestor type here.
Although your suggestion does function, isn't it weird to have to override the default access group referenced in the server's common Requestor Type rule?
This seems to binds your application specific job to the environment and thus taint your AsyncProcessor definition. How would you configure multiple jobs if the by design belong to two distinct applications and have them all appear in Admin Studio? Does this mean one would have to define some shared Access Group that spans multiple applications?
Perhaps the App:AsyncProcessor just provides the context to gain access to the Application layer and its work pool (we kept role PegaRULES:AsyncProcessor). However I cannot see how this pattern translates to multiple -app specific- jobs dispersed over multiple applications on the same Pega cluster -- like we had with Advanced Agents.
As it turns out it suffices to just append all your applications App:AsyncProcessor references in the Requestor Type rule and somehow needs to be marked as default at some point in time for Admin Studio to notice the new configuration. Why?
However -as usual with unversioned rule types- you can only associate one ruleset at most (for auto-packaging reasons). You should leave "No associated ruleset" but you will get a somewhat misplaced guardrail warning; where I can only think of a justification like "This requestor type supports multiple Job Schedules and is indeed required by multiple apps".
Remember: Make sure you have all the appropriate classes and privileges set for the Role within the Access Group you wish to use for job execution(!)
I also face similar issue in my project. We have one PEGA installation which supports 7 different applications. Moreover, these applications are built on different PEGA strategic applications as well.
Reading into your remark, "As it turns out it suffices to just append all your applications App:AsyncProcessor references in the Requestor Type rule and somehow needs to be marked as default at some point in time for Admin Studio to notice the new configuration", does this work for you? Did you manage to dynamically set one requestor type as default at "some point of time"? If yes, please provide some details.