About the form header
All records display a header at the top of the form: Actions, Details, Warnings, and Errors.

Understanding form details
The left side of the form header conveys record information using a standardized design. When an item is not applicable to a specific record type, it is omitted.

Using form actions
The right side of the form header displays actions to help you manage and update your records. Lock status, operator privilege(s), and application configuration determine the presence, position, and available menu options for each action.

Reviewing Warnings
Warnings display in the form header with a condensed format.
​
Resolving errors
Errors represent issues with validation, incomplete fields, or unsupported configurations. You must resolve all errors before a rule or data instance can save successfully. Use the information displayed in the error section of the header to understand what the issue is and how to resolve it. Use the indicator icons to quickly see which tab has an issue and what field(s) on that tab are involved in the error condition.

Form conversionStarting with Pega 7, all rule forms are converted from Form to Harness. This product-wide initiative brings the following benefits:

• Functionality that builds on standards compliant, auto-generated features
• Accessibility from a variety of supported browsers
• Consistent styling and appearance

The Pega 7 Designer Studio clearly presents the required information and tools to perform work in any context. Primary user actions have been promoted to the top level menus for greater visibility.  Explorer navigation is streamlined with greater control over configuration and display of data.  Developer tools are centrally located and display based on role.  Complexity and visual distractions have been eliminated to provide a modernized yet cohesive experience.
There are four main components of the Designer Studio as illustrated below

​The Designer Studio Header is organized to make frequently used items accessible and keep navigation simple.  Each component is detailed below:

​Pega 7 icon
Click the Pega 7 icon to load the Home Page in your Work Area. The Home Page displays guardrail warnings for your application and facilitates task assignments between you and operators in your associated access groups.

Landing Page menu
Click the Designer Studio logo to access landing pages, wizards and tools to build your application.  Although not an entirely new feature in Pega 7, the landing page structure has been reorganized and enhanced to better align with application development needs.  The Landing Page menu is grouped by functionality and presented in tiers.  Navigation is from left to right as illustrated below.

Decision Management capabilities help businesses optimize every customer relationship and interaction to satisfy both customer needs and business objectives at the same time. With Decision Management, business users can implement a management strategy that is personalized for each customer, and that guides every customer interaction and decision.

Case management
​Case Management is a process capability in the Designer Studio that supports the definition of a case and case type with all its associated information and content. Cases can then be created and thus follow the defined application process flows.  

Designer Studio
Using Designer Studio to build and iterate on multiple applications is not restricted to any particular team member's role. It is the application team's work space. Designer Studio provides user management with an access control system so that restricted access to certain areas and application environments can be managed and controlled.
​
Java and activities
To apply programming logic to an application, use features that are built-in to Designer Studio providing for coded procedural processing. This approach removes unnecessary custom code, supporting greater reuse of application rulesets and easier upgrades. Using the Data Transform rule or the Activity form, define step-through logic to call several built-in methods.

Reuse and version management
The Pega 7 Platform supports reuse and sharing of rules through a range of features that affect rule resolution. Rule resolution chooses what version of a rule to use in a given circumstance. Rule reuse helps to reduce the number of rules you must build, test, and maintain

Testing applications
Testing applications is part of an iterative application development approach and release management. Testing features are built-in to the Designer Studio and are used to develop, iterate and release continuous application improvements.

Pegasystems proposes two methodologies – – 1) SmartBPM and 2)PegaScrum

In this post, we will look into the SmartBPM methodology and understand the various phases involved, the kind of activities and deliverables in each phase.
​SmartBPM resembles the agile methodology where we break the requirements into smaller independent deployable modules (which are called as ‘Slivers’ by Pega) and iterate the elaboration and construction cycle.

​Inception Phase Activities:

• Kick off discussion with key stakeholders and define the scope of work.
• Understand and Capture the Business Objectives & High level requirements in the Application Profile.
• Prioritize the requirements based on the business needs and break them into slivers (small functional modules to be delivered in 4-6 weeks of time)
• High Level requirements would include high level use cases, reporting requirements and upstream/downstream applications that need to be integrated with.
• Do the project effort sizing using the DCO estimation template that comes within the Application Profile
• Do the flow and UI drafting within PRPC environment and gain acceptance
• Align the design and coding standards with the client’s corporate standards (if any)

