Question

Enabling Job Scheduler

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!

Correct Answer
March 11, 2019 - 1:19pm

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

Comments

Keep up to date on this post and subscribe to comments

Pega
March 11, 2019 - 1:19pm

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

March 14, 2019 - 3:59pm
Response to smitdi

thank you this solved my issue

July 18, 2019 - 1:48am
Response to smitdi

But that not the way it should work right!

First of all there shouldn't be any restriction as per listing in the Admin portal is concerned.

During execution if explicit access group is mentioned then requestor should switch to that access group else use the access group which is in AsyncProcessor requestor type's access group.

August 13, 2019 - 3:00am
Response to smitdi

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.

August 13, 2019 - 11:16am

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(!)

August 15, 2019 - 4:16am
Response to EdgarPDN

Hi Edgar,

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.