AsyncProcessor requestor type and System Runtime Context

In this blog article, we will see the introduction and deprecation of the AsyncProcessor requestor type followed by the usage of System Runtime Context.

Let’s start with a brief introduction about requestor types.

We know that all the application logic or coding resides in the rule base. To resolve and execute the applicable code, we need the application context.

When I login into the Pega application, the application context is evaluated based on my operator record access group and the code/rules can be resolved and executed under the application context.

Operator record -> Access group -> Application -> Rulesets -> Rules.

It is not always an operator request to execute the application functions, the background processing/jobs, and the service requests (REST, SOAP, File etc) also need to execute the pega rules. In Pega terms, we call them requestors 🙂

Till Pega 7, requestors were classified under 4 requestor types – Browser, Batch, Application and portal.

For a detailed explanation of each requestor type, Please visit another blog article on requestor types.

With Pega 8, a new requestor type was introduced – AsyncProcessor requestor type.

Using Pega 8.2 personal edition to show the AsyncProcessor requestor type.

What is AsyncProcessor requestor type?

– It is used to resolve the job scheduler and queue processor rules.

Little confusing?!! 😁

Let’s talk about the OLD agent rules and how it is rule resolved.

We know that agent activities are grouped under an agent rule and are tied to a ruleset. I mean the agent rule name will be of the ruleset name.

Below you can see the snapshot of Agent rule Pega-Procom with more than one agent activities.

The ruleset name helps in rule resolving the agent rule.

Please do not confuse with rule execution context of agent activity rules. It is a different concept where the standard agent activities execute under the context of operator who queues, whereas for advanced agents, we can specify the access group in agent rule security tab or by batch requestor type, but I am not talking about that. Just one level up, I am talking about the Agent rule and not about the agent activity.

The agent rule helps in grouping similar background jobs. For example – Pega-IntSvcs ruleset groups the agent activities/background jobs that is specific to integration services

How Pega resolve all the agent rules??

On system startup, Pega resolves all the available agent rules in the rulebase and based on the enable/disable configuration, the agent starts running.

I would like to mention one drawback with tieing the agent to ruleset name is when we save as the agent into branch ruleset. It will be treated as a different agent rule and hence, the agent activities can run twice!

With Pega 8, agents are to be replaced with job schedulers and queue processors.

Here there is no grouping concept, instead, each agent activity/background job will be replaced with either job scheduler or queue processor. So their ID will not be on the ruleset name instead just the job name.

Now How Pega resolve the job scheduler and queue processor rules?

Again I am making a strong remark that I am talking only about the rule name and not talking about the execution context of the processing activities 🙂

Pega product team came up with a new requestor type to resolve the job scheduler and queue processor rules – AsyncProcessor requestor type.

We know that requestor types are created per system and so you can see 3 AsyncRequestor types already exist in my personal edition.

Records -> System -> Requestor types

I am opening the requestor type created for my system – Facebook.

You see the requestor type is defined using application based access group and points to the OOTB access group – PRPC:AsyncProcessor access group that in turn points to PegaRULES application.

It means when the system starts up, based on the application access PegaRULES, all the OOTB job schedulers and queue processors should be rule resolved and be up and running if it is enabled.

We can verify it from the admin studio.

Admin studio -> Resources -> Jobs

All the OOTB jobs resolved under PegaRULES application context are listed below.

You see there are 16 jobs.

Now let’s add a new Job scheduler and see how the rule is resolved!

for now I will just create a dummy job scheduler using any existing activity.

Records -> SysAdmin -> Job Scheduler -> Create new

I named it as SimpleJobScheduler.

Tip: Context field in the job scheduler is used to resolve the processing activity. There also you can use the async processor requestor type instead of specifying access group. I will save it for my next post

Save the rule.

Switch to admin studio and refresh the jobs.

You still see 16!!! You know the reason now.

Your AsyncProcessor requestor type doesn’t help in resolving the newly created job scheduler, because it is still pointing to OOTB PRPC:AsyncProcessor

Change the requestor type access group to the right application access group.

Save the requestor type.

Now switch back to admin studio and refresh the job schedulers.

There you see the new job scheduler is rule resolved and in the list.

Okay now let’s talk about some pros and cons of using asyncprocessor requestor type.

First pros

We have a single place to rule resolve the job schedulers and queue processors.

On application basis, you can resolve the rules.

Now cons