Elaboration Phase Activities

• Accelerate the application profile with the Application Accelerator
• Elaborate the high level use cases into atomic level use cases
• Define class structure, rule hierarchy; design DB schema
• Setup the environment
• Create test plan and deployment strategy

Construction Phase Activities

• Design process flows, User interface; implement business rules (decision logic), routing logic, SLAs
• Build reports (Report definition wizard)
• Use connectors/services to connect with external systems
• Unit Testing

Transition Phase Activities

• System Integration Testing (SIT)
• User Acceptance Test (UAT)
• Deployment and Release Notes documentation

Summary
Prerequisites and profile RuleSet lists are both lists of RuleSets and versions, but they have greatly different uses.
Both create a list of RuleSet versions, but

• Prerequisites are used in validating newly-created rules at save time (to be sure all the rules referenced by the new rule are valid for the RuleSet of the new rule), whereas
• Profile RuleSet lists are used during the actual execution of the rules (at run-time).

Suggested Approach
​Overview
Two kinds of RuleSet lists are defined in different places for different purposes, and there is no relationship between the two.

• When creating rules, prerequisites are used.Rule validation (when saving a rule form) is always performed against the prerequisite RuleSet list, not the profile RuleSet list.  Therefore, it is possible at rule creation time to validate against RuleSet lists that are not in the user's profile.

• When running rules, profiles are used.Therefore, it is possible at run-time to execute rules from a RuleSet version that is not in that RuleSet's prerequisites, if that RuleSet is present in the user's profile.

If the user needs to create or change rules and then test them by executing, the RuleSet of the new rule must be present in both the Prerequisite and Profile RuleSet lists for that user (though the order of the RuleSets and their versions can be different).  See Example #2 for details.

NOTE: The Rule Resolution process does not cross major versions for rule searches.   Thus, for Profile RuleSets, if the RuleSet isPega-RULES:03-02, then the user will not be able to see or use any rules from the RuleSet Pega-RULES:02-02, even though this version is less than the version 03-02. For the prerequisite RuleSet, a Prerequisite of major version 02 (RuleSet 02-02-01) would not be found if the major version 03 (03-01-01) is on the system.

Prerequisites

