System category — Settings page
|
Category |
Page |
System | Settings |
The Settings page has six tabs used to administer a system:
Complete these three URLs as follows. Do not use "localhost" as the node name; use the server name or an IP address.
Click Submit to save these changes into the corresponding Dynamic Systems Settings data instances. Log out and log in again, or wait up to 10 minutes, for the new values to be available in this server. See Atlas — Standard Dynamic System Settings.
Optionally, complete two fields to make information available to the Java compiler on your system:
Search tab — Index Administration
The Search tab has three sections: Index Administration, Agent Administration, Index Host Node Settings.
Use the Index Administration settings to enable or disable indexing for classes under Rules-, Data-, and/or Work-.
Through a checkbox labeled Exclude this class from search? on the Advanced tab of the Class form, you can cause full text searching to skip over instances of a specific class. Search results then exclude any instances of that class.
Field |
Description |
All Rule-, Data- and Work- Classes | Turn on/off all search indexing. |
Rules | Turn on/off search indexing for all Rule- classes. |
Click Re-Index to build or rebuild indexes for rules.
|
|
Data | Turn on/off search indexing for all Data- classes. |
Click Re-Index to build or rebuild indexes on Data- class instances.
|
|
Work |
Turn on/off the Re-Index button to build or rebuild indexes on Work- class instances. Enable this capability only if your applications provide full-text searching of work objects. In a production system, building and maintaining search indexes for work objects is typically more costly in performance impact than building and maintaining search indexes for rules or data instances. Work object search is not available in the Designer Studio portal.
|
Index Attachments |
Click this checkbox to index work item attachments. PDF, Microsoft Office, and text attachments are indexed and will be full-text searchable. However, if your application saves work item file attachments in an external enterprise content management system accessed through Connect CMS rules, such file attachments are not included in PRPC search results. |
Click one of the three Re-Index buttons to rebuild the complete index file for the selected type. You normally only need to perform these actions following initial installation, or if the search index files are accidentally deleted or corrupted.
Perform these one at a time; each starts processing that may require several minutes to complete. Progress messages appear at the bottom of the page during the rebuild. Each responds with a success message when processing is complete. Additional details and progress messages appear in the system console log. Building or re-building indexes naturally requires reading every rule, data instance, or work item.
You can check or clear any of the boxes above while a PRPC server node is operating, but such index processing can affect system performance if the indexes are large. As a best practice, choose a time when the server is less busy to perform these one-time processor-intensive operations.
The Designer Studio search facility also allows search of Application Developer help topics. The Help search capability depends on a static index and is unaffected by the settings you record in this tab. During installation or upgrades, the help index file is automatically extracted from a binary file rule named HelpIndex.pxHelpIndexBinary.zip.
Search tab — Agent Administration
Displays the status of the Pega-RULES agents that incrementally update the search index files as changes are made to Rules-, Data-, and/or Work- instances. Also provides Start and/or Stop buttons to manually enable or disable these agents.
Field |
Description |
Enabled? |
If enabled, and the agent is running, a check mark () will be displayed. If disabled, and the agent is not running, an X () will be displayed. |
Agent |
The SystemIndexer agent is responsible for updating Rules- and Data-indices, and the SystemWorkIndexer agent is responsible for updating Work- indices. See Understanding the Pega-RULES agents. |
Scheduling |
The scheduled frequency, in seconds, with which the agents run and update the indices. |
Last Run Start |
Date and time of last run start. |
Last Run Finish |
Date and time of last run finish. |
Next Run Time |
Date and time of next scheduled run. |
Exception Info |
Exception information field. |
Search tab — Index Host Node Settings
In a multinode cluster system, the indexes that support search may be maintained only on one node. When a user connected with another node performs a full text search, an HTTP service request is sent from that node to the node with indexes. The search results are returned to the requesting node and displayed to the user.
Messages pertaining to search indexing appear in this area.
The Security Policies tab is visible to operators who have the pzViewAuthPoliciesLP privilege in their Access Roles. This privilege is part of the role PegaRULES:SysAdm4.
The tab controls the appearance and functions of a CAPTCHA, a test that verifies that a human, not a computer process, is attempting to log in or change an operator password. The user must enter the characters that appear above an image that makes it difficult for a machine to read the characters. If you cannot read the characters, click the Refresh button to get a different image and character set.
A CAPTCHA may appear on the login screen when the user first attempts to log into the system from a given computer or after an authentication failure, and on the password-change screen. The goal is to counter "brute-force" automated attacks on system security.
The tab offers a checkbox, a button, and a series of settings that allow the operator to fine-tune CAPTCHA behavior. Each setting has default, minimum, and maximum values.
Check the Enable Security Policies checkbox to enable the settings the tab displays. Uncheck the checkbox to prevent the CAPTCHA functions from operating.
Click Display Audit Log to display the log that can record login attempts. Audit log behavior is governed by The Audit log level policy setting, described below.
A Report Definition report displays the "Security Audit Log" report, with a default filter to display all audit events (the filter is set to ".pxCreateDateTime is Less or Equal to Current Month"). Click the link to the right of "Filters in the report header to adjust the date range.
For each logged event, the log captures:
Click View History to see a report of changes to security settings, including the date, the operator who made the change, and what change was made.
You can set the following policies:
Policy | Notes | Default value | Min value | Max value |
---|---|---|---|---|
Minimum operator identifier (ID) length | 8 | 3 | 64 | |
Minimum operator password length | 8 | 3 | 64 | |
Minimum numeric [0-9] characters required in operator password | 1 | 0 | 64 | |
Minimum alphabetic [a-zA-Z] characters required in operator password | 1 | 0 | 64 | |
Minimum special characters required in operator password | The available special characters are: ` ~ ! @ # $ % ^ & * ( ) _ + - = { } [ ] | \ : " ; ' < >? , . / | 1 | 0 | 64 |
Minimum unique historical operator passwords | If the value is 5, you cannot change your password to match any of the most recent five passwords you used. | 5 | 0 | 128 |
Maximum operator password age | The maximum number of days before the operator must change the password. | 5 | 0 | 128 |
CAPTCHA implementation |
If Default, the system presents the CAPTCHA implementation shipped with PRPC. If Custom, the system presents the custom CAPTCHA implementation enabled for this system. An application can make use of third-party CAPTCHA solutions on the application login screen; however, a certain amount of developer work is required to prepare the custom RuleSet to deliver the third-party resource. |
Default | ||
Enable CAPTCHA Reverse Turing Test Module | If enabled, the system presents the CAPTCHA upon authentication failure, with a probability set by the following field. If disabled, no CAPTCHA is presented even on login failure. |
Enabled | ||
Probability that CAPTCHA will be presented upon authentication failure | If the CAPTCHA Revers Turing Test is enabled in the field above, the percentage set here is the likelihood CAPTCHA appears. | 5 | 0 | 100 |
Enable presentation of CAPTCHA upon initial login | If enabled, CAPTCHA displays the first time the user tries to log on a new system or from a new compute. | Enabled | ||
Enable authentication lockout penalty mechanism | If enabled, after n failed login attempts, the system imposes a delay of mm seconds after every unsuccessful login attempt. The values are set in the fields below. | Enabled | ||
Failed login attempts before employing authentication lockout penalty | After the number of failed attempts set here, the user will experience a delay after each further attempt. The delay will get longer with each attempt. | 5 | 0 | 128 |
Initial authentication lockout penalty | Set the initial delay, in seconds | 8 | 0 | 128 |
Audit log level | Set the Audit log level: the options are
|
For an example, see PDN article 26428 How to configure login security and password policies.
More advanced customizations are possible. See PDN article 26451 Customizing CAPTCH presentation and function.
Use this page to change the System Name of your PRPC system. A PRPC 'system' in this context is all PRPC instances (nodes) that share a single database and the same system name. When you use this page to change the system name, PRPC clones the current system name record, the node name of the other nodes in the system that use the current name, and all associated Data instances that reference this name and applies the new system name.
If your organization has multiple PRPC systems, it is a best practice to set a distinct system name for each of the systems. For example, you may want to distinguish between development, test, UAT and production systems. When you create, or update a rule or a data instance, the current system name is added to the History tab. When you import a ZIP archive containing a rule or data instance, the system name is on the History tab (which may be the source system on which the ZIP archive was created). Using distinct system Names can help identify the source systems when rules or data objects are moved from one system to another.
To change the system name,
By default the system name is pega.
The system names prpc and iwm are reserved; do not use except as advised by Global Customer support.
PRPC makes an exact copy of the current system name record, the node name of the other nodes in the system that use the current system name and all associated data instances, including requestor type data instances (Data-Admin-Requestor class), the Dynamic System Settings indexing/hostid, and applies the new system name. PRPC also updates any listeners with the new Node IDs.
The table All Affected Nodes on the System Name page lists the nodes whose name will be changed by this action.
If the Required Action column for a node is Update prconfig.xml and Restart you must update the prconfig.xml
file entry Identification/SystemName
for that node to reference the new name before restarting the node. For example:
<env name="Identification/SystemName" value="mycoProd" />
Complete this step for each node.
When the system starts with the new name, it creates new Agent Schedule instances for each node. Review these new instances and update, if necessary, the access group (on the Security tab) to match the value in the older Agent Schedule instance.
See also:
Use this tab when you have an instance of the Project Management Framework to set up the URL connections between applications and the framework, test that connectivity, and enable project tracking for operators who perform development work in the applications they can access.
landing page | |
Definitions — Lucene, CAPTCHA Designer Studio — Using the Search tab Understanding the full-text search facility |
|
Atlas — Initial Dynamic System Settings |