With the evolution of component applications, there is always the possibility of having more than one application stack in a system and so different access groups. If 2 different job schedulers are part of 2 different application stacks, then how to specify it in AsyncProcessor requestor type with a single default access group???

You have an option to specify the ruleset and roles as well.

So, you can actually use this option to add the rulesets that hold the job schedulers and queue processor rules.

Still I feel this is one of the big drawbacks that we don’t have the entire system context to resolve the rules.

The new requestor type adds little maintenance overhead, so you need to manually maintain the configuration.

With Pega 8.3, AsyncProcessor requestor type is rightly deprecated and comes the system run time context!

We will use Pega 8.5 Pega Personal edition to show you the System Runtime Context.

What is System Runtime Context?

– Again, it is also used to rule resolve the job schedulers and queue processor rules.

– It was introduced in Pega 8.3 to replace the AsyncProcessor requestor type way of resolving the job scheduler and queue processor rules.

How to access and configure the System Runtime Context?

Designer studio -> Configure -> System -> General -> System Runtime Context

There you will see the configuration for system run time context.

The main difference that you see here is, no access group definition. You can add as many applications as you want.

As we saw in AsyncProcessor example, if the application access is not specified here, then the job scheduler or queue processor will not be resolved and hence will not be listed in the admin studio. I am not going to show the same again 🙂

Remember we discussed two cons about using AsyncProcessor requestor type.

1. Single access group based rule resolution.
2. Manual maintenance.

Single access group based rule resolution –

This can be overcome easily by using an application list instead of access group based application access.

Manual maintenance –

Still we need to manually update the application and version everytime??? 😐

No no! We have a configuration to automatically update the application and its versions.

How to automatically manage the System Runtime Context?

Step 1: Do not disable the auto updates in System Runtime Context.

Step 2: Open the application rule and switch to the definition tab.

Step 3: Expand the advanced configuration, there you will find an option to include in background processing.

Check the box.

Step 4: Save the application rule. As soon as you save, Pega updates the System Runtime context automatically to include the application and version.

Cool right.

Now if you save any Job scheduler or queue processor under the application MyKnowPega, it will be automatically rule resolved and you can find it in admin studio.

Now next question, what if I increment the application version to 01.01.02??

Let’s test it.

Step 5: Save as the application to the next patch version.

Note: Save as, copies the Include in background processing configuration in application rule.

Now if you switch back to System Runtime Context, you will see pega takes care of automatically updating the patch version and hence no human errors 🙂 I am impressed!!

As you see at the top, a toggle button to disable automatic updates. It is always good to leave it as such so that automatic updates can be done. Also even when automatic updates is enabled, you can always update the System Runtime Context if needed.

Note: For every new application creation using application wizard, Pega by defaults checks the Include in background processing checkbox. So it is going to be automatically added. Just keep an eye when you newly create an application using wizard.

Enable the option in the application rule only when necessary.

How the rule will be resolved if more than one custom application is added?

The answer is on the ordering of application.

Higher the application, higher the ruleset stack resolution.

You can click the resolved rulesets button.

It will list you the ruleset ordering – to resolve the rules.

You can also update the System Runtime Context from admin studio.

One final question

how do we deploy the System Runtime Context to higher environments?

When you import any application (technically that will save the application instance), system runtime context should be automatically updated if your auto updates is enabled.

There can be a small debate that it can be risky to auto-update the System Runtime Context in production, if any application is wrongly enabled!

I would recommend enabling the auto-update in productions because

– This saves the human error of manual updates. In case of frequently incrementing the application version.

– We know what applications we are packaging and it goes through testing environments so if some culprit application gets in, that should be identified.

You can try creating job scheduler and queue processors and see how it is rule resolved using System Runtime Context using admin studio.

As a small recap,

– Pega introduced AsyncProcessor requestor type to resolve the job scheduler and queue processor rules in Pega 8.1.

– AsyncProcessor requestor type can be defined on application based access group or by ruleset list.

– AsyncProcessor requestor type should be manually maintained.

– AsyncProcessor requestor type is deprecated in 8.3.

– Pega introduced System Runtime Conext to replace AsyncProcessor requestor type to rule resolve the job scheduler and queue processor rules.

– Application rules can be configured to get automatically added to the System runtime context configurations.

Hope you all understood the concept behind the AsyncProcessor and System Runtime Context. This makes a bridge for my next article on Job scheduler.