Hi,
My customer develops multiple applications in a single platform for each region, and had minor confusion as Job Scheduler did not run as expected when they imported an application to the target environment. System Runtime Context is not something that developer should always care as it is auto-managed, but in such case you may have to manually maintain it. In this post, I will explain what System Runtime Context is, and how it works.
1. What is System Runtime Context
When we log in to Pega thru browser, application context is established using the access group of the operator and respective UI and logic are executed. However, for background process (Job Scheduler and Queue Processor) there is no specific user associated and System Runtime Context is used to help these to define which rules to run, in what priority, namely rule resolution. Actually, Pegasystems had introduced a new Requestor Type called “ASYNCPROCESSOR” in Pega 8.1 to take care of this but since Requestor Type rule can reference only a single access group, there was a limitation in multiple applications environments and hence deprecated. In 8.3, System Runtime Context was newly added to replace ASYNCPROCESSOR Requestor Type. In Dev Studio, you can go to the configuration gadget from System > General > System Runtime Context.
2. When System Runtime Context is updated
System Runtime Context adds application at the top line when application rule is saved. It is also removed when application rule is deleted. There are two conditions for this automatic addition or removal to work. One is you must turn on “Include in background processing” checkbox in application rule. This checkbox is checked by default if you use New Application wizard, but if you manually create an application rule from Records explorer, this is not checked. Also, once updated, system restart is not required. It takes effect immediately, and Job Scheduler will be executed based on the updated new context from the next run in real time.
Another condition is to turn off “Disable automatic updates” checkbox. This is off by default, and I recommend the default settings, so system can automatically manage it for you.
3. Where the settings are stored
Information configured in System Runtime Context gadget is stored in a physical table. It is an instance of System-Runtime-Context class, and it is mapped to PR_SYS_RUNTIME_CONTEXT table in a RULES schema. The stack of application is stored as a Page List in Blob and the name of this instance is “Default”. You may wonder, if this is a database record of a concrete class, shouldn’t we include this instance in the R-A-P? No, it is not required because System Runtime Context update is triggered not only when you hit the “Save” button on application rule form, but also when you import the Jar/Zip file to the target environment. You would only need to check if it is updated as you expect after import.
4. How System Runtime Context resolves rules (how rule resolution works)
The order of the applications listed in System Runtime Context is important. Just like application rule refers the order of the ruleset in the ruleset list, System Runtime Context also refers to the order of the application in the list. Applications at the top of the list take higher precedence. This is the straightforward, general rule.
However, it is not always the case - what you see in System Runtime Context gadget may behave differently depending on your application design. In a nutshell, the hierarchy of application (built on other application) is tied together, and trusted more than the gadget. For example, if you have two applications, MyApp and Myco, and MyApp is built on MyCo, then MyApp always takes higher precedence despite the order in the gadget (see 4-1. Example 1 below). On the other hand, if you have applications that have no hierarchy (no built on relations) then order is applied. For example, assuming you create a standalone application Sandbox. If Sandbox is listed at the top above MyApp / MyCo, then Sandbox takes higher precedence over MyApp / MyCo (see 4-2. Example 2 below). Conversely, if Sandbox is listed below MyApp / MyCo, then MyApp / MyCo takes higher precedence over Sandbox. Please see below for the details.
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
You create MyApp application first and then create MyCo application later. MyApp application is built on top of 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, system correctly detects MyApp should take precedence over MyCo and it rearranges it as such, internally.
| No | Ruleset |
|---|---|
| 1 | MyApp:01-01-01 |
| 2 | MyAppInt:01-01-01 |
| 3 | MyCo:01-01-01 |
| 4 | MyCoInt:01-01-01 |
| 5 | Pega-ProcessCommander:08-06 |
| 6 | … |
4-2. Example 2: In your system, you have two sets of individual applications.
- Application rules in a system
You create Sandbox application first. Then you create MyApp / MyCo application later. MyApp application is built on top of MyCo application.
- System Runtime Context gadget (auto-managed)
Since Sandbox was created first, it is added to the top initially. Then MyApp was created and it comes on top. Finally, MyCo is created and it gets added to the top of the list.
- Actual rule resolution process (precedence)
| No | Ruleset |
|---|---|
| 1 | MyApp:01-01-01 |
| 2 | MyAppInt:01-01-01 |
| 3 | MyCo:01-01-01 |
| 4 | MyCoInt:01-01-01 |
| 5 | Sandbox:01-01-01 |
| 6 | SandboxInt:01-01-01 |
| 7 | Pega-ProcessCommander:08-06 |
| 8 | … |
Note: If you create Sandbox at last (or manually drag and drop to place Sandbox on top of the list), system will realize Sandbox is the highest priority. In this case, the rule resolution precedence changes in the order of Sandbox, SandboxInt, MyApp, MyAppInt, MyCo, MyCoInt, Pega-ProcessCommender, and so on.
5. Limitations
Just like other rule type, Job Scheduler is also overridable. If you have a Job Scheduler in two layers with the same name, the only one in a higher precedence is executed, and the one in a lower precedence is not executed. Now, let’s think of application structures as below. You have two “sibling” applications, MyApp1 and MyApp2. Both applications are on top of MyCo. Also, let’s assume System Runtime Context gadget lists applications in the order of MyApp2, MyApp1, MyCo, and PegaRULES. In this case, if you create a JobScheduler “MyJobScheduler” as well as an activity “MyActivity” within all three of applications, which one(s) are executed? Can we run ones in both siblings?
The answer is system runs only the one in MyApp2. This is because MyApp2 and MyApp1 have no built on relations, so whichever comes first takes precedence - in this case, MyApp2. MyCo is overridden and hence ignored. It is not possible to run two Job Schedulers in MyApp1 and MyApp2 in a single system at the same time. This is a limitation of the current System Runtime. Even if you specify Access Group for context (in Job Scheduler rule you can choose either fixed Access Group or System Runtime Context), the result is the same - you can change the activity to run in a specific ruleset that Access Group references but the Job Scheduler that gets picked up is still one. So I would say this is a limitation of Job Scheduler in a sibling application environment.
6. Suggestions
If your application is simple and configured as a single linear stack, you do not have to worry about System Runtime Context as system automatically maintains it. If you have multiple applications that are unrelated to each other including sibling applications, you need to pay careful attention. Personally, I would manually update it regardless of the application designs because auto-managed list is sometimes confusing for other developers even though internal rule resolution is correct. Updating manually does not conflict with automatic updates (automatic updates simply allow addition or removal by the system from next time). Also, if you are exporting some portion of applications to other environment, you should always check if System Runtime Context is okay after import.
7. Bugs
You may not be able to find delete icon in 8.4.x, 8.5.x, and 8.6.x.
This is a bug and already fixed in the patch release (8.4.6, 8.5.4, and 8.6.1). Please apply patch release accordingly. Or if you need an immediate solution, here is a workaround - add pzCanEditSRC privilege for Embed-AppInfo class to your access role (ex. MyApp:SysAdm4).
Hope this helps.
Thanks,
