Understanding System Runtime Context

Imagine an individual is creating numerous applications within a unified platform, each tailored for a specific region. They encountered a slight confusion when the Job Scheduler failed to execute as anticipated upon importing an application into the target environment. While System Runtime Context is typically auto-managed and doesn't require constant developer attention, in such instances, manual maintenance may be necessary. This article aims to elucidate the concept of System Runtime Context, providing insights into its nature and functionality.

1.What is System Runtime Context

When accessing Pega through a web browser, the application context is established based on the operator's access group, guiding the execution of the corresponding UI and logic. However, when it comes to background processes such as Job Scheduler and Queue Processor, there isn't a specific user associated. Instead, the System Runtime Context is utilized to determine which rules to execute and in what priority, essentially handling rule resolution. Pegasystems initially introduced a new Requestor Type called "ASYNCPROCESSOR" in Pega 8.1 to address this issue. However, due to limitations in multiple application environments, where a Requestor Type rule could reference only a single access group, it was deprecated. In version 8.3, System Runtime Context was introduced as a replacement for the ASYNCPROCESSOR Requestor Type. To configure it in Dev Studio, navigate to System > General > System Runtime Context.

2.When the System Runtime Context undergoes modifications?

System Runtime Context automatically includes an application at the top line upon saving the application rule, and it is likewise removed when the application rule is deleted. Two conditions govern this automatic addition or removal process. Firstly, the "Include in background processing" checkbox in the application rule must be activated. This checkbox is selected by default when utilizing the New Application wizard. However, if you manually create an application rule from the Records explorer, this checkbox remains unchecked. Additionally, there is no need for a system restart once the update is made. The changes take effect immediately, influencing the real-time execution of Job Scheduler based on the updated context from the next run.

Another condition is to deactivate the "Disable automatic updates" checkbox. This option is disabled by default, and I suggest sticking to the default settings to allow the system to automatically manage it for you.

3.Where the settings are stored?

The information configured in the System Runtime Context gadget is stored in a physical table, specifically an instance of the System-Runtime-Context class. This instance is mapped to the PR_SYS_RUNTIME_CONTEXT table within a RULES schema. The application stack is stored as a Page List in Blob, and the instance is named "Default." One might question whether this database record of a concrete class should be included in the R-A-P. However, it is unnecessary because System Runtime Context updates are triggered not only when saving the application rule form but also when importing the Jar/Zip file into the target environment. Verification of the expected updates is only required after the import process.

4.How System Runtime Context resolves rules (how rule resolution works)?

The sequence of applications in the System Runtime Context holds significance, akin(similar) to how the application rule considers the order of rulesets in the ruleset list. In System Runtime Context, the arrangement of applications in the list matters, with those positioned at the top gaining higher precedence. This follows a simple and general rule.

Nevertheless, the behavior of what is displayed in the System Runtime Context gadget may vary depending on your application design. In essence, the hierarchy of applications, particularly those built on others, takes precedence and is more reliable than the gadget's order. For instance, consider two applications, MyApp and MyCo, where MyApp is built on MyCo; in this scenario, MyApp consistently holds higher precedence regardless of the gadget's order (refer to 4-1. Example 1 below). Conversely, when dealing with applications lacking a hierarchy (no built-on relations), the order becomes influential. For instance, consider a standalone application named Sandbox. If Sandbox is positioned at the top above MyApp/MyCo, it gains higher precedence over them (refer to 4-2. Example 2 below). Conversely, if Sandbox is listed below MyApp/MyCo, then MyApp/MyCo takes precedence over Sandbox. Further details are provided below.

4-1. Example 1: In your system, you have two applications, and one is built on top of the other

• Application rules in a system

Initially, you create the MyApp application, followed by the later creation of the MyCo application. The MyApp application is constructed on top of the MyCo application.

• System Runtime Context gadget (auto-managed)

Since MyCo was created after MyApp, MyCo is added to the top of the list.

• Actual rule resolution process (precedence)

However, the system correctly detects that MyApp should take precedence over MyCo and rearranges it accordingly, internally.

4-2. Example 2: In your system, you have two sets of individual applications.

• Application rules in a system

Initially, you create the Sandbox application. Subsequently, you create the MyApp/MyCo application, with the MyApp application being constructed on top of the MyCo application.

• System Runtime Context gadget (auto-managed)

As Sandbox was the first to be created, it is initially added to the top. Subsequently, MyApp is created and takes the top position. Lastly, with the creation of MyCo, it is added to the top of the list.

• Actual rule resolution process (precedence)

Note: If you create Sandbox last (or manually arrange Sandbox at the top of the list), the system recognizes Sandbox as the highest priority. In such a scenario, the order of rule resolution precedence changes to Sandbox, SandboxInt, MyApp, MyAppInt, MyCo, MyCoInt, Pega-ProcessCommander, and so forth.

5. Constraints

Similar to other rule types, Job Scheduler is also subject to override. If a Job Scheduler with the same name exists in two layers, only the one with higher precedence will be executed, while the one in the lower precedence remains inactive. Now, consider the following application structures: two "sibling" applications, MyApp1 and MyApp2, both positioned on top of MyCo. Let's assume that the System Runtime Context gadget lists applications in the order of MyApp2, MyApp1, MyCo, and PegaRULES. In this scenario, if you create a JobScheduler named "MyJobScheduler" and an activity named "MyActivity" within all three applications, which one(s) will be executed? Is it possible to run those in both siblings?

The system executes only the JobScheduler in MyApp2. This is because MyApp2 and MyApp1 lack built-on relations, and the one that comes first takes precedence—in this case, MyApp2. MyCo is overridden and consequently ignored. Running two Job Schedulers concurrently in MyApp1 and MyApp2 within a single system is not possible. This limitation is inherent in the current System Runtime. Even if you specify an Access Group for context (in the Job Scheduler rule, you can choose either a fixed Access Group or System Runtime Context), the outcome remains the same—you can alter the activity to run in a specific ruleset referenced by the Access Group, but the Job Scheduler that gets triggered remains singular. Therefore, this can be considered a limitation of the Job Scheduler in a sibling application environment.

6. Recommendations

If your application is straightforward and configured as a single linear stack, there's no need to concern yourself with the System Runtime Context, as the system automatically handles it. However, if you have multiple, unrelated applications, including sibling applications, it requires careful attention. Personally, I recommend manual updates regardless of the application designs because the auto-managed list can be confusing for other developers, even though the internal rule resolution is correct. Manual updates do not conflict with automatic updates; the latter simply allows the system to add or remove entries from the next update onwards. Additionally, when exporting portions of applications to another environment, always verify the integrity of the System Runtime Context after the import process.

7.Solution for existing Issues

The delete icon may not be locatable in versions 8.4.x, 8.5.x, and 8.6.x.

This issue has been identified as a bug and has already been rectified in the patch releases (8.4.6, 8.5.4, and 8.6.1). It is advisable to apply the relevant patch release accordingly. Alternatively, if an immediate solution is needed, here is a workaround: add the "pzCanEditSRC" privilege for the "Embed-AppInfo" class to your access role (e.g., MyApp:SysAdm4).

Happy Learning :) :) and Happy New Year Folks :)