Top 10 Pega Questions: Understanding Rule Validation, Assignment and Work Object Storage, Activity Execution, and More

1. What is the difference between the Page-Validate and Property-Validate methods in Pega?

Both Page-Validate and Property-Validate are methods used for data validation in Pega, but they operate at different levels.

Page-Validate is a method that validates an entire page (a collection of properties) against the rules defined in the class of that page. It checks all the properties on the page and ensures they meet the defined validation conditions. If any property fails validation, an error is raised, and the flow may be interrupted.

Property-Validate, on the other hand, validates a single property against the validation rules defined for that property in the class of the object. It focuses on validating a specific property rather than the entire page. If the property fails validation, an error is raised.

In summary, Page-Validate validates all properties on a page, while Property-Validate focuses on validating a specific property.

2. How do Edit Validate and Edit Input rules differ from each other in Pega?

Edit Validate and Edit Input rules are both used for validating user input, but they serve different purposes in Pega.

Edit Input rules are used to validate user input on the client side. They run on the user’s device or browser and provide immediate feedback to the user without making a server round-trip. Edit Input rules define the validation logic and error messages that are displayed to the user when input errors occur. They are typically used to ensure that user input meets specific format requirements or constraints before it is submitted.

Edit Validate rules, on the other hand, are used to validate user input on the server side. They are executed on the server during the processing of a user action or submission, after the data is sent from the client. Edit Validate rules are defined in the Pega ruleset and are responsible for performing more complex validations that cannot be performed on the client side alone. They can access additional data and external systems if needed and can enforce business rules and integrity constraints.

In summary, Edit Input rules are client-side validations that provide immediate feedback to the user, while Edit Validate rules are server-side validations that perform more complex validation logic and can access additional data.

3. Where are assignments stored in the Pega rules database?

Assignments in Pega are not stored in the rules database. Instead, they are stored in the Pega data schema known as the “work” schema. The work schema is separate from the rules schema and is used to store runtime data related to work objects, assignments, cases, and other process-related information.

The assignments are stored in dedicated tables within the work schema, such as pc_assign_worklist, pc_assign_workbasket, and pc_assign_workparty. These tables store information about assignments, including the assignment key, assignment status, assignment urgency, assignment owner, and other relevant details.

Separating the storage of assignments from the rules database allows for better performance and scalability, as the runtime data can be efficiently managed and optimized independently of the rules and definitions.

4. Where are work objects stored in Pega by default? How can they be stored in different tables?

Work objects in Pega are stored in the Pega data schema known as the “work” schema by default. The work schema contains tables that store runtime data related to work objects, assignments, cases, and other process-related information.

The primary table used to store work objects is typically named <class_name>_work. For example, if you have a class named “Customer” in Pega, the work objects for that class would be stored in the Customer_work table.

To store work objects in different tables, you can leverage Pega’s table routing capabilities. Table routing allows you to specify custom table names or patterns based on certain criteria. This can be done by defining a table routing policy rule and configuring it to route work objects to different tables based on conditions such as class, case type, or other criteria.

By defining specific table routing policies, you can partition work objects across multiple tables based on your specific requirements. This can be useful for performance optimization, data segregation, or compliance reasons.

5. How can three different work objects be stored in three different tables in Pega?

To store three different work objects in three different tables in Pega, you can leverage Pega’s table routing feature. Table routing allows you to specify custom table names or patterns based on specific criteria.

Here’s an example of how you can achieve this:

1. Define three classes, let’s say “ClassA,” “ClassB,” and “ClassC,” each representing a different work object type.
2. Create three separate table routing policies, one for each class.
3. In each table routing policy, specify the conditions for routing the work objects to the desired tables. For example, you can define a condition based on the class name.
4. Configure the table routing policy for each class to route the work objects to the respective table.

By setting up the table routing policies correctly, any new work object created for ClassA will be stored in TableA, ClassB objects in TableB, and ClassC objects in TableC. This allows you to store three different work objects in three different tables based on your specific requirements.

6. What are StepStatusGood and StepStatusFail rules in Pega?

StepStatusGood and StepStatusFail are Pega rules that are used to handle the status of individual steps within an activity.

StepStatusGood is a rule used to mark a step as successfully completed within an activity. It indicates that the execution of a specific step was successful, and the activity can proceed to the next step or continue its processing.

