Forms have been completely redesigned in Pega 7, making it easier than ever to configure the elements needed to meet your design requirements. New click-to-edit fields and interactive links allow record updates directly in the form header. Standard record management tasks have been reconfigured into a suite of buttons that change state as you work in the Designer Studio. Tools and menus have been enhanced to put information at your fingertips without having to stray away from the Work Area.
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.
Warnings display in the form header with a condensed format.
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:
Now localizable and accessible from a variety of browsers, the Pega 7 Designer Studio provides a rich developer experience that is optimized for ease of use. A complete redesign puts intuitive tools at the forefront to simplify the design experience and enable you to quickly build enterprise scale applications. This article gives a tour of the Designer Studio, highlighting its major functions and new features.
Designer Studio groups elements consistently and logically
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
About the Designer Studio Header
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 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.
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 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:
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
Two kinds of RuleSet lists are defined in different places for different purposes, and there is no relationship between the two.
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 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?
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.
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.
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.
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.
The following diagram shows a conceptual view of the components involved in the process:
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:
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?
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.
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).
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:
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.
Nizampet Rd, Jai Bharat Nagar, Nagarjuna Homes, Kukatpally, Hyderabad, Telangana 500090
Greater New York City Area
New York -14624
© COPYRIGHT 2011 - 2018. ALL RIGHTS RESERVED.