Prerequisites are the list of RuleSets and their versions which must be present for a new rule created in an existing RuleSet to be validated upon creation, or for the rules in a new RuleSet to be validated properly (see Example #1).

The RuleSet and Version that is entered into the Prerequisite field of a RuleSet Version definition is an upper limit. If the Prerequisite for a particular RuleSet is Pega-ProCom:04-02-01, then any RuleSets in that major version (04) but below the specified version will be used: 04-01-24, 04-01-50, etc.

The system needs to contain the RuleSet and version specified in the Prerequisite RuleSet list.  Due to the nature of upgrading RuleSets, all versions of a RuleSet within a major version will be present.  If a customer receives PegaRULES RuleSet version 04-03-01, because of the way RuleSets are shipped, they will also receive versions 04-02-01 and 04-01-01. Thus, if the Prerequisite references Pega-ProCom version 04-01-01, and the overall system version of Pega-ProCom is version 04- 03 -01, new rules will still be validated, as long as all the rules referenced by a newly-created rule are present in a 04-01-01 version, to satisfy the Prerequisites.  If some of the rules referenced by the new rule are present only in the 04-03-01 version, the validation will fail.(This should not happen with Pega- RuleSets; it may be an issue if you have many RuleSets that are frequently moved between systems.)

Prerequisites are specified in the appropriate instance of the Rule-RuleSet-Version class:
​
In the above example, the ACME RuleSet, version 01-01-01, is dependent upon the Pega-ProCom RuleSet, version 04-01-01.  Pega-ProCom version 04-01-01 itself has a prerequisite:  

Therefore, the ACME RuleSet has both Pega-ProCom 04-01-01 and Pega-RULES 04-01-01 as prerequisites, because Pega-ProCom 04-01-01 requires Pega-RULES 04-01-01.

Whenever a new rule that is subject to rule resolution is created (an Activity, a Flow, a When, etc.), it is defined on a class , and saved into a particular RuleSet and Version.  If the class of the rule being created is not in the same RuleSet as the new rule, it is necessary that the RuleSet of the class be a prerequisite of the RuleSet of the new rule being validated; otherwise, the system will not be able to find the class, and errors will result.  (See Example #2.)

When you save a new rule into a RuleSet, two validations occur:

First Validation - Is the RuleSet of the new rule valid? 

• Is the version of the RuleSet (of the new rule trying to be saved/validated) correct for the Prerequisite RuleSet list?
• If the RuleSet version is correct, is this an open (i.e., not locked) RuleSet?

Second Validation - Are the contents of the rule valid?  

• The new rule may be defined on a class, or may reference properties, activities, etc.  Are the versions of the RuleSets that these classes, activities, etc. belong to correct for the Prerequisite RuleSet list?

In addition to their use when saving rules, prerequisites are used for validation when importing an entire RuleSet, or creating a new RuleSet.  A RuleSet can only be imported into a system that contains all the RuleSets/versions that are listed in its Prerequisites. This guarantees that the moved rules reference only rules that the target system contains. 
​
Thus, when developing a patch for an older version of a RuleSet, the Prerequisite RuleSet list would specify a dependency on the version of the rules that the organization has on-site.  For example, Pegasystems or a partner may want to create a new RuleSet Version instance for a patch for an organization.  The organization has version 04-01-01, but the current version that Pegasystems is working on is version 04-04-01.  To prevent the developers from building on rules that were introduced in version 04-02, that the organization doesn't have, the prerequisite RuleSet list is set to 04-01-01, so we can be sure that the new patch will work on the organization's version.

Issue with Restricting RuleSets
​A third issue may arise with saving a new rule into a RuleSet, from restrictions that are placed on the class itself.  In the Class form, there is a field labeled Limit Rules Applied to This Class To These RuleSets:

If this field is left blank, then there are no restrictions on what RuleSets may extend this class - i.e., it is possible to define properties, activities, etc. on this class and save it into any RuleSet.  
​
However, if one or more RuleSets are listed under the Limit Rules Applied field, then only those RuleSets may be used to extend the class (save objects on this class).  This class is thus immediately limited to only those RuleSets that are listed in this field.
Profile RuleSet Lists
While prerequisite RuleSet lists govern the creation of new rules, profile RuleSet lists govern rule execution at runtime.  The Profile RuleSet list is the list of RuleSets and their versions which must be present for the system to be able to choose and execute the correct rule (according to rule resolution) for actions at run-time.  Profile RuleSets are specified through Access Groups, Organization, and Divisions, and show up in a user's Profile, as the user's RuleSets. 

For whatever version of a RuleSet is displayed in the Profile RuleSet list, users will be able to see and use rules in RuleSets which are equal to or less than that version number.  So if the user's Profile RuleSet includes Pega-RULES:04-02 , then the user will see any rules from that RuleSet that were saved in version 04-02 or 04-01.  Rules that exist in the database at higher versions (04-04) will effectively be invisible.  Again, these rules are only within a major version - if there are rules in version 03-12 on the system, the user will not see these, even though they are in a version less than the 04-02 version in the profile.  

Summary
​Using a list view report on rules, a 5-step activity, and an HTML rule, you can revalidate all rules in one RuleSet, one RuleSet version, or a specific list of RuleSet versions.
The activity provides a comprehensive check of all rule types, in contrast to the Revalidate and Save tool which operates only on one rule type at a time.
If any rules fail validation, investigate and repair as needed. While validation does not ensure that a rule produces "correct" or "intended" results, execution of invalid rules is undesirable and often fails or produces incorrect results without warnings.

Suggested Approach

Each time a developer attempts to save a rule form, Process Commander performs numerous validation checks. Only rules that pass all these checks are saved.

So by definition, every saved rule was valid at one time, in a certain Process Commander system, when it was saved in a specific environment of other rules. However, at later times, or in other environments or other systems systems, a rule that was previously valid may become invalid. For example, rule ALPHA can become invalid if ALPHA depends on rule BETA but rule BETA was deleted after ALPHA was saved.

You can use the the built-in revalidator tool (accessed from the Developer portal menu Tools > Revalidate and Save ) to revalidate each rule of a single rule type in your RuleSets. For example, with this tool you can easily revalidate all the properties, or all the decision table rules, in one RuleSet. Revalidation adds a memo to the history of each rule that passes, even if the rule belongs to a locked Version.

However, it is sometimes helpful to revalidate all rules that meet specific criteria, such as all rules in a RuleSet, all rules updated since a specific date, or all rules updated by a specific developer.
​
The Data-Rule-Summary class supports reports on rules. (This class is linked to a database view, not a database table, in the PegaRULES database. See Related topics). If you can specify a set of rules to revalidate using exposed properties in this class, you can use the approach in this article.

This article describes how to call Java classes in the Process Commander application libraries to programmatically export and import Process Commander class instances from and to Process Commander databases.

• The Export command writes the specified class instances from a source PegaRULES database to a ZIP file in a binary format or as XML.
• The Import command takes the ZIP file as input and writes the exported class instances to a target system PegaRULES database.You can specify the class instances by RuleSet name and version, by class name with or without descendants, or bypzInsKey key values.
  
  

Note : The source Process Commander system must be V5.2 or later, and the destination Process Commander system must have the same or a later version than the source system.

n this diagram, the two Process Commander systems and a third computer executing the script are distinct. In practice, however, this operation can involve one, two, or three computers, or more if each Process Commander system uses a separate computer to host its PegaRULES database. The operation always involves two prconfig.xml files, one identifying the source PegaRULES database (containing the rules to be migrated), and the second identifying the target PegaRULES database.
Note that the Export and Import calls operate directly on the Process Commander databases, independent of the Process Commander applications. The transfer can even occur when the Process Commander application and its server are not in operation; however, the database servers must be running.
To complete this process:

1. Configure a Java JVM environment with access to the Process Commander engine JAR files and the appropriate database driver files.
2. Copy or create prconfig.xml files that specify the location and database access information for the source and target databases.
3. Call the Export method specifying the RuleSets or classes you want to move, and the ZIP file name to use.The Export method creates a Process Commander import archive file with the specified components from the source database.
4. Call the Import method specifying the name of the ZIP file and other database options.The Import method loads the database components in the import archive file into the target database.

Details on these steps are given below.
An example of an Apache Ant script calling these classes is provided below, but you could apply the same method to any scripting language. For example, you can create a Unix shell script to migrate a RuleSet version OurFinance:02-05-15 from a development system (labelled SOURCE in the diagram) to a unit testing system (labelled Target).
Important: This functionality does not duplicate the Product wizard. If you are moving entire Rule-Applications you should use the Import and Export Archive (formerly RulesMove) facility. When calling the Export method, you must specify exactly which RuleSets and/or classes you want to move. Before using these methods, be sure you understand RuleSets and RuleSet archives. 

​
1.    What is an Agent?
An agent is an internal background process operating on the server that runs activities on a periodic basis.
Agents route work according to the rules in our application.
Agents also perform system tasks such as sending e-mail notifications about assignments and outgoing correspondence, generating updated indexes for the full-text search feature, synchronizing caches across nodes in a multiple node system, and so on.

2.    How do we create an Agent?
New - >SysAdmin -> Agents
Rule Set name is the Agent name
       Agent is instance of Rule-Agent-Quiee.

3.    Do we need to create Agent Schedule?
No. Agent schedules cannot be created manually.
The Agent Manager on our Process Commander system generate at least one agent schedule instance for each agents rule.
By default, the Agent Manager checks for new or updated agents rule once every ten minutes.
After we create an agents rule, the Agent Manager generates one Agent Schedule instance for each node running on your Process Commander system the next time it checks for new agents rules.

4.    Do we need to migrate Agent Schedule to other environment?
No

5.    What are the Agent running time intervals?
Each agent activity runs individually on its own interval schedule, as a separate requestor thread.
§  Periodic — The agent runs the activity and then "sleeps" for the number of seconds entered in the Interval column.
§  Recurring — The agent runs the activity based on a specified calendar schedule (for example, every Monday at 5:00 P.M.).

6.    What are the Agent Running modes?
Queue mode indicates whether the agent uses the agent queue capability to process items from the agent queue. This feature allows the agent to temporarily skip over items that fail — for example, because a needed resource is locked — and try again later to process the item later.
§  Standard — Specifies that this agent processes items from an agent queue and that it relies on the system to provide object locking and other transactional support.
§  Advanced — Specifies that this agent uses custom queuing
§  Legacy — specifies that this is an agent that was created in a version prior to V5.4 and has not yet been updated. This option is not available for agents created in V5.4 or later.

7.    What is the use of referring Access Group in Agents?
Agent activity calls another activity. This called activity may not appear in agent rule set. So setup of the Rule set list and Roles by providing Access group in security Tab.
Select the access group to use for the legacy and advanced agents listed in this rule. This field is ignored for agents with a type of Standard.

8.    How do we Troubleshoot or Trace an Agent?
1.    < env name="agent/enable" value="true" />
Verify above tag in prconfig file. Value of the above tag is true or false.
2.    In Agent Schedule, schedule tab verify the check box Enable this agent is Checked or Not. And also verify the Enabled? Check box is checked or Not.
3.    Same thing also check in Agents Rule.

    In Tracer we can trace the particular operator or particular Agent.
    In prsysmgmt portal, In Agent Management select the particular Agent and Delay the Agent and then run the Tracer.
   We can use the Agent Management link in the System Management Application to monitor and control agent processing.
   Agent runs on different nodes, select the particular node and run the Tracer.


9.    What are the Agents for SLA and Correspondence?
The agents in the Pega-ProCom RuleSet process e-mail, service level rules, and assignments, archive work objects, and so on.
    The agents in this rule provide the following types of processing:
§ Processing service level events and escalation
§ Applying a flow action to assignments in bulk
§ Sending out e-mail correspondence
§ Archiving and purging work objects, attachments, and history
§ Retrieving PDF files from the PegaDISTRIBUTION Manager
§ Running tests defined through the optional Automatic Testing facility
§ Checking incoming e-mail
The activity System-Queue-ServiceLevel.ProcessEvents supports service level processing for both assignments and work objects.
The activity Data-Corr-.Send supports outgoing e-mail if your system contains one or more Email Account data instances with a second key part of Notify.


10. Who will create Data-Agent-Queue?
The Agent Manager is a master agent that gathers and caches the agent configuration information set for our system when Process Commander starts. Then, at a regularly scheduled interval, it determines whether any new agents rules were created during the last period. If there are new agents rules, the Agent Manager adds them to its list of agents and generates agent schedule data instances for them for each node.

11. What are the Standard Agents?
our system includes three standard agents rules. Because these agents rules are in locked RuleSets, we cannot modify them. To change the configuration settings for the agents listed in these rules, update the agent schedules generated from the agents rule.
Pega-IntSvcs,
Five agents in the Pega-IntSvcs RuleSet process queued service and connector requests and perform maintenance for PegaDISTRIBUTION MANAGER (formerly called Correspondence Output Server, or COS).
   
      Pega-ProCom,
The agents in the Pega-ProCom RuleSet process e-mail, service level rules, and assignments, archive work objects, and so on. The agents in this rule provide the following types of processing:

• Processing service level events and escalation
• Applying a flow action to assignments in bulk
• Sending out e-mail correspondence
• Archiving and purging work objects, attachments, and history
• Retrieving PDF files from the PegaDISTRIBUTION Manager
• Checking incoming e-mail (deprecated in V5.3)

    Pega-RULES
The agents in the Pega-RULES RuleSet perform general system housecleaning and periodic processing. The agents in this rule provide the following processing:
§ System cleaner
§ System Pulse
§ System Indexer§ Rule Usage Snapshot
§ Static Content Cleaner
§ System Work Indexer

12. What is the use of Data-Agent-Queue?
When you need to modify the behavior of an agent listed in an agents rule in a locked RuleSet (any of the standard Process Commander agents rules, for example) you do so by editing one or more of the generated agent schedule instances.