StepStatusFail, on the other hand, is a rule used to mark a step as failed within an activity. It indicates that the execution of a specific step encountered an error or exception, and the activity should handle the failure accordingly. The failure can trigger error handling mechanisms, such as error flows or exception handling logic, to manage the error condition and take appropriate actions.

These rules are used to manage the flow and control the execution path within an activity. By explicitly marking steps as either successful or failed, the activity can react appropriately and handle different scenarios based on the outcome of each step’s execution.

7. How can you make a rule a favorite for your manager in Pega?

In Pega, you can make a rule a favorite for your manager by following these steps:

1. Open the rule you want to mark as a favorite.
2. In the header section of the rule form, click on the “Actions” menu (represented by three dots or an ellipsis icon).
3. From the dropdown menu, select “Add to favorites.” This action adds the rule to your personal favorites list.
4. After adding the rule to your favorites list, you can share it with your manager.
5. To share your favorites list, go to the Pega portal’s landing page or dashboard.
6. Locate the “Favorites” section, which is typically found on the homepage or a dedicated favorites tab.
7. Within the “Favorites” section, you should see a link or an option to share your favorites list.
8. Click on the share link or option and provide your manager’s details (e.g., name, email address) to send them a copy of your favorites list.
9. Alternatively, you can communicate the name or ID of the rule to your manager, and they can search for it and add it to their own favorites list.

By following these steps, you can make a rule a favorite for your manager and share your preferred rules with them for easy access and reference.

8. Where can you see the parameter values being passed from one activity to another in Pega?

In Pega, you can view the parameter values being passed from one activity to another in the Tracer tool. The Tracer is a powerful debugging and diagnostic tool that allows you to trace the execution of rules, activities, and processes in Pega applications.

To see the parameter values passed between activities in the Tracer, you can follow these steps:

1. Open the Tracer tool in Pega. The Tracer can usually be accessed through the developer toolbar or menu options in the Pega portal.
2. Configure the Tracer settings to capture the desired events and activities.
3. Start the Tracer and perform the actions that trigger the execution of the activities you’re interested in.
4. Once the trace is captured, locate the activity of interest in the Tracer output.
5. Expand the activity details to see the individual steps executed within the activity.
6. Within each step, you can view the parameter values being passed by expanding the step details. Look for the “Parameters” or “Input” section, which displays the input values passed to the activity step.

The Tracer provides a detailed view of the activity execution flow, including the parameter values at each step. This allows you to analyze and troubleshoot how data is passed between activities and identify any potential issues or discrepancies.

9. What is the difference between an activity and a utility in Pega?

Activity: In Pega, an activity is a reusable block of procedural logic that performs a specific task. It is defined as a series of sequential steps and can be called from various rules and components within an application. Activities can interact with the case data, manipulate properties, make decisions, invoke other activities, and perform various operations.

Utility: On the other hand, a utility is a type of activity that is specifically designed to perform background processing or system-level operations. Utilities are often used for tasks like data loading, batch processing, system maintenance, or integration with external systems. They are typically scheduled to run at specific times or triggered by events.

The key difference between an activity and a utility lies in their purpose and usage. Activities are primarily used for processing within cases or user interactions, while utilities are dedicated to system-level operations and background processing.

10. What is the difference between Obj-Open and Obj-Open-By-Handle methods in Pega?

Difference between Obj-Open and Obj-Open-By-Handle methods in Pega: Both Obj-Open and Obj-Open-By-Handle methods are used to retrieve instances of a class in Pega, but they differ in the way they identify the instance to be retrieved:

• Obj-Open: This method retrieves instances based on a set of conditions specified in the step. It allows you to specify property values or expressions to filter and find the desired instance(s). If multiple instances match the criteria, the method retrieves the first one found based on the defined sort order.
• Obj-Open-By-Handle: This method retrieves instances using a unique identifier called the handle. The handle is a system-generated key assigned to each instance, and it ensures direct access to a specific instance without the need for any filtering or sorting. It provides a faster and more efficient way to retrieve a known instance based on its handle.

In summary, Obj-Open and Obj-Open-By-Handle are both methods used in Pega to retrieve instances of classes. Obj-Open relies on key properties for identification, while Obj-Open-By-Handle uses a unique handle assigned to each instance.