# Pega Platform Design The **Pega Platform** is a low-code platform designed for building enterprise applications quickly and efficiently. This section focuses on **how to design applications effectively** using Pega. It covers the **architecture**, scalability, performance optimization, and deployment strategies. ## **1.1 Center-out Business Architecture** ### **What is Center-out Business Architecture?** - **Center-out** is a Pega design approach that aligns **business goals** with **technology solutions**. - Instead of starting from the **front-end (user interfaces)** or the **back-end (systems)**, Pega starts at the **business logic** level (the center). This allows you to focus on what truly matters: delivering business outcomes. ### **Core Concepts of Center-out Design** The Center-out approach focuses on **three key components**: 1. **Microjourneys** 2. **Decisions** 3. **Channels and User Experience (UX)** ### 1. **Microjourneys** – Breaking Large Processes into Smaller Parts - A **Microjourney** is a small, manageable piece of a business process that delivers a specific outcome. - Instead of creating one giant process (e.g., “loan approval”), you divide it into smaller steps, such as: 1. **Application Submission** 2. **Document Verification** 3. **Credit Review** 4. **Approval/Denial** #### **Why Microjourneys?** - **Simplifies processes**: Breaking processes into smaller parts makes them easier to manage, test, and deploy. - **Focuses on outcomes**: Each Microjourney has a clear and achievable outcome. - **Supports incremental delivery**: Build and deploy small pieces first, improving speed to market. #### **Example: Loan Application Process** Imagine a bank that wants to automate its loan approval system. The **entire process** may look like this: - **Stage 1**: Application Submission - **Stage 2**: Document Verification - **Stage 3**: Credit Scoring - **Stage 4**: Decision (Approval/Denial) Each stage can be treated as a **Microjourney**. ### 2. **Decisions** – Automating Business Decisions In Pega, **Decisions** help automate complex business logic, so you don’t need manual intervention for every task. - Decisions can be automated using: - **Decision Tables**: Tables that map inputs (conditions) to outputs (results). - **Decision Trees**: A tree structure to evaluate multiple conditions in sequence. - **Scorecards**: Used for scoring and ranking data (e.g., credit scores). - **Prediction Models**: AI-based models that predict outcomes. #### **Why Decisions?** - **Reduces errors**: Automation eliminates human mistakes. - **Improves consistency**: Decisions are based on pre-defined rules, ensuring predictable outcomes. - **Increases speed**: Automated decisions are faster than manual processes. #### **Example: Loan Approval Decisions** - If a customer has a **credit score > 700**, approve the loan automatically. - If the score is between **600–700**, send the application for manual review. - If the score is **< 600**, reject the application. In Pega, you can configure these conditions in a **Decision Table** or **Decision Tree**. ### 3. **Channels and UX** – Delivering Across Multiple Channels Pega allows you to design solutions that work seamlessly across different **channels** (interfaces), such as: 1. **Web Applications**: Standard browser-based apps. 2. **Mobile Applications**: Responsive apps for mobile devices. 3. **Chatbots and Messaging**: Integration with chat platforms like Facebook Messenger or Slack. 4. **Email**: Automating emails for notifications or updates. 5. **Voice**: Solutions for voice-enabled platforms. #### **Why is Multi-Channel Delivery Important?** - **Customer convenience**: Users interact with businesses on different devices and platforms. - **Consistency**: Ensures the experience is consistent across channels. - **Increased reach**: Supports different user groups and business needs. #### **Example: Multi-Channel Loan Application** - **Web**: Users apply for a loan on the bank’s website. - **Mobile**: They check their application status on the mobile app. - **Email**: The bank sends approval notifications via email. - **Chatbot**: Customers get loan-related answers using an AI chatbot. ### **Benefits of Center-out Design** The **Center-out Design** approach provides several key advantages: 1. **Improves Business Agility**: - Applications are built to adapt quickly to changing business needs. - Microjourneys allow for incremental improvements and faster delivery. 2. **Enhances Reusability**: - Microjourneys, decisions, and rules can be reused across multiple processes or applications. - Saves development time and reduces redundancy. 3. **Simplifies Complex Processes**: - By focusing on business outcomes, you break complex processes into manageable parts. - It’s easier to build, test, and deploy each piece incrementally. ### **Summary of Center-out Design** - **Start at the center**: Focus on business outcomes and decisions. - **Break processes into Microjourneys**: Small steps with clear outcomes. - **Automate decisions**: Use decision tables, trees, and AI models. - **Deliver across channels**: Ensure solutions work on web, mobile, chat, and more. By following the Center-out approach, you can create scalable, efficient, and adaptable solutions that align perfectly with business goals. ## **1.2 Application Layering** Application Layering in Pega refers to the structured organization of rules and resources into layers. This ensures modularity, reusability, and maintainability of applications in enterprise environments. #### **Why is Application Layering Important?** - Promotes **reusability**: Rules and components can be reused across applications. - Improves **scalability**: Applications can be scaled efficiently by adding new layers. - Simplifies **maintenance**: Changes in one layer do not disrupt other layers. - Supports **enterprise-level applications**: Aligns application development with organizational structures. ### **Enterprise Class Structure (ECS)** Pega provides a standard framework called the **Enterprise Class Structure (ECS)** for organizing application layers. ECS divides an application into **four main layers**: | **Layer** | **Purpose** | **Example** | | ------------------------ | ----------------------------------------------------------- | ------------------------------------------ | | **Organization Layer** | Common rules shared across the organization. | Policies, standard UI templates. | | **Division Layer** | Rules reused within specific divisions of the organization. | Rules specific to retail or finance units. | | **Framework Layer** | Industry-specific reusable rules and components. | Loan application templates for banking. | | **Implementation Layer** | Application-specific rules for a single project. | Custom rules for a specific bank branch. | #### **Layers in Detail** #### 1. **Organization Layer** The **Organization Layer** contains rules that are common across the entire organization. It serves as the foundation for all applications. - **Purpose**: - Store reusable rules, templates, and policies. - Provide standard components that all applications can inherit. - **Examples**: - UI Templates: Standard headers, footers, or branding styles. - Organization-wide policies: Security rules, encryption settings. - **Naming Convention**: - The organization layer starts with the **Organization Name**. - Example: `OrgName-` (e.g., `ABCInsurance-`). #### 2. **Division Layer** The **Division Layer** contains rules that are specific to certain divisions or departments within the organization. - **Purpose**: - Enable reuse of rules within specific divisions. - Provide flexibility for departments to customize shared rules. - **Examples**: - **Retail Division**: Rules for managing retail banking products. - **Corporate Division**: Rules for handling corporate banking loans. - **Naming Convention**: - Add the division name after the organization. - Example: `OrgName-DivisionName-` (e.g., `ABCInsurance-Retail-`). #### 3. **Framework Layer** The **Framework Layer** contains **reusable assets** for industry-specific or application-specific purposes. These assets are shared across implementations. - **Purpose**: - Provide a base template for creating applications. - Deliver reusable components, such as workflows and case types. - **When to Use**: - Use for creating a standard solution that can be implemented by multiple clients or projects. - **Examples**: - Loan Application Process: A reusable framework for processing loan requests in a bank. - Customer Service Framework: A template for managing customer complaints and queries. - **Naming Convention**: - Include the framework name after the organization. - Example: `OrgName-FW-FrameworkName-` (e.g., `ABCInsurance-FW-LoanProcessing-`). #### 4. **Implementation Layer** The **Implementation Layer** contains rules that are specific to a particular application, project, or business unit. - **Purpose**: - Customize the framework layer for specific business needs. - Contain rules that are tailored to an individual application. - **Examples**: - Application-specific workflows for a bank branch or project. - Custom rules for regional or legal compliance. - **Naming Convention**: - Include the implementation name after the framework layer. - Example: `OrgName-FW-FrameworkName-ImplementationName` (e.g., `ABCInsurance-FW-LoanProcessing-LoanAppUK`). ### **Example: A Banking Application** Let’s see how ECS applies to a banking scenario. 1. **Organization Layer** (`ABCInsurance-`): - Contains branding styles, organization-wide policies, and security settings. 2. **Division Layer** (`ABCInsurance-Retail-`): - Contains rules specific to the **Retail Division** of ABCInsurance, such as personal banking workflows. 3. **Framework Layer** (`ABCInsurance-FW-LoanProcessing-`): - Provides reusable components for managing loan applications (e.g., workflows for document verification, credit scoring, and approvals). 4. **Implementation Layer** (`ABCInsurance-FW-LoanProcessing-LoanAppUK`): - Customizes the loan application process for the UK market with specific regulatory rules. ### **Best Practices for Application Layering** 1. **Plan Ahead**: - Understand the organization’s structure and create layers accordingly. 2. **Reuse Components**: - Place shared rules (e.g., policies, templates) in higher layers (Organization or Framework) to maximize reuse. 3. **Avoid Duplication**: - Avoid copying the same rule across layers. Use inheritance and specialization. 4. **Keep Layers Simple**: - Ensure each layer has a clear purpose and avoid overcomplicating the structure. 5. **Test Incrementally**: - Validate rules layer by layer to ensure consistency and avoid conflicts. ### **Summary of Application Layering** - Application Layering in Pega follows the **Enterprise Class Structure (ECS)**. - ECS organizes applications into four layers: 1. **Organization Layer**: Rules shared across the organization. 2. **Division Layer**: Rules specific to divisions or departments. 3. **Framework Layer**: Industry-specific reusable assets. 4. **Implementation Layer**: Customized rules for specific applications. - Following ECS ensures that applications are modular, reusable, and scalable. ## **1.3 Performance Optimization** Performance optimization ensures that Pega applications run efficiently, respond quickly, and scale seamlessly as workloads increase. Optimizing performance is critical for ensuring user satisfaction, reducing system load, and maintaining application reliability. ### **Why is Performance Optimization Important?** - **Improves User Experience**: Faster response times improve usability. - **Reduces System Load**: Efficient resource usage allows the system to handle more concurrent users. - **Supports Scalability**: Optimized applications can grow without performance degradation. - **Enhances Maintainability**: Well-optimized applications are easier to debug and manage. ### **Core Topics for Performance Optimization** 1. **Performance Monitoring Tools** 2. **Performance Improvement Techniques** ### **1.3.1 Performance Monitoring Tools** Pega provides tools to monitor and diagnose performance issues proactively. These tools help identify slow-running processes, resource bottlenecks, and system errors. #### **1. Pega Predictive Diagnostic Cloud (PDC)** - **What is PDC?** - PDC is a cloud-based performance monitoring tool provided by Pega. - It collects **alerts**, **system health data**, and **usage statistics** in real time. - **Features**: 1. **Proactive Monitoring**: Detects performance problems before they impact users. 2. **Alerts**: Tracks issues like slow database queries, memory usage, or long-running processes. 3. **Performance Trends**: Analyzes trends to predict potential failures. 4. **Root Cause Analysis**: Identifies the root cause of performance issues and provides recommendations. - **Example**: - If a database query is taking too long, PDC sends an alert and provides details, such as the query, table name, and execution time. #### **2. Autonomic Event Services (AES)** - **What is AES?** - AES is an on-premises alternative to PDC for monitoring application performance. - It provides similar features but is deployed and managed on your infrastructure. - **Key Features**: - Proactive monitoring and alerting. - Health tracking of nodes, processes, and agents. - Diagnostic tools for analyzing performance. - **When to Use**: - Use AES when the organization prefers on-premise monitoring due to security or compliance constraints. #### **3. Admin Studio** - **Purpose**: - Admin Studio provides real-time system monitoring for node health, agents, and queue processors. - **Key Features**: - Monitor **agent health**: Check if agents are running properly. - View **queue processors**: Track asynchronous jobs and their statuses. - Manage **job schedulers**: Monitor the performance of scheduled background tasks. - **Example**: - If a background process (e.g., sending emails) is failing repeatedly, Admin Studio can identify the issue and allow you to restart or debug the process. #### **4. Logs and Alerts** - Pega generates various logs to help you identify issues: 1. **System Logs**: Records system events and errors. 2. **Alert Logs**: Captures performance issues such as slow database queries or long-running activities. - **Log Analyzer**: - Use tools like **Log Analyzer** to parse logs and identify recurring performance issues. ### **1.3.2 Performance Improvement Techniques** After monitoring and identifying issues, you can apply optimization techniques to improve application performance. #### **1. Optimize Data Access** - **Problem**: Excessive database hits slow down application performance. - **Solutions**: - Use **Data Pages**: - Data Pages load and cache data to reduce frequent database queries. - Use **Node-level** caching for data shared across users. - Avoid unnecessary database queries: - Do not fetch more data than required. - Use **Pagination** to retrieve data in smaller chunks. #### **Example**: - Instead of querying all customer data from a database, configure a **Data Page** to fetch only active customers, and use caching to store the data temporarily. #### **2. Declarative Processing** - **Problem**: Repetitive calculations (e.g., recalculating totals) impact performance. - **Solutions**: - Use **Declarative Rules** such as **Declare Expressions** to automate calculations efficiently. - Pega automatically recalculates values only when dependent properties change. #### **Example**: - In a shopping cart application, the total price can be calculated using a **Declare Expression** that automatically recalculates when product quantities or prices change. #### **3. Minimize Nested Loops in Activities** - **Problem**: Deeply nested **for-each loops** in activities cause performance bottlenecks. - **Solution**: - Use optimized logic to reduce the number of iterations. - Replace loops with **Declarative Rules** or **Data Pages** when possible. #### **Example**: - Instead of looping through all orders to find completed ones, use a **Report Definition** to fetch only completed orders directly from the database. #### **4. Use Report Definitions for Data Retrieval** - **Problem**: Custom SQL queries or loops are inefficient for retrieving data. - **Solution**: - Use **Report Definitions** to query and filter data efficiently. - Apply **database indexing** for frequently queried columns to improve performance. #### **5. Optimize UI Performance** - **Problem**: Slow-loading screens impact user experience. - **Solutions**: 1. **Defer Load**: Use the **Defer Load** option to load sections only when required. 2. **Responsive Design**: Ensure UI components load properly on all devices. 3. **Avoid Large Tables**: Use pagination and filters to display data efficiently. ##### **Example**: - If a dashboard contains several widgets, use the **Defer Load** feature to load each widget only when the user scrolls to it. #### **6. Background Processing for Heavy Workloads** - **Problem**: Long-running tasks can block user interactions. - **Solution**: - Use **Queue Processors** and **Job Schedulers** to handle tasks in the background. - Schedule resource-intensive processes during off-peak hours. ##### **Example**: - Generating monthly reports can be scheduled as a background job using a **Job Scheduler** instead of running it in real time. #### **7. Use Load Balancing** - **Problem**: High user traffic can overwhelm servers. - **Solution**: - Implement **Load Balancers** to distribute workloads evenly across multiple nodes. - Horizontal scaling: Add new nodes to handle increased load. ### **Summary of Performance Optimization** 1. **Monitor Performance** using tools like **PDC**, **AES**, and **Admin Studio** to identify issues. 2. **Optimize Data Access** with Data Pages, caching, and efficient queries. 3. **Avoid Nested Loops** and use declarative processing where possible. 4. **Use Report Definitions** to query data efficiently. 5. **Enhance UI Performance** with features like **Defer Load** and pagination. 6. **Handle Background Workloads** with Queue Processors and Job Schedulers. 7. **Scale Applications** using load balancers and horizontal scaling. ## **1.4 Deployment Options** The **deployment model** defines where and how Pega applications are hosted, deployed, and managed. Pega provides flexible deployment options to suit different organizational needs, ranging from **cloud-based solutions** to **on-premises environments**. #### **Why is Deployment Strategy Important?** - Ensures **scalability**: The system can grow as usage increases. - Guarantees **high availability**: Uptime and reliability are maintained. - Supports **cost optimization**: Resources are allocated efficiently. - Enables compliance with **security policies**: Sensitive data can be managed in secure environments. ### **Deployment Models** #### 1. **Cloud Deployment** Pega offers fully managed cloud-based solutions for hosting applications. The cloud model provides scalability, cost efficiency, and maintenance-free infrastructure. ##### **Pega Cloud** - **Definition**: Pega Cloud is a **Platform as a Service (PaaS)** offering where Pega manages the infrastructure, upgrades, and monitoring. - **Features**: - Fully managed infrastructure with automated patching and upgrades. - **High Availability (HA)**: Ensures uptime through clustering and redundancy. - **Security**: Compliance with industry standards (e.g., ISO, SOC2). - **Scalability**: Resources scale dynamically based on workload. - **Advantages**: - Reduces operational overhead (no need for IT teams to manage servers). - Speeds up deployment with preconfigured infrastructure. - Supports continuous monitoring through **Pega Predictive Diagnostic Cloud (PDC)**. - **Cloud Providers**: - Pega Cloud is typically hosted on platforms like **AWS**, **Microsoft Azure**, or **Google Cloud Platform**. ##### **Example Use Case**: - A bank wants to quickly deploy its loan application system globally. Pega Cloud allows the bank to go live faster without worrying about managing servers. #### 2. **On-Premises Deployment** In an **on-premises deployment**, the application is hosted on infrastructure owned and managed by the organization. ##### **Key Features**: - **Full Control**: Organizations have complete control over the servers, networks, and data. - **Customization**: The infrastructure can be configured to meet unique security or compliance needs. - **Monitoring Tools**: Use tools like **Autonomic Event Services (AES)** for proactive monitoring. ##### **Advantages**: - Suitable for organizations with strict **regulatory or security requirements**. - Data remains within the organization's private infrastructure. ##### **Challenges**: - Higher operational costs for managing hardware, upgrades, and monitoring. - Requires skilled IT teams for deployment and maintenance. ##### **Example Use Case**: - A government agency handling sensitive citizen data chooses on-premises deployment to comply with national data security laws. #### 3. **Hybrid Deployment** A **hybrid deployment** combines cloud and on-premises models. It allows organizations to leverage the benefits of the cloud while maintaining certain workloads on-premises. ##### **Why Use Hybrid Deployment?** - **Data Segmentation**: Store sensitive data on-premises while hosting non-sensitive processes on the cloud. - **Incremental Transition**: Gradually migrate from on-premises systems to the cloud. - **Load Optimization**: Use the cloud for handling peak traffic while maintaining critical workloads on-premises. ##### **Example Use Case**: - An insurance company stores customer records on-premises for compliance but uses Pega Cloud to handle customer service workflows. ### **DevOps Integration** To improve deployment efficiency, Pega supports **DevOps practices** such as automation, continuous integration, and continuous delivery (CI/CD). #### **What is DevOps?** **DevOps** is a methodology that combines development (Dev) and operations (Ops) to automate and streamline the software delivery process. #### **DevOps Tools and Features in Pega** 1. **Deployment Pipelines**: - Pega supports **CI/CD pipelines** to automate the build, test, and deployment process. - Tools like **Jenkins**, **Azure DevOps**, and **Git** can be integrated with Pega. 2. **Product Rules**: - Use **Product Rules** to package and migrate application rules and data from one environment to another. - Example: Move an application from a development environment to a testing environment. 3. **Continuous Integration**: - **Rule Versioning**: Maintain versions of rules in a structured manner. - Automated testing and validation ensure applications are error-free before deployment. 4. **Continuous Delivery**: - Automate deployment processes for production environments. - Use **Deployment Manager**: A Pega tool to manage deployment pipelines. #### **Steps for CI/CD Deployment in Pega** 1. **Build Phase**: - Develop and test rules in a development environment. - Package rules using a **Product Rule**. 2. **Test Phase**: - Automatically test rules using **PegaUnit** or other testing frameworks. - Perform performance testing and security checks. 3. **Deploy Phase**: - Move applications to higher environments (QA, staging, production). - Use tools like **Deployment Manager** to automate deployment. 4. **Monitor Phase**: - Monitor application performance using **PDC** or **AES**. ### **Deployment Best Practices** 1. **Choose the Right Deployment Model**: - Use **Pega Cloud** for fast, managed deployments. - Use **On-Premises** for sensitive workloads. - Use **Hybrid** to balance performance, security, and cost. 2. **Automate Deployments**: - Use CI/CD pipelines to automate builds, testing, and releases. 3. **Use Version Control**: - Ensure all rules are versioned properly using **RuleSets**. 4. **Test Before Deployment**: - Validate application behavior through automated unit tests and integration tests. 5. **Monitor Post-Deployment**: - Use PDC, AES, and logs to track performance and quickly resolve issues. ### **Summary of Deployment Options** 1. **Cloud Deployment**: Fully managed infrastructure with scalability and minimal maintenance. 2. **On-Premises Deployment**: Self-managed infrastructure for security and compliance. 3. **Hybrid Deployment**: Combines cloud and on-premises for flexibility. 4. **DevOps Integration**: Streamlines deployment through automation and CI/CD pipelines. ## **1.5 Application Monitoring and Logging** Effective monitoring and logging help maintain the health, performance, and reliability of Pega applications. Monitoring tools provide insights into system behavior, while logs capture detailed information to diagnose and resolve issues. ### **Why Application Monitoring and Logging Are Important** 1. **Detect Performance Issues**: Identifies slow processes, long-running tasks, and resource bottlenecks. 2. **Ensure System Health**: Tracks system components like nodes, agents, and jobs to prevent outages. 3. **Enable Troubleshooting**: Logs provide valuable insights into root causes of errors and failures. 4. **Improve User Experience**: Continuous monitoring ensures responsiveness and uptime. ### **Core Topics for Monitoring and Logging** 1. **Log Management** 2. **Monitoring Node Health** 3. **Alert Thresholds** ### **1.5.1 Log Management** Pega generates logs that capture **system events**, **errors**, and **performance alerts**. These logs are critical for diagnosing and resolving issues. #### **Types of Logs** 1. **System Logs** - Capture system-level events, warnings, and errors. - Used for diagnosing application crashes, exceptions, and system failures. - Example: ``` ERROR - Rule-Declare-Expression failed: Unable to evaluate expression 'TotalPrice = Qty * UnitPrice' ``` 2. **Alert Logs** - Capture performance-related alerts, such as: - **Slow-running queries** - **Excessive memory usage** - **Long-running processes** - Alerts are triggered when performance thresholds are breached. - **Example of an Alert Log**: ``` PEGA0001 - Query took more than 2000 ms: SELECT * FROM CUSTOMERS WHERE STATUS='ACTIVE' ``` 3. **Pega-Specific Logs** - **BIX Logs**: Track data extraction activities. - **Security Logs**: Capture authentication and authorization events. #### **Log Analysis Tools** 1. **Log Analyzer** - **What is it?** - Pega’s Log Analyzer tool processes log files to identify trends and recurring issues. - **What It Does**: - Provides a summary of error types and alerts. - Highlights performance bottlenecks. 2. **Third-Party Tools** - Logs can be exported to external tools like **Splunk**, **ELK Stack (Elasticsearch, Logstash, Kibana)**, or **Prometheus** for centralized analysis and visualization. ### **1.5.2 Monitoring Node Health** Pega applications run on a **clustered environment** where multiple **nodes** (servers) work together to handle workloads. Monitoring node health ensures all nodes function properly and efficiently. #### **What Is a Node?** A **node** represents a running instance of a Pega application server. Nodes handle user requests, background tasks, and system processes. #### **Tools for Node Health Monitoring** 1. **Admin Studio** - Admin Studio is Pega’s built-in tool for monitoring system health. - **Key Features**: - **Node Status**: Shows whether nodes are active, down, or unhealthy. - **Agent Health**: Monitors background agents to ensure they are running. - **Queue Processors**: Displays queue statuses (e.g., success, failure). - **Example**: - If a node is consuming too much memory, Admin Studio can flag it for investigation. 2. **Pega Predictive Diagnostic Cloud (PDC)** - Provides real-time health monitoring for nodes and servers. - Generates alerts for node failures or resource bottlenecks. #### **Health Metrics to Monitor** 1. **Memory Usage**: Track memory consumption on each node to identify potential leaks. 2. **CPU Utilization**: Monitor high CPU usage caused by intensive tasks or processes. 3. **Agent and Job Status**: Ensure all agents and background jobs are functioning properly. 4. **Node Uptime**: Track how long nodes have been running without interruptions. ### **1.5.3 Configuring Alert Thresholds** Pega applications use **performance thresholds** to trigger alerts when a component exceeds acceptable limits. #### **Common Alert Thresholds** | **Metric** | **Threshold** | **Purpose** | | ---------------------------- | ----------------------------- | ------------------------------------------ | | **Database Query Time** | > 2000 milliseconds (ms) | Detects slow database queries. | | **Memory Usage** | > 80% of available memory | Prevents memory overload or leaks. | | **CPU Utilization** | > 90% of CPU capacity | Ensures CPU resources are not overwhelmed. | | **Response Time** | > 2 seconds | Tracks slow application response times. | | **Queue Processor Failures** | More than X failures per hour | Identifies failed background processes. | #### **How to Configure Alerts** 1. Go to **Admin Studio** → **System** → **Settings** → **Performance Thresholds**. 2. Set thresholds for database queries, memory usage, response times, etc. 3. Enable notifications to alert system administrators when thresholds are breached. #### **Example of Performance Alert** When a query takes longer than the configured threshold (e.g., 2000ms), Pega logs an **alert**: ``` PEGA0005 - Query execution time exceeded threshold. Query: SELECT * FROM CUSTOMERS WHERE STATUS = 'ACTIVE' ``` - **Impact**: Slow queries degrade application performance. - **Resolution**: - Optimize the query. - Add database indexes to improve query performance. - Cache frequently accessed data using Data Pages. ### **Summary of Application Monitoring and Logging** 1. **Log Management**: - System logs capture events and errors. - Alert logs track performance issues. - Use tools like **Log Analyzer** or third-party tools (Splunk, ELK). 2. **Node Health Monitoring**: - Monitor node status, memory, CPU, and agent health using **Admin Studio** and **PDC**. 3. **Alert Thresholds**: - Configure performance thresholds for queries, memory, and response times. - Proactively identify and resolve performance bottlenecks. By effectively monitoring logs, system health, and performance thresholds, you can ensure your Pega application remains reliable, responsive, and efficient. ## **1.6 Rule Management and Versioning** Pega’s core strength lies in its **rule-based architecture**. Everything in Pega—like workflows, UI designs, integrations, and decision logic—is defined using **rules**. Effective rule management and versioning ensure that applications remain modular, easy to maintain, and capable of handling changes efficiently. ### **Key Concepts** 1. **Rule Management** 2. **RuleSets** 3. **Application Rules** 4. **Version Control** ### **1.6.1 What is a Rule?** A **rule** in Pega is a reusable, configurable piece of logic that defines application behavior. Rules include instructions for: - **Workflows**: Process flows, stages, and steps. - **UI**: Layouts, sections, forms, and components. - **Data**: Data pages, data transforms, properties. - **Decisions**: Decision tables, trees, and logic. - **Integrations**: Connectors, services, and database queries. **Example**: - A **decision table** rule might determine loan approval eligibility based on income and credit score. - A **section rule** might define how the loan application form appears on a web page. ### **1.6.2 RuleSets** #### **What is a RuleSet?** A **RuleSet** is a logical grouping of related rules. It serves as a container that organizes rules and allows developers to manage versions and dependencies. #### **Structure of a RuleSet** A RuleSet has three components: 1. **Name**: Identifies the RuleSet (e.g., `LoanApp`). 2. **Version**: Tracks rule changes over time (e.g., `01-01-01`). 3. **Rules**: The actual rules inside the RuleSet (e.g., sections, properties, activities). **Naming Convention**: - RuleSet name usually follows this format: **ApplicationName**-**Purpose**. - Example: - `LoanApp-Data` → RuleSet for loan-related data. - `LoanApp-UI` → RuleSet for user interface components. #### **RuleSet Versions** - RuleSet versions follow a **three-part versioning** convention: **XX-YY-ZZ**. - **XX**: Major version – Represents significant application changes (e.g., new features). - **YY**: Minor version – Represents incremental updates (e.g., minor enhancements). - **ZZ**: Patch version – Represents fixes (e.g., bug fixes, small updates). **Example**: - `LoanApp:01-01-01` → Initial version of the RuleSet. - `LoanApp:01-01-02` → Patch update for bug fixes. - `LoanApp:01-02-01` → Minor update with enhancements. - `LoanApp:02-01-01` → Major version with new features. #### **Best Practices for RuleSets** 1. **Organize by Function**: Use separate RuleSets for data, UI, processes, and integrations. 2. **Version Control**: Always increment versions when modifying rules. 3. **Minimize Dependencies**: Avoid creating too many dependencies between RuleSets. 4. **Lock RuleSets**: Lock older versions to prevent accidental changes. ### **1.6.3 Application Rules** The **Application Rule** defines the overall structure and components of a Pega application. It includes references to: - RuleSets - Organizational layers - Access groups - Built-on applications (inheritance). #### **Application Stack** An **application stack** determines how RuleSets are layered and inherited. Applications can build on other applications, allowing you to reuse rules. #### **Application Validation (AV) vs. Ruleset Validation (RV)** Pega supports two types of rule validation to ensure consistency: 1. **Application Validation (AV)**: - Rules are validated against the **current application stack**. - Use when rules are tightly coupled to the application. - **Example**: Rules specific to a single loan approval application. 2. **Ruleset Validation (RV)**: - Rules are validated independently of the application. - Use for **reusable RuleSets** that can be shared across multiple applications. - **Example**: A generic customer data management RuleSet. **Best Practice**: - Use **Ruleset Validation** for reusable components. - Use **Application Validation** for application-specific rules. ### **1.6.4 Version Control and Product Rules** #### **Rule Versioning** 1. **Increment RuleSet Versions**: Always create new RuleSet versions for changes. 2. **Lock Older Versions**: Lock previous versions to prevent unintentional changes. #### **Product Rules** A **Product Rule** packages application components (RuleSets, data, and dependencies) for deployment or migration. - **When to Use**: - Moving applications from **development** to **testing** or **production** environments. - Creating backups for application components. **Key Components of Product Rules**: - RuleSets: Include RuleSets and versions. - Data: Include test data or configurations. - Security: Include roles, access groups, and permissions. #### **Exporting and Importing Product Rules** 1. **Export**: Package the application components into a **ZIP file** using the Product Rule. 2. **Import**: Deploy the ZIP file into a new environment. **Example**: - Package `LoanApp` (RuleSets `LoanApp-Data`, `LoanApp-UI`, etc.) into a Product Rule to move it from **Development** to **QA**. ### **Best Practices for Rule Management and Versioning** 1. **Organize RuleSets**: Separate rules by function (data, UI, processes, integrations). 2. **Lock RuleSets**: Prevent changes to older versions. 3. **Increment Versions**: Always create new versions when modifying rules. 4. **Use Application Validation for Projects**: For tightly coupled rules. 5. **Use Ruleset Validation for Reusability**: For reusable components across applications. 6. **Document Changes**: Keep clear documentation of rule updates and dependencies. ### **Summary of Rule Management and Versioning** 1. **RuleSets**: Group rules logically and manage versions using a three-part format (e.g., `01-01-01`). 2. **Application Rules**: Define the application structure and stack. 3. **Validation Modes**: - **AV**: Tied to the application stack. - **RV**: For reusable RuleSets. 4. **Product Rules**: Package and migrate rules across environments. 5. **Best Practices**: Organize rules effectively, lock older versions, and document changes. ## **1.7 Scalability and High Availability** Scalability and high availability are essential for enterprise applications to maintain performance, stability, and uptime, even under heavy workloads or failures. Pega’s architecture supports both **scaling** (to handle more work) and **high availability** (to maintain uptime). ### **Why Scalability and High Availability Are Important?** 1. **Scalability**: Ensures applications can grow to handle increasing numbers of users, workloads, and processes without compromising performance. 2. **High Availability (HA)**: Ensures applications remain operational even if individual servers or components fail. ### **1.7.1 High Availability (HA)** #### **Definition** High Availability refers to the ability of a system to remain operational with minimal downtime, even when failures occur. #### **Key Components of High Availability** 1. **System Clustering** 2. **Redundancy** 3. **Failover Mechanisms** #### **1. System Clustering** A **cluster** in Pega consists of multiple **nodes** (application servers) working together to handle workloads. If one node fails, others take over to ensure continued operation. - **What is a Node?** - A **node** is a single instance of the Pega application running on a server. - **Cluster Types**: 1. **Horizontal Cluster**: Multiple nodes working in parallel. 2. **Vertical Cluster**: A single node with multiple JVM instances. - **Benefits**: - Distributes workloads across multiple servers. - Reduces risk of a single point of failure. - Increases system resilience and uptime. #### **2. Redundancy** Redundancy ensures that **backup components** are available to replace failed components automatically. - **Examples**: - Duplicate servers to ensure failover. - Replicated databases to maintain data availability. **Real-world Analogy**: Imagine a car with a spare tire. If one tire fails, the spare takes over, ensuring you can continue driving. #### **3. Failover Mechanisms** Failover mechanisms ensure that if one node or component fails, another takes over without interrupting the user experience. - **Examples in Pega**: - If **Node A** fails, the load balancer redirects requests to **Node B**. - If a **queue processor** fails, Pega retries the task on a different node. **Failover Best Practice**: - Always have **health checks** configured to detect node failures automatically. - Use **Load Balancers** to redirect workloads. ### **1.7.2 Load Balancing** #### **What is Load Balancing?** Load balancing distributes user requests evenly across multiple nodes to ensure no single node is overloaded. #### **Load Balancer Features** 1. **Traffic Distribution**: - Distributes requests evenly among all active nodes. 2. **Health Checks**: - Monitors the health of nodes and routes requests only to healthy nodes. 3. **Failover**: - Redirects requests automatically when a node fails. #### **Load Balancing Strategies** 1. **Round Robin**: - Distributes requests sequentially to nodes. - Example: - Request 1 → Node A - Request 2 → Node B - Request 3 → Node C 2. **Least Connections**: - Routes requests to the node with the least active connections. 3. **IP Hash**: - Routes requests from the same user to the same node (useful for session management). #### **Pega and Load Balancing** - Load balancing is critical in Pega for: 1. **Web Requests**: Ensures fast response times for user requests. 2. **Background Processes**: Distributes processing tasks to available nodes. 3. **Service Integrations**: Handles API calls and external service requests. **Best Practice**: Use a load balancer (like **F5**, **AWS ELB**, or **NGINX**) to manage traffic and ensure high availability. ### **1.7.3 Scalability** Scalability refers to the system’s ability to handle increasing workloads without compromising performance. Pega supports two types of scaling: 1. **Horizontal Scaling** 2. **Vertical Scaling** #### **1. Horizontal Scaling** Horizontal scaling involves adding **more nodes** to the cluster to distribute the workload. - **How It Works**: - Each new node can process additional requests, allowing the system to scale out. - **Benefits**: - Reduces the load on individual nodes. - Supports increased traffic and processing demands. - **Example**: - If 3 nodes handle 1,000 users, adding a 4th node allows the system to handle 1,333 users. - **When to Use**: - For applications with rapidly growing user bases or workloads. #### **2. Vertical Scaling** Vertical scaling involves increasing the **resources** (CPU, memory, etc.) of existing nodes. - **How It Works**: - Increase the **RAM**, **CPU power**, or **disk capacity** of an existing server to handle more workload. - **Benefits**: - Simplifies scaling since no additional nodes are needed. - Suitable for applications with single-node bottlenecks. - **Limitations**: - There is a physical limit to how much you can upgrade a server. - **When to Use**: - When workloads are intensive but predictable. ### **Combining Horizontal and Vertical Scaling** In most enterprise environments, **horizontal scaling** and **vertical scaling** are combined to ensure optimal performance and cost-efficiency. - **Example**: - Start with vertical scaling (upgrading resources). - When further scaling is required, add new nodes (horizontal scaling). ### **Scalability Best Practices** 1. **Monitor Performance**: - Use tools like **Pega Predictive Diagnostic Cloud (PDC)** to track performance under load. 2. **Use Load Balancers**: - Implement load balancing to distribute workloads efficiently. 3. **Plan for Growth**: - Design applications to scale horizontally as workloads increase. 4. **Optimize Resources**: - Ensure background jobs and processes (e.g., **queue processors**) are optimized. 5. **Test for Scalability**: - Perform load testing to identify bottlenecks and scale appropriately. ### **Summary of Scalability and High Availability** 1. **High Availability**: - Ensures system uptime with clustering, failover, and redundancy. - Pega supports failover mechanisms and automatic recovery. 2. **Load Balancing**: - Distributes workloads evenly across nodes. - Health checks and failover mechanisms maintain system stability. 3. **Scalability**: - **Horizontal Scaling**: Add more nodes to handle increased workloads. - **Vertical Scaling**: Upgrade server resources for better performance. 4. **Best Practices**: - Combine horizontal and vertical scaling for flexibility. - Use monitoring tools to plan and manage system growth. --- # Pega Platform Design Extended ## **2.1 App Studio** App Studio is one of the primary tools in Pega for building applications using a **low-code development environment**. It is designed for **citizen developers** (business users with minimal coding experience) and professional developers to quickly design, configure, and test applications. ### **Key Features of App Studio** 1. **Low-code Development** 2. **Case Management** 3. **Data Integration** 4. **Collaboration** #### **1. Low-code Development** ##### **What is Low-code Development?** - **Low-code** means building applications using **drag-and-drop** tools, visual interfaces, and pre-built components, reducing the need for manual coding. - In App Studio, you can **configure workflows, user interfaces, and data connections** quickly without writing complex code. ##### **Core Features of Low-code Development in App Studio** 1. **Drag-and-drop Interface** - You can **drag and drop UI components**, processes, and data integrations to design your application. - Example: - Drag a **Text Input** field to create a “Name” input box on a form. - Drag a **Flow** component to add a workflow stage. 2. **Pre-built Templates** - App Studio provides **pre-built templates** for designing user interfaces and workflows. - Example: A template for creating a case management dashboard. 3. **Workflow Automation** - Build **automated workflows** by defining **Stages**, **Steps**, and transitions between them. 4. **Real-time Preview** - Changes to the application can be previewed in real time, allowing you to test immediately. ##### **Example: Building a Loan Application Form** In App Studio, you can design a **loan application form** in three simple steps: 1. **Drag-and-drop UI Components**: - Add a **Text Field** for "Applicant Name" and "Loan Amount". - Add a **Dropdown** for selecting “Loan Type” (e.g., Home Loan, Personal Loan). 2. **Define Workflow**: - Create stages like: - **Stage 1**: Application Submission - **Stage 2**: Document Verification - **Stage 3**: Approval - Add steps under each stage. For example, “Collect Documents” under the **Verification** stage. 3. **Integrate Data**: - Configure a **Data Page** to fetch customer data from a CRM system. #### **Benefits of Low-code Development** - **Faster Development**: Applications are built quickly using visual tools. - **Reduced Complexity**: Non-technical users can contribute to development. - **Flexibility**: Easily make changes without breaking the application. - **Real-time Testing**: Instantly test changes as you design. #### **2. Case Management** **Case Management** is the process of managing and automating workflows to achieve a specific business outcome. In Pega, a **Case** represents a business process or transaction. ##### **Core Concepts of Case Management** 1. **Stages and Steps** - **Stages**: Major milestones in a business process. - **Steps**: Actions performed within each stage. **Example**: For a **Loan Approval Process**: - **Stage 1**: Application Submission - Step: Collect Applicant Information - **Stage 2**: Verification - Step: Verify Documents - **Stage 3**: Approval - Step: Approve/Reject Loan 2. **Service Level Agreements (SLAs)** - SLAs define **deadlines** and **goals** for completing tasks. - Example: “Verify Documents” must be completed within **2 days**. If not, escalate the task to a manager. 3. **Parallel Processing** - Tasks within a case can be performed **simultaneously** rather than sequentially. - Example: “Background Check” and “Credit Score Check” can occur in parallel. 4. **Case Hierarchy** - **Parent Cases**: Represent a high-level process. - **Child Cases**: Break down complex processes into smaller, manageable parts. **Example**: - **Parent Case**: Loan Approval - **Child Cases**: Document Verification, Income Verification #### **Case Management Example** Imagine you are building a **Customer Onboarding Process** for a bank: - **Stage 1**: Collect Customer Information - Step 1: Collect personal details (name, address, contact). - Step 2: Upload ID documents. - **Stage 2**: Verification - Step 1: Verify identity documents. - Step 2: Check for duplicate accounts. - **Stage 3**: Approval - Step 1: Manager reviews the application. - Step 2: Approve or reject onboarding. #### **Benefits of Case Management** - **Structured Workflows**: Simplifies complex processes into manageable stages and steps. - **SLA Management**: Ensures tasks are completed on time with automatic escalation. - **Parallel Processing**: Improves efficiency by allowing tasks to run simultaneously. - **Reusability**: Use templates to design similar processes quickly. #### **3. Data Integration** App Studio allows you to **integrate external systems** into your application to fetch or send data. ##### **What is a Data Page?** - A **Data Page** is a Pega rule used to fetch and store data from external sources or internal systems. - Data Pages reduce the need for multiple database calls by caching data. ##### **Configuring Data Integration in App Studio** 1. **Connect to an External System**: - Use connectors like **REST** or **SOAP** to integrate APIs. - Example: Fetch customer details from a CRM system using a REST API. 2. **Create a Data Page**: - Define a **Data Page** to pull data from the external system. - Example: Fetch “Customer Details” and cache it for the session. 3. **Bind Data to UI**: - Use the fetched data in your user interface. - Example: Display “Customer Name” and “Address” on a form. #### **Example of Data Integration** A bank application integrates with an external **Credit Bureau API** to fetch a customer’s credit score: 1. **Connector**: Use a **REST Connector** to call the Credit Bureau API. 2. **Data Page**: Fetch the credit score and store it in a **Data Page**. 3. **UI**: Display the credit score on the loan application form. #### **4. Collaboration** App Studio provides tools to **improve collaboration** between developers and business stakeholders. - **Commenting**: - Stakeholders can add comments to workflows, forms, or stages for feedback. - Example: “Please add a verification step before approval.” - **Feedback Loops**: - Real-time feedback ensures continuous improvement. - Example: A business analyst tests the form and requests layout changes directly in App Studio. ### **Summary of App Studio** - **Low-code Development**: Build applications quickly with a drag-and-drop interface. - **Case Management**: Design structured workflows with stages, steps, and SLAs. - **Data Integration**: Connect with external systems using Data Pages and connectors. - **Collaboration**: Enable communication between developers and stakeholders using comments and feedback loops. ## **2.2 Prediction Studio** Prediction Studio is a component of the Pega platform used to build, manage, and monitor **AI-driven decision-making**. It enables organizations to provide personalized experiences, automate complex decision-making, and predict outcomes using advanced analytics. ### **Key Capabilities of Prediction Studio** 1. **Next-Best-Action (NBA)** 2. **Decision Strategies** 3. **Prediction Models** 4. **Testing and Monitoring** ### **2.2.1 Next-Best-Action (NBA)** #### **What is Next-Best-Action?** - **Next-Best-Action (NBA)** is Pega’s AI-driven approach to recommending the best action for a specific customer or user at a given moment. - It uses **business rules, real-time data, and machine learning** to identify and deliver personalized decisions. #### **How Does NBA Work?** The NBA process considers three main factors: 1. **Customer Context**: Information about the user (e.g., demographics, behavior, preferences). 2. **Business Objectives**: Organizational goals such as increasing sales, improving service, or reducing churn. 3. **AI Insights**: Predictions made using machine learning models to determine the likelihood of specific outcomes. These inputs are analyzed in real time to recommend the most relevant action. #### **Examples of NBA** 1. **Marketing Example**: - A telecom company uses NBA to recommend personalized offers: - If a customer has a high likelihood of leaving, NBA suggests a **retention discount**. - If a customer has low usage, NBA recommends an **upgrade to a premium plan**. 2. **Customer Service Example**: - In a support center, NBA recommends actions based on the query type: - For a customer asking about a **broken product**, NBA recommends “Schedule Replacement.” - For a customer asking about **bill details**, NBA suggests “Send Email Summary.” 3. **Sales Example**: - In a retail app, NBA can recommend: - “Related Products” based on past purchases. - “Seasonal Discounts” for frequently viewed items. #### **Benefits of Next-Best-Action** 1. **Personalization**: Tailors actions for each user to enhance customer satisfaction. 2. **Improved Decision-making**: Combines data, rules, and AI for smarter decisions. 3. **Real-time Action**: Provides decisions immediately based on current data. 4. **Business Optimization**: Balances customer needs and business goals. ### **2.2.2 Decision Strategies** #### **What is a Decision Strategy?** A **Decision Strategy** in Pega combines business rules, predictive models, and data to automate and optimize decision-making. It is the “brain” behind NBA. #### **Key Components of a Decision Strategy** 1. **Input**: Data about the customer, system, or business. 2. **Business Rules**: Conditions and logic that guide decisions. 3. **Predictive Models**: AI-based models that predict the likelihood of outcomes. 4. **Actions**: Possible options to recommend (e.g., an offer, a message). 5. **Filters**: Criteria to exclude irrelevant options. 6. **Ranking**: Prioritizes actions based on business value or customer relevance. #### **How to Build a Decision Strategy** 1. **Define Inputs**: Identify the data you need (e.g., customer age, purchase history). 2. **Add Predictive Models**: Use AI models to predict customer behavior. 3. **Apply Business Rules**: Add rules to include or exclude certain actions. 4. **Filter Options**: Use filters to remove invalid or irrelevant recommendations. 5. **Rank and Select**: Rank actions based on customer value and likelihood. #### **Example: A Telecom Company’s Decision Strategy** A telecom company wants to increase customer retention and upsell premium plans: - **Inputs**: Customer data (e.g., usage, contract status). - **Predictive Models**: - Model 1: Predict churn likelihood. - Model 2: Predict response to upsell offers. - **Business Rules**: - If churn likelihood > 80%, offer a retention discount. - If usage > 10GB, suggest upgrading to a premium plan. - **Filter**: Exclude customers already on premium plans. - **Rank**: Prioritize actions by potential revenue and customer satisfaction. **Result**: - A customer at risk of leaving gets a **retention discount**. - A high-usage customer gets an **upsell offer**. ### **2.2.3 Prediction Models** Prediction models use machine learning to **predict outcomes** based on historical data. Pega supports different types of prediction models: #### **Types of Prediction Models in Pega** 1. **Adaptive Models** - **What is it?**: A model that learns and improves automatically over time. - **Key Features**: - Learns from real-time customer interactions. - Continuously updates itself as new data comes in. - **Example**: Predicting whether a customer will respond to a special offer. 2. **Scorecards** - **What is it?**: A simple scoring mechanism that assigns points based on input values. - **Example**: - Credit scoring models where income and debt are used to calculate a credit score. 3. **Predictive Models** - **What is it?**: AI models built using historical data to predict future outcomes. - Built in external tools (e.g., R, Python) and imported into Pega. - **Example**: Predicting the likelihood of loan approval based on customer demographics. #### **Example of Adaptive Models** A bank uses an **adaptive model** to predict whether customers will accept a credit card offer: 1. The model analyzes **historical data**: - Age, income, transaction history, and response behavior. 2. When a customer interacts with an offer: - The model **learns** whether the customer accepts or declines. 3. Over time: - The model improves its predictions by analyzing new data. #### **Benefits of Prediction Models** 1. **Improved Accuracy**: Models use real data to make predictions. 2. **Self-learning**: Adaptive models improve over time. 3. **Informed Decisions**: Provides insights to make better business decisions. ### **2.2.4 Testing and Monitoring** Once prediction models and decision strategies are deployed, they must be monitored for performance and accuracy. #### **Key Features of Monitoring in Prediction Studio** 1. **Dashboards**: View model performance metrics, such as accuracy and success rates. 2. **Performance Tracking**: Identify which predictions are successful and which need improvement. 3. **Bias Detection**: Ensure that AI models are fair and free from bias. 4. **Testing Models**: Validate predictions using historical or simulated data. **Example**: A marketing team monitors how well their adaptive model predicts customer responses. If accuracy drops, the team can retrain the model with new data. ### **Summary of Prediction Studio** 1. **Next-Best-Action (NBA)**: Recommends the best action in real time using AI and business rules. 2. **Decision Strategies**: Combines rules, models, and ranking to automate decisions. 3. **Prediction Models**: Uses adaptive, scorecard, and predictive models to forecast outcomes. 4. **Testing and Monitoring**: Ensures predictions are accurate and continuously improving. ## **2.3 Admin Studio** **Admin Studio** is a part of Pega that provides tools for managing the **health, performance, and resources** of Pega applications. It is primarily used by system administrators and developers to monitor nodes, manage background jobs, and resolve performance bottlenecks. ### **Key Capabilities of Admin Studio** 1. **Node Management** 2. **Job Schedulers** 3. **Queue Processors** ### **2.3.1 Node Management** #### **What is a Node?** In Pega, a **node** is a running instance of the Pega platform on a server. Nodes work together in a **cluster** to process user requests, run background tasks, and ensure system performance. #### **Core Features of Node Management** 1. **Start/Stop Nodes and Agents** - Admin Studio allows administrators to **start**, **stop**, or **restart** nodes and agents. - Agents are background processes that perform tasks such as sending notifications, updating records, or archiving data. 2. **Monitor Node Health** - View the real-time health status of each node in the system, including: - **Memory Usage**: How much memory the node is consuming. - **CPU Usage**: The current load on the node’s CPU. - **Active Threads**: How many tasks are being processed simultaneously. 3. **Diagnose Node Issues** - Identify slow nodes, nodes under heavy load, or nodes that are unresponsive. - Resolve issues by: - Restarting nodes. - Offloading tasks to other nodes. #### **How to Monitor Nodes in Admin Studio** 1. Open **Admin Studio**. 2. Navigate to **System** → **Nodes**. 3. View node statistics: - Node ID - Current status (Healthy, Unresponsive) - Memory usage percentage - CPU load percentage 4. Take actions: - Restart the node. - Redirect workloads to healthier nodes. #### **Example of Node Management** Imagine you are running a Pega application across **4 nodes**. - Node 3 suddenly experiences **high memory usage** and starts slowing down. - Using Admin Studio: - You identify that Node 3 is consuming **90% of its memory**. - You decide to **restart** Node 3 and distribute its workloads to Nodes 1, 2, and 4 temporarily. This ensures the application remains responsive while the issue is resolved. #### **Benefits of Node Management** - **Ensures Stability**: Proactively monitor and resolve node issues to prevent failures. - **Improves Performance**: Identify and balance workloads across nodes. - **Reduces Downtime**: Restart problematic nodes without interrupting the entire system. ### **2.3.2 Job Schedulers** #### **What is a Job Scheduler?** A **Job Scheduler** is a Pega background process that performs recurring tasks at scheduled intervals. It is designed to replace legacy agents for better efficiency and reliability. #### **Core Features of Job Schedulers** 1. **Recurring Jobs** - Schedule tasks to run **daily**, **weekly**, or **at specific intervals**. 2. **Execute Background Tasks** - Run resource-intensive tasks without impacting the user interface. - Example tasks include: - Sending nightly email reports. - Archiving completed cases. - Updating database records. 3. **Cluster-Aware Scheduling** - Job Schedulers can run on a **single node** or **across the entire cluster**, ensuring tasks are distributed efficiently. 4. **Monitoring and Logs** - Admin Studio displays: - The last execution time. - The success or failure status of jobs. - Error logs for failed jobs. #### **Steps to Create a Job Scheduler** 1. Open **App Studio** or **Dev Studio**. 2. Create a new **Job Scheduler Rule**. 3. Define: - **Frequency**: (e.g., every 10 minutes, once daily). - **Task**: Specify the activity or job to run. - **Node Configuration**: Choose whether the job runs on one node or across multiple nodes. 4. Monitor the Job Scheduler in **Admin Studio**. #### **Example of a Job Scheduler** **Use Case**: Archiving completed loan applications every night. - **Task**: Move all “Resolved” loan application cases older than 30 days to an archive table. - **Schedule**: Run the job at **2 AM daily**. - **Node Configuration**: Run on a **single node** to avoid conflicts. **Result**: The Job Scheduler runs at 2 AM, processes archived cases, and logs the success status in Admin Studio. #### **Benefits of Job Schedulers** - **Improved Performance**: Tasks are executed in the background without affecting users. - **Reliability**: Jobs run consistently at scheduled times. - **Simplified Management**: Easily monitor job execution and troubleshoot failures. ### **2.3.3 Queue Processors** #### **What is a Queue Processor?** A **Queue Processor** is a Pega component that manages **asynchronous tasks**—tasks that run in the background without requiring immediate results. #### **Core Features of Queue Processors** 1. **Asynchronous Execution** - Processes tasks without blocking the user interface. - Example: Sending an email after a user submits a form. 2. **Scalability** - Queue Processors automatically scale to handle large volumes of tasks. 3. **Retry Mechanism** - If a task fails, Pega automatically retries it based on a configured schedule. 4. **Monitoring and Troubleshooting** - Admin Studio provides visibility into: - **Pending Tasks**: Tasks waiting to be processed. - **Successful Tasks**: Tasks processed successfully. - **Failed Tasks**: Tasks that failed, along with error logs. #### **Types of Queue Processors** 1. **Standard Queue Processors** - Handle tasks such as sending notifications, processing approvals, or updating databases. 2. **Dedicated Queue Processors** - Custom queue processors built for specific tasks or business needs. #### **Example of a Queue Processor** **Use Case**: Sending confirmation emails asynchronously. 1. A customer submits a loan application form. 2. Instead of sending the email immediately (which can slow down the UI), the task is sent to a **Queue Processor**. 3. The Queue Processor sends the email **in the background**. 4. If the email fails to send, the Queue Processor retries the task automatically. #### **Benefits of Queue Processors** - **Improved UI Performance**: Heavy tasks are processed in the background. - **Scalability**: Handles a large number of tasks simultaneously. - **Reliability**: Automatically retries failed tasks. ### **Summary of Admin Studio** 1. **Node Management**: Monitor node health, start/stop nodes, and resolve performance issues. 2. **Job Schedulers**: Automate recurring tasks (e.g., archiving, reporting) at scheduled intervals. 3. **Queue Processors**: Manage asynchronous tasks efficiently in the background. Admin Studio empowers administrators and developers to keep the Pega system healthy, responsive, and optimized. ## **2.4 User Experience Design** User Experience (UX) design is an essential part of building applications in Pega. A well-designed UI ensures that users can interact with the application efficiently, intuitively, and across different devices. Pega simplifies UX design by providing frameworks, templates, and best practices for building modern, responsive, and accessible applications. ### **Key Capabilities of User Experience Design** 1. **Cosmos Design System** 2. **Responsive Design** 3. **Accessibility** ### **2.4.1 Cosmos Design System** #### **What is the Cosmos Design System?** The **Cosmos Design System** is Pega’s modern UX framework that provides a set of **pre-built templates, components, and design principles** for building applications. It is optimized for productivity, consistency, and user experience. #### **Core Features of Cosmos Design System** 1. **Pre-Built Templates** - Cosmos provides reusable **page templates** to speed up UI development. - Examples: - **Dashboard Template**: Pre-built layout for summary dashboards. - **Form Template**: Standard templates for input forms. 2. **Widgets and Components** - Cosmos includes various **widgets** and **UI components** to build interactive UIs, such as: - Buttons - Dropdowns - Date Pickers - Summary Panels 3. **Dynamic UI** - UI components in Cosmos can adapt to user actions and display data dynamically. - Example: A form automatically hides or shows sections based on user input. 4. **Modern, Clean Design** - Cosmos uses clean layouts, a focus on whitespace, and simple navigation for better usability. 5. **Performance Optimization** - UI rendering is optimized for speed to ensure a fast and smooth user experience. #### **Benefits of Using Cosmos Design System** 1. **Faster Development**: Pre-built templates and components reduce development time. 2. **Consistency**: Ensures a standardized look and feel across all applications. 3. **Improved User Experience**: Clean, responsive, and intuitive designs improve user satisfaction. 4. **Maintainability**: Easier to maintain and update UI components. #### **Example of Cosmos Design System** Imagine building a **Customer Service Portal** for a bank: 1. **Dashboard**: Use the **Dashboard Template** to show account balances, recent transactions, and notifications. 2. **Forms**: Use **Form Templates** to create sections for loan applications. Add components like **text fields**, **dropdowns**, and **buttons**. 3. **Dynamic UI**: Show or hide the “Additional Details” section based on user selections (e.g., if they choose “Home Loan,” additional property details appear). ### **2.4.2 Responsive Design** #### **What is Responsive Design?** **Responsive Design** ensures that the application UI works seamlessly across different devices, such as desktops, tablets, and smartphones. #### **How Pega Supports Responsive Design** 1. **Dynamic Layouts** - Pega’s **Dynamic Layouts** automatically adjust the size and positioning of UI components based on the screen size. - Example: - On a desktop: Show two columns side by side. - On a mobile device: Stack the columns vertically for better readability. 2. **Responsive Breakpoints** - Breakpoints define how the UI behaves at specific screen widths. - Common breakpoints: - Desktop: > 1024px - Tablet: 768px–1024px - Mobile: < 768px 3. **Preview Modes** - Pega allows developers to preview the UI for different devices during development. - Example: Test how a loan application form looks on a phone versus a desktop. 4. **Accessibility of Components** - All Pega UI components (like buttons, inputs, and sections) are **responsive by default**. #### **Benefits of Responsive Design** 1. **Multi-Device Compatibility**: Applications work seamlessly on all devices (desktops, tablets, and smartphones). 2. **Improved User Experience**: Optimized layouts ensure users can interact with the app comfortably on smaller screens. 3. **Reduced Development Effort**: Pega’s Dynamic Layouts adapt automatically, reducing the need for custom designs. 4. **Increased Reach**: Applications are accessible to a broader range of users across devices. #### **Example of Responsive Design** Consider a **Loan Application Portal**: 1. **On Desktop**: - The form shows input fields for “Name,” “Address,” and “Loan Amount” side by side. 2. **On Mobile**: - The form stacks input fields vertically to fit the smaller screen. 3. **On Tablet**: - The form might display fields in two narrow columns. By using Pega’s **Dynamic Layouts**, developers achieve this responsiveness without writing any additional code. ### **2.4.3 Accessibility** #### **What is Accessibility?** **Accessibility** ensures that applications are usable by people with disabilities, such as visual, hearing, motor, or cognitive impairments. Pega follows the **Web Content Accessibility Guidelines (WCAG)** standards to make its applications accessible to all users. #### **Key Accessibility Features in Pega** 1. **Keyboard Navigation** - Users can navigate the application using a keyboard (e.g., Tab, Arrow keys). - Example: Pressing “Tab” moves focus between input fields. 2. **Screen Reader Support** - Pega applications are compatible with screen readers (e.g., JAWS, NVDA), which read aloud UI components and instructions. - Example: A screen reader announces “Enter your name in this field” when the user focuses on the “Name” input. 3. **Color Contrast** - Ensures high contrast between text and backgrounds for users with visual impairments. - Example: Black text on a white background or white text on a dark blue background. 4. **ARIA Labels** - Pega allows developers to add **Accessible Rich Internet Applications (ARIA)** labels to components to describe their purpose for assistive technologies. 5. **Customizable Fonts and Sizes** - Users can adjust font size or styles for better readability. #### **Example of Accessibility** In a **Customer Onboarding Form**: 1. **Screen Reader**: - When a user focuses on an “Email Address” field, the screen reader announces: “Enter your email address. This field is required.” 2. **Keyboard Navigation**: - Users can press “Tab” to move to the next input field. 3. **Color Contrast**: - Error messages appear in **bold red text** on a **white background** to ensure visibility. #### **Benefits of Accessibility** 1. **Inclusivity**: Ensures applications are usable by everyone, including people with disabilities. 2. **Compliance**: Meets legal requirements such as WCAG, ADA, and Section 508. 3. **Improved Usability**: Enhances the overall user experience for all users. 4. **Expanded User Base**: Makes applications accessible to a wider audience. ### **Summary of User Experience Design** 1. **Cosmos Design System**: - Modern, clean UI framework with pre-built templates and components for faster development. 2. **Responsive Design**: - Ensures the application works seamlessly on desktops, tablets, and mobile devices using Dynamic Layouts. 3. **Accessibility**: - Supports WCAG standards with features like keyboard navigation, screen readers, and color contrast. ## **2.5 Reuse and Componentization** One of the key advantages of the Pega platform is its ability to promote **reuse** and **componentization**. Instead of creating rules or components from scratch every time, developers can **build once** and **reuse multiple times** across applications. ### **Why Reuse and Componentization Are Important?** 1. **Faster Development**: Reduces the time needed to create similar functionalities. 2. **Consistency**: Ensures uniformity in design and functionality across applications. 3. **Maintainability**: Changes made to a reusable component propagate automatically to all instances. 4. **Reduced Redundancy**: Prevents duplication of code or logic, saving effort and resources. ### **Key Capabilities of Reuse and Componentization** 1. **Reusable Components** 2. **Templates** 3. **Application Reuse** ### **2.5.1 Reusable Components** Reusable components are pieces of functionality or design that can be reused across applications, workflows, or user interfaces. #### **Types of Reusable Components** 1. **Sections** - A **Section** is a UI component that contains fields, buttons, or other layouts. - **Reuse**: Include sections in multiple forms or screens without redesigning them. - Example: A “Customer Address” section can be reused across forms for billing, shipping, or account creation. 2. **Data Transforms** - Data Transforms allow you to manipulate or map data between properties. - **Reuse**: Common data mapping logic can be reused wherever needed. - Example: Mapping “Order Details” data from a requestor to a database table. 3. **Activities** - Activities define procedural logic (e.g., loops, conditions) to execute tasks. - **Reuse**: Use the same activity for similar backend processes. - Example: An activity to validate form fields can be reused for multiple forms. 4. **Decision Rules** - Decision Tables and Decision Trees automate business logic. - **Reuse**: Share decision rules for similar conditions. - Example: A decision table to determine discounts can be reused across products. 5. **Integration Connectors** - Connectors (e.g., REST, SOAP) allow integration with external systems. - **Reuse**: A connector to a **CRM API** can be reused across workflows to fetch customer data. 6. **Queues and Background Processes** - Queue Processors and Job Schedulers for background task management can be shared. #### **Steps to Create Reusable Components** 1. Identify functionality that is common across applications. 2. Build the functionality as a **rule** (e.g., a section, data transform, or connector). 3. Test the rule to ensure it works correctly. 4. Use **RuleSets** and layers (Organization, Division, Framework) to make the rule available for reuse. #### **Example of Reusable Components** **Scenario**: Building a loan application portal. - **Reusable Section**: A “Customer Information” section with fields like Name, Address, and Email can be reused in: - Loan application forms. - Account opening forms. - Profile update screens. - **Reusable Data Transform**: A Data Transform to format customer data for display can be applied across all forms. - **Reusable Integration Connector**: A REST Connector to fetch customer credit scores can be reused across loan approval and credit card applications. ### **2.5.2 Templates** Templates provide pre-configured designs or rules that standardize and accelerate development. #### **Types of Templates in Pega** 1. **Section Templates** - Pre-defined layouts for UI components, such as forms, tables, or dashboards. - **Reuse**: Apply the same template to maintain consistency in design. - Example: A **two-column layout** for forms can be used across different screens. 2. **Case Templates** - Pre-defined templates for case structures, including stages, steps, and workflows. - **Reuse**: Use templates to create new cases with similar processes. - Example: A “Loan Application Case Template” can include stages for Submission, Verification, and Approval. 3. **Report Templates** - Templates for building standard reports, such as summary or list reports. - Example: A **Sales Report Template** to display weekly or monthly sales data. #### **Benefits of Using Templates** 1. **Speed**: Speeds up development by reducing repetitive design work. 2. **Consistency**: Ensures uniformity across applications. 3. **Flexibility**: Templates can be customized to fit specific needs. #### **Example of Templates** **Scenario**: Designing a customer service portal. - Use a **Section Template** for all forms to follow a consistent **two-column layout**. - Use a **Case Template** to standardize workflows for different types of support requests: - “Password Reset” Case - “Account Unlock” Case - “Billing Query” Case ### **2.5.3 Application Reuse** #### **What is Application Reuse?** Application reuse involves sharing parts of an application (such as RuleSets or components) across multiple applications or projects. #### **How to Achieve Application Reuse** 1. **Rule Delegation** - Delegating specific rules (e.g., decision tables or configurations) to business users for reuse or updates. - **Example**: Allowing business analysts to update “Discount Rules” without involving developers. 2. **Componentized Applications** - Build applications as **components** with reusable assets (e.g., workflows, rules, UI). - These components can be shared across multiple projects. 3. **Built-on Applications** - Use one application as a base for another application. - **Example**: A “Loan Processing Framework” application can serve as the foundation for a “Home Loan” and “Car Loan” application. 4. **RuleSets and Libraries** - Store reusable rules and components in specific RuleSets or libraries for use in other applications. #### **Example of Application Reuse** **Scenario**: A bank builds a **Customer Management Framework** application: - This framework includes reusable components like: - A “Customer Profile” workflow. - Integration with a CRM system. - The bank then uses this framework as a **base application** to create: - A “Loan Processing System” for loans. - A “Customer Service Portal” for support. ### **Benefits of Reuse and Componentization** 1. **Increased Development Speed**: Reusing components reduces development effort and accelerates project delivery. 2. **Consistency**: Ensures that the same rules and components are applied across applications. 3. **Simplified Maintenance**: Updates to reusable components automatically apply everywhere they are used. 4. **Cost Efficiency**: Reduces development and testing costs by avoiding duplication. ### **Summary of Reuse and Componentization** 1. **Reusable Components**: Create reusable sections, activities, decision rules, and connectors. 2. **Templates**: Use pre-built section templates, case templates, and report templates for consistency. 3. **Application Reuse**: Share rules and components across multiple applications using frameworks, RuleSets, and rule delegation. ## **2.6 Extending Applications** While Pega provides a comprehensive set of tools and components to build applications, there are scenarios where you need to **extend its capabilities** to meet specific business or technical requirements. This includes: 1. **Integration with Third-Party Systems** 2. **Custom JavaScript and CSS for UI Enhancements** ### **2.6.1 Integration with Third-Party Systems** #### **What is Integration?** Integration involves connecting Pega applications with external systems, databases, or APIs to **exchange data**, trigger actions, or leverage external services. Pega supports various integration options, such as **REST**, **SOAP**, **JDBC**, and **custom connectors**. #### **Why Integrate with Third-Party Systems?** 1. **Data Exchange**: Fetch data from external systems or send data for processing. 2. **External Services**: Use third-party tools for tasks like payments, credit scoring, or notifications. 3. **Legacy System Integration**: Connect to older systems still in use within the enterprise. 4. **Automation**: Enable automation workflows by triggering external services. #### **Common Integration Methods in Pega** 1. **REST Connectors** 2. **SOAP Connectors** 3. **JDBC (Database Integration)** 4. **File Integration** #### **1. REST Connectors** ##### **What is REST?** - REST (Representational State Transfer) is a protocol for exchanging data over HTTP using APIs. - It is widely used for modern integrations due to its simplicity and flexibility. ##### **How REST Connectors Work in Pega**: 1. **Configuration**: Use the **Integration Wizard** in Dev Studio to configure a REST Connector. 2. **Endpoints**: Define the external API’s URL (endpoint). 3. **HTTP Methods**: Specify the HTTP method: - **GET**: Retrieve data (e.g., fetch customer details). - **POST**: Send data to create or update records (e.g., submit an order). - **PUT**: Update existing data. - **DELETE**: Remove data. 4. **Data Mapping**: Map the incoming or outgoing data to Pega’s properties using Data Transforms. ##### **Example: REST Integration** **Scenario**: Fetch customer credit scores from a third-party Credit Bureau API. - **Step 1**: Create a REST Connector with the API endpoint: `https://api.creditbureau.com/creditscore`. - **Step 2**: Configure the request using the **GET** method. - **Step 3**: Map the response (e.g., `creditScore`, `status`) to Pega properties. - **Step 4**: Use the data in the workflow (e.g., approve loans based on credit scores). #### **2. SOAP Connectors** ##### **What is SOAP?** SOAP (Simple Object Access Protocol) is an older protocol for integrating with XML-based web services. It is still widely used in legacy systems. ##### **How SOAP Connectors Work in Pega**: 1. Use the **SOAP Connector Wizard** to connect to an external SOAP-based service. 2. Import the **WSDL (Web Service Definition Language)** file to configure the connection. 3. Define input/output data mappings using Data Transforms. ##### **Example: SOAP Integration** **Scenario**: Submit an insurance claim to an external claims processing system that uses SOAP. - Use a SOAP Connector to send **claim details** in XML format. - Map the response (e.g., claim status) back to Pega properties. #### **3. JDBC (Database Integration)** ##### **What is JDBC?** JDBC (Java Database Connectivity) allows Pega to connect directly to external databases. ##### **How JDBC Works in Pega**: 1. Configure a **Database Table** rule in Pega to define the database connection. 2. Use **Connect SQL** rules to execute custom SQL queries. 3. Map the query results to Pega properties. ##### **Example: JDBC Integration** **Scenario**: Fetch account balances from a bank’s external database. - Create a **Database Table** rule to connect to the bank’s database. - Use a **Connect SQL** rule to run a query: ```sql SELECT balance FROM Accounts WHERE account_id = :accountId; ``` - Map the result (`balance`) to a Pega property. #### **4. File Integration** Pega can process external files, such as **CSV**, **Excel**, or **XML** files, to import or export data. ##### **File Integration Example** **Scenario**: Import a list of customers from a CSV file. 1. Use the **File Listener** to monitor a folder for incoming CSV files. 2. Process the file to extract customer data. 3. Map the data to Pega properties and create cases for each customer. #### **Best Practices for Integration** 1. **Use Data Pages**: Store external data in Data Pages to improve performance. 2. **Error Handling**: Configure retries, timeouts, and error handling for unreliable integrations. 3. **Secure Connections**: Use encryption (e.g., HTTPS) and authentication mechanisms (e.g., OAuth 2.0). 4. **Monitor Integrations**: Use **Admin Studio** to monitor connector performance and failures. ### **2.6.2 Custom JavaScript and CSS** While Pega provides robust tools for building UI, there are scenarios where you may need custom **JavaScript** or **CSS** for additional enhancements. #### **Why Use Custom JavaScript and CSS?** 1. **Enhance UI Functionality**: Add interactive behaviors not available out of the box. 2. **Custom Styling**: Override Pega’s default styles to meet branding requirements. 3. **Integrate External Libraries**: Use third-party libraries (e.g., jQuery, Chart.js) for advanced UI components. #### **Adding Custom JavaScript** 1. **Script Files**: - Create a **Text File** rule to write custom JavaScript. 2. **Attach to a Section**: - Include the script in a section using the **“Script”** field. 3. **Event Listeners**: - Use JavaScript to handle events like clicks or hover actions. #### **Example of Custom JavaScript** **Scenario**: Add a dynamic date picker that disables weekends. - Use a third-party library (e.g., jQuery UI) in a Text File rule: ```javascript $(document).ready(function() { $(".datepicker").datepicker({ beforeShowDay: function(date) { return [date.getDay() !== 0 && date.getDay() !== 6]; } }); }); ``` - Attach the script to a **Date Field** section. #### **Adding Custom CSS** 1. **CSS Files**: - Create a **Text File** rule for custom styles. 2. **Override Styles**: - Use CSS to customize layouts, colors, fonts, or spacing. 3. **Include in UI**: - Reference the CSS file in a **Skin Rule** or section. #### **Example of Custom CSS** **Scenario**: Customize the appearance of a submit button. - Write the following CSS: ```css .custom-submit-button { background-color: #007bff; color: white; font-size: 16px; border-radius: 5px; } ``` - Apply the class **custom-submit-button** to the button. ### **Best Practices for Extending Applications** 1. **Avoid Overuse**: Use custom JavaScript and CSS only when necessary to prevent conflicts with Pega’s UI rules. 2. **Leverage Built-in Features**: Explore Pega’s native capabilities before customizing. 3. **Test Thoroughly**: Test custom scripts and styles across browsers and devices. 4. **Document Customizations**: Maintain clear documentation of all custom code for future reference. ### **Summary of Extending Applications** 1. **Integration with Third-Party Systems**: - Use **REST, SOAP, JDBC**, and file integrations to exchange data or trigger actions. 2. **Custom JavaScript and CSS**: - Enhance UI functionality and appearance using custom scripts and styles. 3. **Best Practices**: - Use Pega’s native capabilities whenever possible. - Test and document all custom code to ensure maintainability. --- # Application Design Application Design in Pega focuses on creating solutions that meet **business needs**, provide **scalable automation**, and ensure **efficient workflows**. A well-designed application aligns technical implementation with business objectives and improves user experience. ## **3.1 Microjourney Design** ### **What is a Microjourney?** A **Microjourney** is a small, focused business process designed to deliver a **specific business outcome**. - Instead of automating a large, complex process all at once, you **break it into smaller, manageable steps**. - Each Microjourney focuses on one **specific user goal** or result. ### **Why Use Microjourneys?** 1. **Focus on Outcomes**: Each Microjourney has a **clear, measurable result**. 2. **Incremental Delivery**: You can build and deploy one Microjourney at a time, enabling faster results. 3. **Easier to Maintain**: Smaller pieces of functionality are easier to test, modify, and reuse. 4. **User-Centric**: Microjourneys align with customer needs and deliver better user experiences. ### **Microjourney Structure** Microjourneys are designed using three key components: 1. **Stages** 2. **Steps** 3. **Processes** #### **1. Stages** - A **Stage** represents a **major milestone** in a Microjourney. - It organizes the overall flow into clear phases. - Stages help both developers and business users visualize the progression of a business process. ##### **Characteristics of Stages**: 1. **Sequential**: Stages typically occur in sequence, but they can also be skipped or returned to if necessary. 2. **High-Level**: Stages provide an overview of what happens without going into technical details. 3. **Outcome-Focused**: Each stage delivers a significant part of the overall business result. **Example: Loan Application Process** Stages in a loan approval process could include: | **Stage** | **Purpose** | | ------------ | ----------------------------------- | | **Initiate** | Capture basic customer information. | | **Review** | Verify submitted documents. | | **Approval** | Approve or reject the application. | | **Closure** | Notify the customer and finalize. | #### **2. Steps** - A **Step** is an action or task that occurs within a stage. - Steps provide detailed activities that move the case forward. - Steps can include: - Assignments: Tasks for users to complete (e.g., “Verify documents”). - Processes: Automated workflows (e.g., sending notifications). - Subprocesses: Smaller workflows within a step. **Example: Steps in the “Review” Stage** In the **Review** stage of a loan application, the steps might include: 1. **Collect Documents**: Gather ID proof, income statements, etc. 2. **Verify Documents**: Ensure all required documents are valid. 3. **Notify Status**: Send an email updating the customer on progress. #### **3. Processes** - A **Process** is an automated workflow that defines how tasks are performed in a step. - Processes can include: - **Sequential Flows**: Tasks happen in a defined order. - **Parallel Flows**: Tasks happen simultaneously. - **Decision Logic**: Rules that control the flow of the process (e.g., “If income > $50,000, approve loan”). **Example: Process for “Verify Documents”** The **Verify Documents** step can include the following automated process: 1. Check if the uploaded documents meet the required format (e.g., PDF, less than 5 MB). 2. Validate information in the documents against the customer’s submitted form. 3. If successful, mark the document as **Verified**. 4. If unsuccessful, send an email to the customer requesting corrections. ### **Best Practices for Microjourney Design** 1. **Keep Stages Simple**: Limit each stage to 5-7 steps to keep processes clear and focused. 2. **Modular Design**: Break large tasks into smaller, reusable processes. 3. **Use Meaningful Names**: Name stages and steps based on their purpose (e.g., “Document Review” instead of “Stage 2”). 4. **Focus on Business Outcomes**: Ensure each Microjourney delivers a specific result (e.g., “Application Approved” or “Customer Onboarded”). 5. **Avoid Overloading Stages**: If a stage has too many steps, consider breaking it into two stages. ### **Real-World Example: Loan Application Microjourney** To summarize, let’s map out a **Loan Application Microjourney**: | **Stage** | **Steps** | **Processes** | | ------------ | ------------------------------------------ | ----------------------------------------- | | **Initiate** | Collect Customer Information | Validate data and store in the system. | | **Review** | Collect Documents → Verify Documents | Automated validation → Send status email. | | **Approval** | Manager Approval → System Decision Check | Approve/reject loan → Notify outcome. | | **Closure** | Notify Customer → Archive Loan Application | Send approval letter → Close the case. | ### **Benefits of Well-Designed Microjourneys** 1. **Faster Development**: Build, test, and deploy small components incrementally. 2. **Clear Visibility**: Business stakeholders can easily understand and approve processes. 3. **Improved User Experience**: Focus on delivering one goal at a time to reduce complexity. 4. **Scalability**: Add more Microjourneys as business needs evolve. ### **Summary of Microjourney Design** - **Microjourneys** are small, focused processes designed to deliver specific business outcomes. - Each Microjourney consists of: - **Stages**: Major milestones. - **Steps**: Actions within stages. - **Processes**: Automated workflows. - Following best practices ensures Microjourneys remain modular, clear, and efficient. ## **3.2 Case Design** In Pega, a **case** represents a business process or transaction that needs to be managed and resolved. **Case Design** is about structuring these cases efficiently so that they align with business objectives and deliver the desired outcomes. ### **Core Components of Case Design** 1. **Case Types** 2. **Parent and Child Cases** 3. **Dynamic Case Management** 4. **SLA Configuration** 5. **Routing and Assignments** 6. **Escalations** ### **3.2.1 Case Types** #### **What is a Case Type?** A **Case Type** in Pega defines the **life cycle of a business process**. It organizes tasks, decisions, and data into a structured process to achieve a specific outcome. #### **Case Type Structure** A case type includes: 1. **Stages**: High-level milestones or phases in the case life cycle. 2. **Steps**: Actions performed within each stage (e.g., forms to fill out, decisions to make). 3. **Processes**: Automation or logic used to execute steps. #### **Examples of Case Types** 1. **Loan Application**: - Purpose: Process a loan request from initiation to approval. - Stages: **Initiation** → **Review** → **Approval** → **Closure**. 2. **Customer Onboarding**: - Purpose: Register a new customer in a bank. - Stages: **Collect Information** → **Document Verification** → **Account Creation**. 3. **Employee Hiring**: - Purpose: Hire new employees in an organization. - Stages: **Application Submission** → **Interview** → **Offer** → **Onboarding**. #### **Benefits of Case Types** 1. **Clear Structure**: Organizes processes into logical stages and steps. 2. **Adaptable**: Easy to modify and extend as business requirements evolve. 3. **Reusable**: Standardized case types can be reused for similar business processes. ### **3.2.2 Parent and Child Cases** #### **What are Parent and Child Cases?** - **Parent Case**: Represents the **main process** or a high-level business objective. - **Child Case**: Breaks the parent case into smaller, manageable parts that can be handled independently. #### **Why Use Parent and Child Cases?** 1. **Manage Complexity**: Large processes can be broken down into smaller, modular components. 2. **Parallel Processing**: Child cases can be worked on simultaneously, improving efficiency. 3. **Reusability**: Child cases can be reused across different parent cases. #### **Example of Parent and Child Cases** **Scenario**: Processing an **Insurance Claim**. | **Parent Case** | **Child Cases** | | ------------------- | ---------------------- | | **Insurance Claim** | 1. Document Collection | | | 2. Damage Assessment | | | 3. Payment Processing | 1. **Document Collection**: Collect required documents from the customer. 2. **Damage Assessment**: Verify the claim by assessing the reported damage. 3. **Payment Processing**: Approve and process the payment. - These child cases can run **in parallel** to reduce processing time. - Once all child cases are resolved, the **Parent Case** can move to completion. #### **Benefits of Parent and Child Cases** 1. **Simplifies Management**: Focus on smaller, manageable parts of the process. 2. **Parallel Execution**: Work on multiple child cases simultaneously to save time. 3. **Error Isolation**: Errors in one child case do not impact others. 4. **Reusability**: Child cases can be reused in other processes. ### **3.2.3 Dynamic Case Management** #### **What is Dynamic Case Management?** Dynamic Case Management allows you to **adjust the workflow** of a case in response to **real-time business changes** or user input. #### **How Does It Work?** 1. **Case Routing**: Dynamically route cases based on conditions (e.g., assign urgent tasks to senior employees). 2. **Optional Actions**: Allow users to perform tasks **outside the standard flow** when needed. 3. **Ad-Hoc Steps**: Add steps or tasks to the case on the fly. #### **Example of Dynamic Case Management** **Scenario**: Handling a **Customer Complaint**. - **Standard Flow**: 1. Receive Complaint → 2. Investigate → 3. Resolve → 4. Notify Customer. - **Dynamic Adjustment**: - If the complaint escalates, add an **Ad-Hoc Step**: “Review by Senior Manager.” - Allow users to perform an **Optional Action**: “Offer a Discount” to resolve the issue quickly. #### **Benefits of Dynamic Case Management** 1. **Flexibility**: Adjust workflows in real time to handle unexpected events. 2. **Improved Responsiveness**: Quickly resolve complex or unpredictable cases. 3. **Enhanced User Control**: Allow caseworkers to add tasks or actions when required. ### **3.2.4 SLA Configuration** #### **What is an SLA?** An **SLA (Service Level Agreement)** defines **deadlines** for task completion and specifies actions to take when those deadlines are missed. #### **Key SLA Components** 1. **Goal**: The expected time to complete a task. 2. **Deadline**: The maximum time allowed to complete a task. 3. **Passed Deadline**: Actions to perform if the deadline is missed. #### **Example of SLA Configuration** **Scenario**: Loan Application Review - **Task**: Verify Loan Documents. - **Goal**: Complete within **4 hours**. - **Deadline**: Complete within **8 hours**. - **Passed Deadline Action**: - Notify the manager via email. - Reassign the task to another user. #### **Benefits of SLAs** 1. **Timely Completion**: Ensures tasks are completed on time. 2. **Escalation Management**: Automates escalation when deadlines are missed. 3. **Improved Accountability**: Tracks task performance and identifies bottlenecks. ### **3.2.5 Routing and Assignments** #### **What is Routing?** Routing determines **who will perform a task** in the case process. #### **Routing Methods** 1. **Work Queue (Workbasket)**: Assign tasks to a shared queue for a group of users. 2. **Specific User**: Route tasks to a specific individual. 3. **Skill-Based Routing**: Route tasks to users with specific skills. 4. **Dynamic Routing**: Use business rules to assign tasks based on conditions. #### **Example of Routing** **Scenario**: Document Verification in Loan Application - Route tasks as follows: - **Standard Loan**: Assign to a junior loan officer. - **High-Value Loan**: Assign to a senior loan officer. **Dynamic Routing**: Use business logic to decide routing dynamically based on loan amount. ### **3.2.6 Escalations** #### **What is Escalation?** Escalation ensures tasks are addressed when SLAs are missed. It can notify stakeholders, reassign tasks, or change priorities. #### **Example of Escalation** **Scenario**: Task: Approve Loan Application - **SLA Missed**: Approval not completed within **8 hours**. - **Escalation Actions**: 1. Notify the manager via email. 2. Reassign the task to the manager. ### **Summary of Case Design** 1. **Case Types**: Define the structure and life cycle of a business process. 2. **Parent and Child Cases**: Break processes into smaller, manageable components. 3. **Dynamic Case Management**: Adjust workflows dynamically for flexibility. 4. **SLA Configuration**: Define goals, deadlines, and escalation actions. 5. **Routing and Assignments**: Assign tasks to users or queues based on rules. 6. **Escalations**: Automate actions when SLAs are missed. ## **3.3 Pega Express Methodology** Pega Express is Pega's **design and delivery methodology** used to implement applications efficiently. It is built on **agile principles** and focuses on delivering incremental value to businesses by identifying and building **Microjourneys**. ### **Key Characteristics of Pega Express** 1. **Outcome-Driven**: Focuses on delivering business outcomes through Microjourneys. 2. **Agile and Iterative**: Work is broken into smaller, manageable phases with continuous feedback. 3. **Minimum Viable Product (MVP)**: Delivers a functional version of the application quickly. 4. **Collaboration**: Involves business stakeholders, developers, and end users throughout the process. ### **Four Stages of Pega Express Methodology** Pega Express consists of **four stages**: 1. **Discover** 2. **Prepare** 3. **Build** 4. **Adopt** ### **3.3.1 Discover** #### **Purpose of the Discover Stage** The **Discover stage** is where you identify business objectives, define the scope, and understand the requirements. This phase focuses on finding the **Microjourneys** that will deliver the most value. #### **Key Activities in the Discover Stage** 1. **Identify Business Outcomes**: - Work with stakeholders to define the specific outcomes the application must achieve. - Example: For a **loan application system**, the outcome could be “Approve loans within 24 hours.” 2. **Define Microjourneys**: - Break down the overall process into smaller, focused Microjourneys. - Example: For a loan system: - Microjourney 1: **Application Submission** - Microjourney 2: **Document Verification** - Microjourney 3: **Approval and Disbursement** 3. **Map Case Life Cycles**: - Outline the **stages** and **steps** for each Microjourney. - Example: - **Stage 1**: Collect Information - **Stage 2**: Review Documents - **Stage 3**: Approve Loan 4. **Understand Personas**: - Identify user roles (personas) that will interact with the application. - Example: - **Loan Officer**: Reviews loan applications. - **Manager**: Approves high-value loans. - **Customer**: Submits loan requests. 5. **Capture Requirements**: - Document business requirements and prioritize them based on importance. #### **Outcome of the Discover Stage** - A clear list of **Microjourneys** to focus on. - A **high-level case design** with stages, steps, and expected outcomes. - Defined **personas** and their roles in the process. - Prioritized **business requirements**. ### **3.3.2 Prepare** #### **Purpose of the Prepare Stage** The **Prepare stage** focuses on planning the implementation. This is where you finalize the **Minimum Viable Product (MVP)**, design the initial case structures, and align on priorities. #### **Key Activities in the Prepare Stage** 1. **Define the MVP (Minimum Viable Product)**: - The MVP is the smallest, functional version of the application that meets key business goals. - Example: For a loan system, the MVP could include: - Customer application submission. - Document collection and verification. 2. **Design Initial Case Structure**: - Build a skeleton of the case type, including: - **Stages**: Major milestones. - **Steps**: Actions within each stage. - Example: - Stage 1: Application Submission - Stage 2: Verification - Stage 3: Approval 3. **Prioritize Features**: - Work with stakeholders to prioritize features for the MVP and future phases. - Focus on delivering **high-value features first**. 4. **Plan the Build**: - Create a plan for development and testing. - Identify key team members and their responsibilities. 5. **Set Up the Development Environment**: - Prepare Pega environments (Development, QA, and Production) for implementation. #### **Outcome of the Prepare Stage** - Defined **MVP** with clear features and priorities. - Initial **case life cycle design**. - Development plan and team alignment. - Prepared environments for the Build phase. ### **3.3.3 Build** #### **Purpose of the Build Stage** The **Build stage** is where the application is developed and tested. It involves creating workflows, automations, user interfaces, and data integrations to meet the requirements. #### **Key Activities in the Build Stage** 1. **Develop the Case Types**: - Create case types with stages, steps, and processes. - Example: Build the **loan application case type** with stages for Submission, Review, and Approval. 2. **Configure UI**: - Design **forms, screens, and dashboards** using Pega’s low-code tools. - Use **Cosmos Design System** for modern, responsive UI components. 3. **Integrate Data**: - Use **Data Pages** and **Connectors** to fetch or send data to external systems. - Example: Integrate with a **Credit Bureau API** to fetch customer credit scores. 4. **Automate Processes**: - Build automation for tasks like email notifications, validations, and decision logic. - Use **Flows** and **Decision Rules** to automate case progression. 5. **Perform Testing**: - Test the application incrementally to ensure it meets requirements. - Perform unit testing, integration testing, and user acceptance testing (UAT). #### **Outcome of the Build Stage** - A functional application that meets the MVP requirements. - Tested case types, workflows, and integrations. - A user-friendly UI with the necessary automation. ### **3.3.4 Adopt** #### **Purpose of the Adopt Stage** The **Adopt stage** focuses on rolling out the application to end users and ensuring successful adoption. This phase also involves gathering feedback for future improvements. #### **Key Activities in the Adopt Stage** 1. **Deploy the Application**: - Move the application to the **Production Environment**. 2. **Train End Users**: - Provide training sessions, documentation, and guides for end users. - Example: Train loan officers to use the loan approval system. 3. **Monitor Adoption**: - Use **Pega Predictive Diagnostic Cloud (PDC)** or performance dashboards to monitor how users interact with the application. 4. **Collect Feedback**: - Gather feedback from end users to identify areas for improvement. - Use this feedback to plan future updates. 5. **Plan for Continuous Improvement**: - Add new features or enhancements based on user needs. #### **Outcome of the Adopt Stage** - A successfully deployed application in production. - Trained and satisfied end users. - Feedback collected for future iterations. - Continuous improvement plan for ongoing development. ### **Summary of Pega Express Methodology** 1. **Discover**: Identify business outcomes, Microjourneys, and case structures. 2. **Prepare**: Define the MVP, prioritize features, and plan the implementation. 3. **Build**: Develop, test, and configure the application incrementally. 4. **Adopt**: Deploy the application, train users, and monitor adoption. ## **3.4 Application Modularity** **Application Modularity** in Pega refers to designing applications in a way that components, rules, and logic are organized into reusable and maintainable units. Modular design reduces duplication, accelerates development, and ensures consistent behavior across applications. ### **Why Application Modularity is Important** 1. **Reusability**: Components can be reused across applications, saving time and effort. 2. **Scalability**: Modular applications are easier to extend as business requirements evolve. 3. **Maintainability**: Changes made to reusable components are automatically applied wherever the component is used. 4. **Reduced Redundancy**: Avoid duplication of logic, rules, and processes. 5. **Improved Collaboration**: Teams can work independently on different modules without conflicts. ### **Key Concepts of Application Modularity** 1. **Application Reuse** 2. **Rule Specialization** 3. **Examples of Modular Components** ### **3.4.1 Application Reuse** #### **What is Application Reuse?** Application reuse involves designing applications so that parts of the application (e.g., rules, workflows, components) can be reused in other applications or projects. #### **How to Enable Application Reuse in Pega** 1. **Break Applications into Modules**: - Divide applications into reusable components, such as: - Validation rules - Case templates - User interface sections - Store these components in specific **RuleSets** to enable sharing. 2. **Leverage Rule Inheritance**: - Use Pega’s **Enterprise Class Structure (ECS)** to design layers that support reuse. - Layers include: - **Organization Layer**: Shared across the entire enterprise. - **Division Layer**: Shared within a specific business unit. - **Framework Layer**: Industry-specific reusable assets. - **Implementation Layer**: Custom rules for a specific application. 3. **Built-on Applications**: - Build new applications on top of existing ones, inheriting rules and components. - Example: A **Customer Management Framework** application can serve as a base for multiple solutions, such as loan processing and customer service. 4. **Delegated Rules**: - Allow business users to update specific rules (e.g., decision tables) without developer involvement. #### **Example of Application Reuse** **Scenario**: A bank builds a **Customer Management Framework**. - **Components in the Framework**: - Case Types: Manage customer profiles, account creation. - UI Templates: Standard forms for customer information. - Integration Rules: Connectors to CRM systems. - **Reuse**: - The **Customer Management Framework** is reused as a foundation for: 1. **Loan Processing Application** 2. **Credit Card Application** 3. **Customer Support Portal** This modular approach ensures consistency and accelerates development. ### **3.4.2 Rule Specialization** #### **What is Rule Specialization?** Rule specialization allows you to create **variations of rules** based on specific conditions, such as user roles, regions, or product types, without duplicating the original rule. #### **Types of Rule Specialization** 1. **Circumstancing**: - Create **conditional variations** of a rule based on specific property values. - Example: Apply different discount rules based on customer **region** or **membership level**. **Example Use Case**: - Base Rule: Apply a 10% discount. - Circumstanced Rule: If `Region = Europe`, apply a 15% discount. 2. **Template Overrides**: - Use specialized templates to customize forms or layouts for different use cases. - Example: Override a “Customer Form” for premium customers to include additional fields. 3. **Inheritance**: - Rules in child classes inherit behavior from parent classes but can be **overridden** when needed. - Example: A “Validate Loan Application” rule can have specialized logic for different loan types (e.g., Home Loan, Auto Loan). #### **Benefits of Rule Specialization** 1. **Flexibility**: Customize behavior without changing the base rule. 2. **Maintainability**: Updates to the base rule do not affect specialized versions. 3. **Efficiency**: Avoid duplicating rules for minor variations. #### **Example of Circumstancing** **Scenario**: Discount Calculation Rule 1. **Base Rule**: Apply a **10% discount** to all customers. 2. **Specialized Rule** (Circumstanced): - If `Region = North America`, apply a **12% discount**. - If `Region = Europe`, apply a **15% discount**. With circumstancing, you create targeted behavior without duplicating the entire rule. ### **3.4.3 Examples of Modular Components** Here are some examples of components that can be modularized for reuse: 1. **Validation Rules**: - Rules to validate user inputs (e.g., email format, numeric values). - Example: “Check Email Validity” can be reused across multiple forms. 2. **Case Templates**: - Pre-built templates for case types and life cycles. - Example: A “Customer Onboarding” case template can be reused for loan applications and account creation. 3. **User Interface Sections**: - Reusable UI components for forms and layouts. - Example: A “Customer Address Section” can be reused in billing, shipping, and registration forms. 4. **Decision Tables and Trees**: - Modular rules to automate decision-making logic. - Example: A “Loan Eligibility Decision Table” can be reused across personal loan and auto loan applications. 5. **Data Pages**: - Centralized data sources that fetch and store data from external systems. - Example: A Data Page to fetch customer details can be reused in multiple workflows. ### **Best Practices for Application Modularity** 1. **Identify Reusable Components Early**: During design, identify rules, processes, and UI components that can be reused. 2. **Leverage Inheritance**: Use class inheritance to avoid duplicating rules and templates. 3. **Use Circumstancing for Variations**: Specialize rules for different conditions instead of creating duplicates. 4. **Organize with RuleSets**: Store reusable components in dedicated RuleSets to enable sharing across applications. 5. **Test Reusable Components**: Ensure modular components are well-tested, as changes will affect all applications that use them. ### **Summary of Application Modularity** 1. **Application Reuse**: - Divide applications into reusable modules (e.g., templates, components, and workflows). - Use RuleSets and built-on applications to enable sharing. 2. **Rule Specialization**: - Use **circumstancing** and inheritance to customize rules based on conditions without duplicating logic. 3. **Examples of Modular Components**: - Validation rules, case templates, UI sections, decision tables, and Data Pages. 4. **Best Practices**: - Promote reusability, avoid duplication, and ensure modular components are well-organized and tested. ## **3.5 User Interface Design** User Interface (UI) Design in Pega focuses on creating intuitive, interactive, and visually appealing forms, screens, and navigation structures. A well-designed UI improves **user experience (UX)** and makes applications efficient and easy to use. ### **Key Concepts of UI Design** 1. **Designing User Forms** 2. **Navigation** 3. **Forms and Validation** 4. **Accessibility** ### **3.5.1 Designing User Forms** #### **What is a User Form?** A **form** is a UI component where users interact with the application to input, view, or update information. Pega allows you to design forms using **low-code tools**, such as **Sections** and **Dynamic Layouts**. #### **Core UI Elements in User Forms** 1. **Sections**: - A Section is a container for UI components, such as fields, buttons, and layouts. - Sections allow you to group related fields together and reuse them across the application. - Example: A “Customer Details Section” with fields for Name, Email, and Address. 2. **Dynamic Layouts**: - Dynamic Layouts automatically adjust the positioning of UI elements based on the screen size. - Types of Dynamic Layouts: - **Inline Grid Double**: Two columns side-by-side. - **Stacked Layout**: Fields arranged vertically. - **Inline Flex**: Flexible layouts for responsive design. 3. **Field Types**: - Use appropriate field types to capture user input: - **Text Input**: For single-line text (e.g., Name). - **Dropdown**: For predefined values (e.g., Loan Type: Personal, Home, Auto). - **Radio Buttons**: For single selections. - **Checkboxes**: For multiple selections. - **Date Picker**: For selecting dates. 4. **Buttons and Actions**: - Add buttons like **Submit**, **Cancel**, and **Save** to trigger actions in the workflow. #### **Steps to Create a User Form** 1. Open **App Studio** or **Dev Studio**. 2. Create a **Section Rule** for the form. 3. Add a **Dynamic Layout** to organize fields. 4. Add **fields** (e.g., Text, Dropdown, Date Picker) to capture input. 5. Include **buttons** (e.g., Submit) to progress the workflow. 6. Test the form for responsiveness and usability. #### **Example of a Loan Application Form** **Purpose**: Capture customer details for a loan application. | **Field** | **Field Type** | | ------------------ | ------------------------------- | | Applicant Name | Text Input | | Loan Amount | Numeric Input | | Loan Type | Dropdown (Home, Auto, Personal) | | Email Address | Text Input | | Application Date | Date Picker | | Terms & Conditions | Checkbox | | Submit Button | Button | - Use a **Two-Column Layout** to organize the form neatly. - Add a **Submit Button** to trigger the “Loan Application Submission” process. #### **Best Practices for Designing User Forms** 1. **Keep it Simple**: Avoid clutter by including only relevant fields. 2. **Group Related Fields**: Use sections to group similar fields together. 3. **Use Appropriate Field Types**: Choose fields like dropdowns, checkboxes, or date pickers for better usability. 4. **Make Forms Responsive**: Use Dynamic Layouts to ensure the form works well on all devices (desktop, tablet, mobile). 5. **Test for Errors**: Include **real-time validation** to ensure users input correct data. ### **3.5.2 Navigation** #### **What is Navigation?** Navigation refers to how users move through the application. Well-structured navigation helps users find the information or tasks they need quickly and easily. #### **Core Navigation Features in Pega** 1. **Navigation Menus**: - Provide a top or side menu to allow users to navigate between pages or tasks. - Example: A bank portal with menus like “Dashboard,” “Loan Applications,” and “Customer Support.” 2. **Tabs**: - Use tabs to organize related sections within a single screen. - Example: A user profile screen with tabs for “Personal Info,” “Settings,” and “History.” 3. **Breadcrumbs**: - Display the **path of navigation** so users know where they are in the application. - Example: Home → Loan Application → Submit Documents. 4. **Dynamic Links**: - Allow users to quickly jump to specific tasks or screens. #### **Example of Navigation** **Scenario**: Loan Application Portal Navigation - **Top Menu**: - Dashboard - My Applications - Notifications - **Breadcrumb**: - Home → My Applications → Review Loan Application - **Tabs in “My Applications”**: - Active Applications - Completed Applications - Drafts #### **Best Practices for Navigation** 1. **Keep it Consistent**: Use a uniform navigation structure across the application. 2. **Use Breadcrumbs**: Help users track their navigation path. 3. **Prioritize Accessibility**: Ensure navigation works with keyboard shortcuts. 4. **Minimize Clicks**: Allow users to access tasks in as few clicks as possible. ### **3.5.3 Forms and Validation** #### **What is Validation?** Validation ensures that users provide correct and complete input in forms. It improves data quality and prevents errors. #### **Types of Validation in Pega** 1. **Required Fields**: - Mark fields as mandatory so users cannot submit incomplete forms. - Example: “Email Address” must be filled before submission. 2. **Input Formats**: - Validate formats for fields like email, phone numbers, or dates. - Example: Ensure the “Email Address” contains an `@` symbol. 3. **Real-Time Validation**: - Validate inputs as the user types. - Example: Display an error message if the entered phone number is too short. 4. **Custom Validation Rules**: - Add validation logic using **Edit Validate Rules**. - Example: Validate that the loan amount does not exceed a specified limit. #### **Example of Field Validation** **Field**: Loan Amount - **Validation**: Must be a positive numeric value less than $1,000,000. - **Error Message**: “Loan Amount must be between $1 and $1,000,000.” ### **3.5.4 Accessibility** #### **What is Accessibility?** Accessibility ensures that applications are usable by people with disabilities, following the **Web Content Accessibility Guidelines (WCAG)**. #### **Key Accessibility Features** 1. **Keyboard Navigation**: - Users can navigate forms and menus using the keyboard (e.g., Tab key). 2. **Screen Reader Support**: - Use **ARIA labels** to provide descriptions for screen readers. 3. **Color Contrast**: - Ensure sufficient contrast between text and background for visibility. 4. **Field Labels**: - Provide descriptive labels for form fields. #### **Example of Accessibility** **Scenario**: Customer Registration Form - **Field Label**: “Enter your full name.” - **Screen Reader Support**: Use ARIA tags to describe the field to visually impaired users. - **Keyboard Navigation**: Use the **Tab key** to move between fields. ### **Summary of User Interface Design** 1. **Designing User Forms**: Use sections, dynamic layouts, and appropriate fields to capture user input. 2. **Navigation**: Implement menus, tabs, and breadcrumbs for smooth navigation. 3. **Forms and Validation**: Ensure data quality using required fields, input formats, and real-time validation. 4. **Accessibility**: Follow WCAG guidelines to make applications accessible to all users. ## **3.6 Process Design** **Process Design** in Pega defines how tasks are automated, organized, and executed to achieve a specific business outcome. It involves creating workflows, configuring decision rules, and allowing users to perform optional tasks as needed. ### **Key Concepts in Process Design** 1. **Flows** 2. **Decision Rules** 3. **Optional Actions** ### **3.6.1 Flows** #### **What is a Flow?** A **Flow** in Pega defines the **process steps and transitions** in a case life cycle. It represents the path a case follows, including tasks, decisions, and automated actions. Flows can be **sequential** (tasks occur in order) or **parallel** (tasks occur simultaneously). #### **Types of Flows in Pega** 1. **Starter Flow** - The entry point of a case or process. - Example: Submitting a loan application triggers the starter flow. 2. **Subflow** - A smaller flow that is called within a larger flow to perform specific tasks. - Example: A “Document Verification Flow” runs within the loan review process. 3. **Parallel Flow** - Tasks in a flow can occur **simultaneously**, allowing faster processing. - Example: “Background Check” and “Document Review” can happen at the same time. 4. **Screen Flow** - A flow that displays **multiple screens** in sequence to collect user input. - Example: A multi-step form for submitting a loan application. #### **Flow Components** 1. **Assignment Shapes**: Tasks for users to complete (e.g., “Verify Documents”). 2. **Decision Shapes**: Conditional logic to decide the next step (e.g., “Is Loan Amount > $50,000?”). 3. **Utility Shapes**: Automated actions like sending emails, updating records, or calling APIs. 4. **Subprocess Shapes**: Call another flow within the current flow. 5. **End Shapes**: Mark the completion of a flow. #### **Example: Loan Approval Flow** Here is a simple example of a loan approval flow: 1. **Start**: Customer submits the loan application. 2. **Assignment**: Loan officer reviews the application. 3. **Decision**: Check loan amount: - If **Loan Amount ≤ $50,000** → Approve automatically. - If **Loan Amount > $50,000** → Route to Manager for approval. 4. **Subprocess**: Perform “Document Verification.” 5. **Utility**: Send an email to notify the customer about the loan status. 6. **End**: Close the loan approval process. #### **Best Practices for Flows** 1. **Keep Flows Simple**: Avoid creating complex, tangled flows. Use subflows to organize tasks. 2. **Use Parallel Processing**: Enable parallel tasks to improve efficiency. 3. **Automate Where Possible**: Use Utility shapes for automated tasks like notifications or data updates. 4. **Error Handling**: Include error-handling steps to manage unexpected issues in the flow. 5. **Use Decision Shapes for Logic**: Place business rules in decision shapes for better maintainability. ### **3.6.2 Decision Rules** #### **What are Decision Rules?** **Decision Rules** automate business logic to determine outcomes based on defined conditions. They eliminate the need for manual decision-making in processes. #### **Types of Decision Rules in Pega** 1. **Decision Tables** - A tabular format to define multiple conditions and outcomes. - Example: Determine interest rates based on credit score and loan type. | **Credit Score** | **Loan Type** | **Interest Rate** | | ---------------- | ------------- | ----------------- | | > 750 | Home Loan | 5% | | > 750 | Personal Loan | 7% | | ≤ 750 | Any Loan | 10% | 2. **Decision Trees** - A hierarchical structure to evaluate conditions sequentially. - Example: Approve or reject a loan application based on conditions. - **Conditions**: - If Loan Amount > $100,000 → Route to Manager. - If Credit Score < 650 → Reject Application. 3. **Map Value Rules** - Use a **matrix-style lookup** to map values based on input parameters. - Example: Map delivery charges based on weight and destination zone. 4. **When Rules** - Simple rules that evaluate a single condition. - Example: “When customer is VIP, apply a 10% discount.” #### **Example of Decision Rules** **Scenario**: Approve or Reject Loan Applications. 1. **Decision Table**: - If Credit Score > 700 and Income > $50,000 → Approve. - If Credit Score ≤ 700 → Send to Manager for approval. 2. **Decision Tree**: - If Loan Amount > $100,000 → Route to Senior Manager. - Else → Approve Loan. 3. **When Rule**: - If `LoanType = “Home Loan”` AND `CreditScore > 750`, apply a lower interest rate. #### **Benefits of Decision Rules** 1. **Automation**: Reduces manual decision-making by applying business logic automatically. 2. **Maintainability**: Rules are easy to update and maintain without modifying the process flow. 3. **Reusability**: Decision rules can be reused across different flows and processes. ### **3.6.3 Optional Actions** #### **What are Optional Actions?** Optional Actions allow users to perform tasks **outside the standard process flow**. These actions provide flexibility to handle **exceptions** or additional tasks as needed. #### **Examples of Optional Actions** 1. **Update Case Details**: Allow users to edit case information outside the main flow. 2. **Send Notifications**: Let users send an email or message manually during the case. 3. **Add Supporting Documents**: Provide an option to upload extra files. 4. **Cancel Case**: Allow users to terminate the case if necessary. #### **Benefits of Optional Actions** 1. **Flexibility**: Enables users to handle exceptions or unplanned tasks. 2. **Improved User Control**: Users can perform additional actions as needed without modifying the main flow. 3. **Better User Experience**: Optional actions help resolve issues or adjust the case quickly. #### **Example of Optional Action** **Scenario**: Loan Application Process - Standard Flow: Submit → Verify → Approve → Notify. - Optional Action: During “Verification,” the user can: - **Request Additional Documents**: Ask the customer to upload missing files. - **Cancel Application**: Terminate the application if incorrect data is found. ### **Summary of Process Design** 1. **Flows**: Define the sequence of tasks and automate workflows using shapes like Assignments, Decisions, and Utilities. 2. **Decision Rules**: Use Decision Tables, Trees, and When Rules to automate business logic. 3. **Optional Actions**: Provide flexibility to users by allowing tasks outside the main flow. ### **Application Design Recap** We have now covered all key topics in **Application Design**: 1. **Microjourney Design**: Small, outcome-focused processes. 2. **Case Design**: Structuring case types, parent-child cases, SLAs, and routing. 3. **Pega Express Methodology**: Agile, value-driven development. 4. **Application Modularity**: Promoting reuse and specialization. 5. **User Interface Design**: Designing responsive, accessible, and validated UI. 6. **Process Design**: Automating workflows, decision-making, and enabling optional actions. --- # Application Design Extended ## **4.1 Work Assignment and Routing** In Pega, **Work Assignment and Routing** determine how tasks are assigned to the right users or teams based on predefined logic. Efficient routing ensures that work is processed by the most appropriate resource, improving productivity and meeting SLAs. ### **Key Topics in Work Assignment and Routing** 1. **Routing Strategies** - Skill-Based Routing - Role-Based Routing - Dynamic Routing using Decision Tables or Data Pages 2. **Work Queues (Workbaskets)** 3. **Workload Balancing** ### **4.1.1 Routing Strategies** #### **What is Routing?** Routing is the process of assigning work to users, teams, or queues based on business logic or conditions. Pega provides **several routing strategies** to ensure tasks are delivered to the right individuals or work queues. #### **Types of Routing Strategies** 1. **Skill-Based Routing** 2. **Role-Based Routing** 3. **Dynamic Routing** #### **1. Skill-Based Routing** ##### **Definition** Skill-Based Routing assigns tasks to users based on their **skills** or competencies. This ensures that specialized work is routed to team members with the required expertise. ##### **How It Works** 1. Define skills in Pega for specific users. 2. Tag assignments with the required skill(s). 3. Pega matches users to assignments based on their skills. ##### **Example: IT Support Desk** **Scenario**: Assign support tickets to agents based on their technical skills. | **Agent** | **Skills** | | --------- | ----------------------- | | Alice | Network Troubleshooting | | Bob | Database Support | | Charlie | Software Issues | **Routing Logic**: - Tickets tagged as “Database Issue” are routed to Bob. - Tickets tagged as “Network Issue” are routed to Alice. ##### **Steps to Configure Skill-Based Routing** 1. **Define Skills**: - In Pega, go to **Operator Record** → Add skills (e.g., Network Support, Database Support). 2. **Tag Assignment**: - In the process flow, configure the Assignment Shape → Add required skills for the task. 3. **Route Based on Skills**: - Use **To Skilled User** in the Routing configuration of the assignment. ##### **Benefits of Skill-Based Routing** 1. Ensures tasks are handled by qualified users. 2. Improves work quality and efficiency. 3. Reduces task reassignment due to lack of expertise. #### **2. Role-Based Routing** ##### **Definition** Role-Based Routing assigns tasks to users based on their **roles** or access groups in the organization. ##### **How It Works** 1. Assign users to **roles** (e.g., Manager, Approver, Reviewer). 2. Route work to individuals or groups based on their roles. ##### **Example: Loan Approval Process** **Scenario**: Approve loan applications based on roles. | **Role** | **User** | | ------------- | ---------- | | Loan Reviewer | John, Mary | | Loan Approver | Sarah | **Routing Logic**: - Tasks for “Document Verification” are routed to users with the **Loan Reviewer** role. - Tasks for “Final Approval” are routed to the **Loan Approver** role. ##### **Steps to Configure Role-Based Routing** 1. Assign **Roles**: - Go to **Access Group** → Define roles (e.g., Manager, Approver). 2. Configure Assignment: - In the process flow, use the **Route To** option and specify “Work Group” or “Role.” ##### **Benefits of Role-Based Routing** 1. Simplifies routing for teams with clear roles. 2. Ensures role-specific tasks are assigned correctly. 3. Reduces the risk of task misassignment. #### **3. Dynamic Routing** ##### **Definition** Dynamic Routing determines the task recipient **at runtime** using business logic, decision rules, or data sources. ##### **How It Works** - Pega uses **Decision Tables**, **Decision Trees**, or **Data Pages** to decide the assignment dynamically based on real-time conditions. ##### **Example: Insurance Claim Assignment** **Scenario**: Route insurance claims based on claim type and priority. **Dynamic Logic**: | **Condition** | **Assigned To** | | --------------------------------------- | ------------------ | | Claim Type = “Auto” AND Priority = High | Senior Adjuster | | Claim Type = “Health” | Health Claims Team | | Claim Type = “Auto” | Auto Claims Team | ##### **Steps to Configure Dynamic Routing** 1. **Create Decision Logic**: - Use a **Decision Table** or **Data Page** to define routing conditions. 2. **Reference Logic in Flow**: - In the Assignment Shape, choose **Route To** → Use a Decision Table or Data Page. ##### **Benefits of Dynamic Routing** 1. Provides flexibility to adapt routing based on real-time data. 2. Ensures tasks are routed accurately based on complex conditions. 3. Reduces manual intervention in work assignments. ### **4.1.2 Work Queues (Workbaskets)** #### **What is a Work Queue?** A **Work Queue** (formerly known as Workbasket) is a shared queue where assignments are pooled for a group of users. Team members can pull tasks from the queue based on priority. #### **How Work Queues Work** 1. Assign tasks to a Work Queue instead of a specific user. 2. Team members access the queue and work on tasks based on availability. 3. Pega can **automatically assign tasks** from the queue using workload balancing rules. #### **Example: Customer Support Work Queue** **Scenario**: Route support tickets to a shared **Customer Support Queue**. | **Work Queue** | **Assigned To** | | ----------------------- | ------------------------ | | General Support Queue | Support Team A (3 users) | | Technical Support Queue | Support Team B (2 users) | - All tickets are added to the **General Support Queue**. - Team A members pick tickets from the queue. - If a ticket is marked as “Technical,” it is routed to the **Technical Support Queue**. ##### **Benefits of Work Queues** 1. Improves teamwork by pooling assignments. 2. Ensures tasks are accessible to multiple users. 3. Reduces idle time by allowing team members to pick tasks. ### **4.1.3 Workload Balancing** #### **What is Workload Balancing?** Workload Balancing ensures that tasks are **distributed evenly** among team members to avoid overloading individuals. #### **How It Works** 1. Tasks in a Work Queue can be automatically assigned to users based on: - **Availability**: Assign work to idle users first. - **Workload**: Assign work based on the current number of tasks. 2. Configure **Routing Rules** in Pega to distribute tasks fairly. #### **Example: Claims Processing Team** **Scenario**: Distribute claims processing tasks evenly among team members. | **Team Member** | **Current Task Count** | **Next Assignment** | | --------------- | ---------------------- | ------------------- | | Alice | 2 | Yes | | Bob | 1 | Yes | | Charlie | 4 | No | **Logic**: - Assign tasks to users with the least number of active tasks. ##### **Benefits of Workload Balancing** 1. Ensures fair distribution of tasks. 2. Prevents individual overload and reduces burnout. 3. Improves team efficiency by balancing work evenly. ### **Summary of Work Assignment and Routing** 1. **Routing Strategies**: - **Skill-Based Routing**: Assign tasks based on user skills. - **Role-Based Routing**: Assign tasks based on user roles. - **Dynamic Routing**: Use decision logic or data pages for real-time routing. 2. **Work Queues**: - Pool assignments in shared queues for team-based processing. 3. **Workload Balancing**: - Distribute tasks evenly to improve productivity and prevent overload. ## **4.2 Case Participation and Collaboration** In Pega, **Case Participation** refers to defining roles for users who interact with cases, while **Collaboration** tools allow users to communicate, share information, and track changes efficiently within the case. Together, these features ensure better teamwork, accountability, and visibility across processes. ### **Key Topics in Case Participation and Collaboration** 1. **Case Participants** 2. **Pulse Collaboration** 3. **Case Audit Trail** ### **4.2.1 Case Participants** #### **What are Case Participants?** **Case Participants** are the users or roles involved in processing a case. Each participant has specific permissions and responsibilities depending on their role. #### **Types of Case Participants** 1. **Case Workers**: - Users who perform tasks in a case (e.g., agents, processors). - Example: A “Loan Officer” verifies documents in a loan application. 2. **Case Managers**: - Supervisors who monitor case progress, approve decisions, and manage escalations. - Example: A “Manager” approves loan applications over $50,000. 3. **Reviewers**: - Users who review case information but do not perform tasks. - Example: An auditor reviews approved loans for compliance. 4. **External Users**: - Users outside the organization who interact with the case. - Example: Customers submit applications or documents via a portal. #### **Defining Case Participants** In Pega, you define participants by assigning **roles** to users or work groups. Roles determine what actions a user can perform within the case. ##### **Example: Loan Application Case** | **Role** | **Participant** | **Responsibilities** | | ------------- | ------------------- | ------------------------------------- | | Case Worker | Loan Officer | Collect and verify documents. | | Case Manager | Senior Loan Manager | Approve or reject applications. | | Reviewer | Internal Auditor | Review approved loans for compliance. | | External User | Customer | Submit loan applications. | #### **Steps to Configure Case Participants** 1. **Define Roles**: - Go to **Access Groups** → Create roles (e.g., LoanOfficer, Approver). 2. **Assign Roles to Users**: - Link roles to operator IDs or work groups. 3. **Restrict Access**: - Configure access permissions for each role (e.g., view, update, or approve cases). 4. **Role-Based Routing**: - Use roles to route tasks to the appropriate participants. #### **Benefits of Defining Case Participants** 1. **Clear Responsibilities**: Ensures everyone knows their role and tasks. 2. **Improved Accountability**: Tracks who performed or approved specific actions. 3. **Better Organization**: Roles help organize workflows and prevent unauthorized actions. ### **4.2.2 Pulse Collaboration** #### **What is Pulse?** **Pulse** is Pega’s built-in collaboration tool that allows users to communicate and share information **within a case**. It works like a chat or comment system to facilitate discussions and decisions. #### **Pulse Features** 1. **Contextual Collaboration**: - Comments are attached directly to the case, making it easy to track discussions. 2. **Mentions (@)**: - Use **@mentions** to notify specific users or teams. - Example: `@LoanManager Please review this case.` 3. **File Attachments**: - Attach files, screenshots, or documents to comments. - Example: Attach a customer’s ID proof for reference. 4. **Visibility Settings**: - Control who can see Pulse comments: - Private: Visible only to specific users. - Public: Visible to all case participants. 5. **Notifications**: - Users receive notifications when they are mentioned or when comments are added to cases they follow. #### **Example: Using Pulse in a Loan Application** **Scenario**: A loan officer finds missing information in a customer’s loan application. 1. Loan Officer adds a **Pulse comment**: - `@Customer Please upload your income statement.` 2. Manager adds a note for escalation: - `@LoanManager This application needs urgent review due to missing documents.` 3. Attach files: - The customer uploads the document, and the loan officer attaches it to the case. #### **Benefits of Pulse Collaboration** 1. **Real-Time Communication**: Facilitates quick discussions within the case. 2. **Improved Documentation**: Keeps a record of conversations and decisions. 3. **File Sharing**: Enables easy sharing of supporting documents. 4. **Increased Accountability**: Tracks who made comments or updates. ### **4.2.3 Case Audit Trail** #### **What is the Case Audit Trail?** The **Case Audit Trail** is a chronological record of all user actions, system changes, and updates made to a case. It helps track who did what, when, and why, ensuring accountability and transparency. #### **What Does the Audit Trail Track?** 1. **Assignments**: - Who worked on a task, when it was assigned, and its status. 2. **Updates**: - Changes to case data (e.g., loan amount updated from $20,000 to $25,000). 3. **Approvals**: - Who approved or rejected a task and the reason for their decision. 4. **Comments**: - Pulse comments or notes added by users. 5. **SLAs and Escalations**: - SLA events, missed deadlines, and escalations. #### **Example: Case Audit Trail for a Loan Application** | **Action** | **User** | **Date/Time** | **Details** | | ------------------------------- | ------------ | ------------------- | ------------------------------ | | Case Created | Customer | 2024-06-01 10:00 AM | Loan Amount: $50,000 | | Task Assigned: Verify Documents | Loan Officer | 2024-06-01 11:00 AM | Assigned to John | | Loan Amount Updated | Loan Officer | 2024-06-01 01:00 PM | Loan Amount updated to $55,000 | | Task Approved | Loan Manager | 2024-06-02 09:00 AM | Approved with comments: OK | #### **How to View the Audit Trail** 1. Open the case in the **Case Manager Portal**. 2. Go to the **Audit** tab to see a chronological list of case events. #### **Benefits of the Case Audit Trail** 1. **Accountability**: Tracks all actions for transparency. 2. **Compliance**: Ensures compliance with business and regulatory requirements. 3. **Error Debugging**: Helps identify who made changes or when an issue occurred. 4. **Improved Communication**: Provides visibility into case progress and history. ### **Summary of Case Participation and Collaboration** 1. **Case Participants**: - Define roles (e.g., Case Worker, Manager, Reviewer) and assign responsibilities to users. 2. **Pulse Collaboration**: - Use Pulse for contextual discussions, @mentions, and file sharing within a case. 3. **Case Audit Trail**: - Track all user actions, updates, approvals, and escalations to ensure accountability and transparency. ## **4.3 Advanced Process Handling** Advanced process handling ensures that Pega applications can efficiently manage **complex workflows**, perform **background tasks**, and adapt to changing business conditions. ### **Key Topics in Advanced Process Handling** 1. **Background Processing** - Job Schedulers - Queue Processors 2. **Change Management** - Circumstance Rules 3. **Flows with Sub-Processes** - Subflows - Split-For-Each ### **4.3.1 Background Processing** #### **What is Background Processing?** Background processing enables Pega to perform **automated tasks** behind the scenes without user intervention. It improves performance by offloading non-interactive tasks from the main user flow. #### **Background Processing Tools** 1. **Job Schedulers** 2. **Queue Processors** #### **1. Job Schedulers** ##### **Definition** A **Job Scheduler** is a Pega rule used to schedule **recurring tasks** at specific intervals (e.g., nightly, weekly). It replaces the legacy **Agent** method for scheduled tasks. ##### **When to Use Job Schedulers** - Recurring tasks that need to run at a fixed schedule. - Example: Data archiving, generating daily reports, or nightly database cleanup. ##### **Example: Nightly Data Cleanup** **Scenario**: Archive completed loan applications every night. 1. **Task**: Identify loan cases with status **Resolved-Completed** and archive them. 2. **Schedule**: Run at **2:00 AM daily**. 3. **Implementation Steps**: - Create a **Job Scheduler** rule. - Define the frequency (e.g., daily, weekly). - Configure an **Activity** to perform the task. ##### **Benefits of Job Schedulers** 1. Automates recurring tasks without manual intervention. 2. Improves system performance by running tasks during off-peak hours. 3. Provides centralized management for scheduled tasks. #### **2. Queue Processors** ##### **Definition** A **Queue Processor** handles **asynchronous tasks** by placing them into a queue and processing them in the background. This allows the system to handle large volumes of tasks efficiently. ##### **When to Use Queue Processors** - Tasks that do not require immediate execution. - High-volume processes that need to run in parallel. - Example: Sending email notifications, data synchronization, or processing approvals. ##### **How Queue Processors Work** 1. **Task Added to Queue**: The system or user triggers a task. 2. **Queue Processor Picks Task**: Pega adds the task to a **queue**. 3. **Processing**: The Queue Processor processes tasks in the background. 4. **Retries on Failure**: If a task fails, the Queue Processor retries it automatically. ##### **Example: Sending Notifications** **Scenario**: Send confirmation emails after a loan is approved. 1. When a loan is approved, the system triggers a **Queue Processor**. 2. The task (“Send Email”) is added to the queue. 3. The Queue Processor processes the task: - Sends the email to the customer. 4. If the email fails (e.g., server issue), the Queue Processor retries it after a short delay. ##### **Benefits of Queue Processors** 1. **Improves Performance**: Offloads tasks from the main flow, keeping the UI responsive. 2. **Scalability**: Handles large volumes of tasks efficiently. 3. **Retry Mechanisms**: Automatically retries failed tasks to ensure reliability. ### **4.3.2 Change Management** #### **What is Change Management?** Change Management allows Pega processes to adapt to **changing business conditions** dynamically. It involves using **Circumstance Rules** to apply variations of rules based on specific conditions. #### **Circumstance Rules** ##### **Definition** A **Circumstance Rule** is a specialized version of a rule (e.g., decision table, UI form) that applies under certain conditions. ##### **When to Use Circumstance Rules** - To customize processes for specific conditions without duplicating rules. - Examples of conditions: - Customer type (e.g., VIP vs. Regular). - Product version (e.g., Home Loan vs. Auto Loan). - Region (e.g., North America vs. Europe). ##### **Example: Loan Approval Process** **Scenario**: Adjust approval criteria for VIP customers. 1. **Base Rule**: Loan Approval requires a credit score > 700. 2. **Circumstanced Rule**: If `Customer Type = VIP`, bypass credit score verification. ##### **Steps to Configure Circumstance Rules** 1. Open the **Base Rule** (e.g., Decision Table). 2. Click **Specialize by Circumstance**. 3. Define the condition (e.g., `Customer Type = VIP`). 4. Configure the specialized version of the rule. ##### **Benefits of Circumstance Rules** 1. Allows process customization without duplicating rules. 2. Simplifies maintenance by managing variations centrally. 3. Improves flexibility to adapt to changing business conditions. ### **4.3.3 Flows with Sub-Processes** #### **What are Sub-Processes?** Sub-Processes allow you to break down complex workflows into smaller, reusable flows. They simplify process management and improve modularity. #### **Types of Sub-Processes** 1. **Subflows** 2. **Split-For-Each** #### **1. Subflows** ##### **Definition** A **Subflow** is a smaller flow that is called within a main flow to perform specific tasks. ##### **Example: Loan Verification Flow** **Scenario**: During loan approval, call a **subflow** to verify documents. - **Main Flow**: - Collect Loan Application → Verify Documents → Approve Loan. - **Subflow** (Verify Documents): - Validate ID → Validate Income Statement → Confirm Document Validity. Subflows are reusable and can be invoked in multiple workflows. #### **2. Split-For-Each** ##### **Definition** The **Split-For-Each** shape in Pega allows you to run tasks **in parallel** for a list of items. ##### **Example: Parallel Document Verification** **Scenario**: Verify multiple documents (e.g., ID, income proof, property documents) simultaneously. 1. Add a **Split-For-Each** shape in the flow. 2. Provide the list of documents to process. 3. Tasks run in parallel: - Task 1: Validate ID. - Task 2: Validate Income Proof. - Task 3: Validate Property Documents. #### **Benefits of Sub-Processes and Split-For-Each** 1. Simplifies complex workflows by breaking them into smaller, reusable flows. 2. Improves efficiency with parallel processing. 3. Enhances modularity and reusability of flows. ### **Summary of Advanced Process Handling** 1. **Background Processing**: - Use **Job Schedulers** for recurring tasks (e.g., nightly cleanups). - Use **Queue Processors** for asynchronous, high-volume processing (e.g., sending notifications). 2. **Change Management**: - Use **Circumstance Rules** to adapt processes dynamically based on conditions. 3. **Flows with Sub-Processes**: - Use **Subflows** to simplify workflows. - Use **Split-For-Each** for parallel processing of tasks. ## **4.4 Error Handling and Recovery** **Error Handling and Recovery** in Pega ensures that failures, exceptions, and unexpected issues in workflows or processes are handled gracefully. It minimizes disruptions, improves user experience, and maintains system reliability. ### **Key Topics in Error Handling and Recovery** 1. **Error Handling** - Error Handling Flows - Retry Mechanisms for Transient Failures 2. **Recovery** - Queue Processors with Retry Logic - Logging and Auditing Errors ### **4.4.1 Error Handling** #### **What is Error Handling?** Error Handling involves **detecting, managing, and resolving failures** during process execution. Examples include: - Missing data inputs. - System or network issues (e.g., API failure). - Business rule violations. #### **Error Handling Flows** ##### **Definition** An **Error Handling Flow** redirects a failed process or step to a specialized flow designed to manage the error. ##### **When to Use Error Handling Flows** - To provide users with options when a process fails. - To log errors for debugging and auditing purposes. - To ensure the workflow continues or resolves gracefully after failure. ##### **Example: Loan Approval Failure** **Scenario**: A loan approval step fails due to a **system integration error** with the credit bureau. 1. **Main Flow**: - Collect Application → Verify Credit Score → Approve Loan. 2. **Error Handling Flow**: - If the “Verify Credit Score” step fails: - **Step 1**: Log the error. - **Step 2**: Notify the system administrator via email. - **Step 3**: Provide an option to retry or manually approve the step. ##### **Steps to Configure Error Handling Flows** 1. Identify the step where failures might occur (e.g., an API integration). 2. Add an **Error Flow** to the process step: - Open the **Assignment Shape** → Define an alternate flow for errors. 3. In the Error Flow: - Log the error using a **Utility Shape**. - Send notifications or display corrective actions. #### **Retry Mechanisms for Transient Failures** **Transient Failures** are temporary issues like network glitches or timeouts. Retry mechanisms help ensure that these failures do not disrupt the workflow permanently. ##### **How to Implement Retry Logic** 1. Use **Queue Processors** or **Job Schedulers** to automatically retry failed tasks. 2. Configure **retry intervals** and the maximum retry attempts. 3. Log each retry attempt for debugging purposes. ##### **Example: API Call Retry** **Scenario**: Fetch customer credit score via an external REST API. - If the API call fails due to a timeout: - **Retry** the task up to 3 times with a delay of 5 minutes between retries. - If all retries fail, route the case to an error flow for manual intervention. ### **4.4.2 Recovery** #### **What is Recovery?** Recovery ensures that failed processes or tasks are resumed and completed successfully after the root cause of the failure is resolved. #### **Queue Processors with Retry Logic** **Queue Processors** in Pega automatically manage retry mechanisms for failed tasks, ensuring reliable recovery. ##### **How Queue Processors Handle Failures** 1. **Task Failure**: When a queued task fails, it is marked for retry. 2. **Automatic Retries**: The Queue Processor retries the task based on configured rules. - Example: Retry every 10 minutes, up to 5 times. 3. **Exhausted Retries**: If retries fail, the task is moved to a **broken item queue** for manual resolution. 4. **Recovery**: Once the issue is resolved, the task can be retried manually. ##### **Example: Sending Email Notifications** **Scenario**: A Queue Processor sends confirmation emails after a loan is approved. - **Failure**: Email service is temporarily down. - **Automatic Retry Logic**: - Retry every 5 minutes, up to 3 times. - **Recovery Action**: If all retries fail: - Move the task to the broken queue. - Notify the administrator. #### **Logging and Auditing Errors** Effective logging and auditing are critical for diagnosing and recovering from errors. ##### **What to Log?** 1. **Error Details**: - Error type (e.g., API failure, missing data). - Error message. 2. **Task Information**: - Which task or step failed? - Which user or system triggered the task? 3. **Retry Attempts**: - Number of retries made. - Time of each retry attempt. 4. **Resolution Path**: - Whether the error was resolved automatically or manually. ##### **Example: Logging API Errors** **Scenario**: Logging errors for failed API calls. 1. Create a **Log Message** step in the flow using the **Utility Shape**. 2. Include the following details: - “API Call Failed” - Error Message: “Timeout after 30 seconds.” - Step Name: “Fetch Credit Score.” 3. Store logs in the **Pega System Log** for debugging. ##### **Benefits of Logging and Auditing** 1. Provides visibility into what went wrong and why. 2. Helps developers debug and resolve issues quickly. 3. Tracks trends in errors for proactive monitoring and improvements. ### **Summary of Error Handling and Recovery** 1. **Error Handling**: - Use **Error Flows** to redirect failed processes. - Implement **retry mechanisms** for transient failures. 2. **Recovery**: - Use **Queue Processors** with retry logic to recover failed tasks automatically. - Move permanently failed tasks to the **broken item queue** for manual intervention. 3. **Logging and Auditing**: - Log error details, retry attempts, and resolution steps to enable quick debugging and proactive monitoring. ## **4.5 Background and System Jobs** In Pega, **Background and System Jobs** allow you to automate processes that do not require user interaction. These jobs are essential for handling backend tasks like scheduled cleanups, notifications, or high-volume processing. ### **Key Topics in Background and System Jobs** 1. **Agents** 2. **Job Schedulers** 3. **Queue Processors** 4. **Best Practices for Background Jobs** ### **4.5.1 Agents** #### **What are Agents?** Agents are a **legacy mechanism** in Pega used for automating background tasks. Agents run predefined activities periodically or at scheduled intervals. **Note**: Agents are now considered **legacy**. **Job Schedulers** and **Queue Processors** are the preferred methods in modern applications. #### **Types of Agents** 1. **Standard Agents**: - Process tasks asynchronously at a scheduled interval. - Example: Sending email notifications. 2. **Advanced Agents**: - Provide greater control over task execution. - Example: Updating complex workflows in the backend. #### **Example: Legacy Agent for Data Cleanup** **Scenario**: Archive resolved loan applications every week. 1. Create an **Agent Rule** with a schedule of **weekly** execution. 2. Configure an **Activity** to: - Identify completed loan cases. - Archive them to a database table. #### **Why Move Away from Agents?** 1. Limited flexibility and performance. 2. No built-in retry or failure handling. 3. Modern tools like **Job Schedulers** and **Queue Processors** offer better scalability and reliability. ### **4.5.2 Job Schedulers** #### **What are Job Schedulers?** **Job Schedulers** are modern replacements for agents in Pega. They allow you to schedule and run recurring tasks efficiently. Job Schedulers are **cluster-aware**, meaning they work seamlessly across multiple nodes. #### **When to Use Job Schedulers** - For **recurring backend tasks** that require a specific schedule. - Examples: - Daily cleanup of old cases. - Generating weekly or monthly reports. - Sending scheduled notifications. #### **Example: Generating Monthly Reports** **Scenario**: Generate a **Monthly Loan Report** for all approved loans. 1. **Create a Job Scheduler Rule**: - Name: **MonthlyLoanReport**. - Frequency: Monthly (1st of every month at 12:00 AM). 2. **Configure the Task**: - Reference an **Activity** to: - Fetch all approved loan records. - Generate the report and save it to a database or file repository. - Send the report via email to stakeholders. #### **Steps to Configure a Job Scheduler** 1. Go to **Records** → **SysAdmin** → **Job Scheduler**. 2. Define the **Execution Schedule** (e.g., daily, weekly, monthly). 3. Configure the **Task Activity**: Write logic to perform the background task. 4. Test the Job Scheduler to ensure it runs as expected. #### **Benefits of Job Schedulers** 1. **Cluster Awareness**: Runs on any available node in the Pega cluster. 2. **Reliability**: Ensures tasks run on schedule without user intervention. 3. **Efficiency**: Handles recurring tasks in a scalable manner. ### **4.5.3 Queue Processors** #### **What are Queue Processors?** **Queue Processors** manage **asynchronous tasks** by placing them in a queue and processing them in the background. They are ideal for handling **large volumes** of work without blocking the main user interface. #### **When to Use Queue Processors** - Tasks that do not require immediate execution. - High-volume, repetitive tasks. - Examples: - Sending email notifications. - Processing payments. - Integrating with external systems (e.g., API calls). #### **How Queue Processors Work** 1. **Add Task to Queue**: Tasks are added to a **queue** during runtime. 2. **Process Task**: The Queue Processor picks tasks from the queue and processes them. 3. **Retries on Failure**: If a task fails, the Queue Processor automatically retries it based on configured rules. #### **Example: Sending Confirmation Emails** **Scenario**: Send confirmation emails after a customer submits a loan application. 1. Add the task (“Send Email”) to the **Queue Processor**. 2. The Queue Processor processes the task asynchronously. 3. If the email server is unavailable: - Retry sending the email up to 3 times, with a 5-minute delay between attempts. #### **Steps to Configure Queue Processors** 1. Create a **Queue Processor Rule**: - Define the task to be processed. 2. Write the **Activity** or logic to perform the task. 3. Add the task to the queue during runtime. #### **Benefits of Queue Processors** 1. **Asynchronous Processing**: Tasks run in the background without impacting user performance. 2. **Automatic Retry**: Failed tasks are retried automatically to ensure completion. 3. **Scalability**: Processes large volumes of tasks efficiently. ### **4.5.4 Best Practices for Background Jobs** To ensure reliability and performance, follow these best practices: 1. **Use Job Schedulers Over Agents**: Job Schedulers are modern, more reliable replacements for legacy Agents. 2. **Avoid Overloading Queues**: Manage the volume of tasks to prevent resource exhaustion. 3. **Use Retry Mechanisms**: Configure automatic retries for transient failures in Queue Processors. 4. **Log Task Execution**: Log successful and failed executions for monitoring and debugging. 5. **Optimize Schedules**: Run intensive tasks during **off-peak hours** to minimize performance impact. 6. **Monitor Background Jobs**: Use **Pega Predictive Diagnostic Cloud (PDC)** or Admin Studio to monitor and troubleshoot jobs. ### **Summary of Background and System Jobs** 1. **Agents**: Legacy method for scheduled tasks (replaced by Job Schedulers). 2. **Job Schedulers**: Run recurring tasks on a schedule, improving reliability and performance. 3. **Queue Processors**: Handle asynchronous tasks with built-in retry logic and scalability. 4. **Best Practices**: Optimize schedules, use retries, and log execution for monitoring. ### **Conclusion of Application Design Extended** We have now completed all topics in **Application Design Extended**: 1. **Work Assignment and Routing**: Skills-based, role-based, and dynamic routing. 2. **Case Participation and Collaboration**: Roles, Pulse collaboration, and audit trails. 3. **Advanced Process Handling**: Background tasks, change management, and sub-process flows. 4. **Error Handling and Recovery**: Error flows, retry logic, and logging. 5. **Background and System Jobs**: Job Schedulers, Queue Processors, and best practices. --- # Data Model Design In Pega, **Data Model Design** refers to defining how data is stored, organized, and accessed within applications. Efficient data models improve application performance, scalability, and maintainability. ## **5.1 Data Relationships** Data relationships define how data elements interact with one another. By designing relationships correctly, you can ensure that data is reliable, organized, and reusable across applications. ### **Key Concepts of Data Relationships** 1. **Single Source of Truth (SSOT)** 2. **Types of Relationships**: - One-to-One - One-to-Many - Many-to-Many ### **5.1.1 Single Source of Truth (SSOT)** #### **What is Single Source of Truth?** The **Single Source of Truth (SSOT)** ensures that all data originates from a single, authoritative source. This principle avoids data duplication and ensures consistency. #### **Why SSOT is Important**: 1. **Data Consistency**: All applications retrieve the same accurate and up-to-date data. 2. **Reduced Redundancy**: Eliminates duplicate data storage. 3. **Simplified Maintenance**: Updates to data occur in one place. #### **Example of Single Source of Truth** **Scenario**: Customer Data Management - A bank needs customer information for **loan processing**, **account creation**, and **support cases**. - Instead of storing duplicate customer data in each process, a **single source (CRM system)** provides the data. **Implementation**: - Create a **Data Page** that fetches customer details from the CRM system. - All applications access this Data Page to retrieve customer data. ### **5.1.2 Types of Relationships** Data relationships determine how records in one data entity (class) relate to records in another data entity. Pega supports the following types of relationships: 1. **One-to-One** 2. **One-to-Many** 3. **Many-to-Many** #### **1. One-to-One Relationship** ##### **Definition** In a **One-to-One** relationship, each record in one data class maps to exactly one record in another data class. ##### **Example: Customer and Address** **Scenario**: Each customer has one primary address. | **Customer Table** | **Address Table** | | ---------------------------------------------- | ---------------------- | | CustomerID: 001 | AddressID: A001 | | Name: John Doe | Street: 123 Elm Street | | Email: [john@email.com](mailto:john@email.com) | City: Springfield | - A **CustomerID** in the **Customer Table** maps to an **AddressID** in the **Address Table**. **Implementation in Pega**: 1. Use **Properties** to define the relationship: - `Address` (Single Page property) stores the address for the customer. 2. Reference the Address Class (e.g., `Data-Address`) as the source. #### **2. One-to-Many Relationship** ##### **Definition** In a **One-to-Many** relationship, a single parent record links to multiple child records. ##### **Example: Customer and Orders** **Scenario**: A customer can place multiple orders. | **Customer Table** | **Order Table** | | ---------------------------------------------- | ------------------------------ | | CustomerID: 001 | OrderID: O001, CustomerID: 001 | | Name: John Doe | OrderID: O002, CustomerID: 001 | | Email: [john@email.com](mailto:john@email.com) | OrderID: O003, CustomerID: 001 | - A single **CustomerID** in the **Customer Table** maps to multiple orders in the **Order Table**. **Implementation in Pega**: 1. Use **Page List Properties** to store multiple child records. - Example: `Orders` (Page List) contains all orders for a customer. 2. Reference the child class (e.g., `Data-Order`) for the Page List property. #### **3. Many-to-Many Relationship** ##### **Definition** In a **Many-to-Many** relationship, multiple records in one class relate to multiple records in another class. This is typically managed using **intermediate tables** or **joins**. ##### **Example: Students and Courses** **Scenario**: Students enroll in multiple courses, and each course can have multiple students. | **Student Table** | **Course Table** | **Enrollment Table** | | ----------------- | ---------------- | ------------------------------- | | StudentID: S001 | CourseID: C101 | StudentID: S001, CourseID: C101 | | Name: Alice | CourseName: Math | StudentID: S001, CourseID: C102 | | | | StudentID: S002, CourseID: C101 | - The **Enrollment Table** acts as an **intermediate table** to connect students and courses. **Implementation in Pega**: 1. Create two parent classes: `Data-Student` and `Data-Course`. 2. Use a **Join Table** class (e.g., `Data-Enrollment`) to store the relationship. 3. Use **Page List Properties** in the parent classes to reference the join table. ### **5.1.3 Summary of Data Relationships** | **Relationship** | **Definition** | **Pega Implementation** | **Example** | | ---------------- | ----------------------------------------------------- | ------------------------- | ------------------ | | **One-to-One** | Each record links to one record in another class. | Single Page Property | Customer → Address | | **One-to-Many** | One parent record links to multiple child records. | Page List Property | Customer → Orders | | **Many-to-Many** | Multiple records in two classes relate to each other. | Join Table and Page Lists | Students ↔ Courses | ### **Best Practices for Data Relationships** 1. **Follow the Single Source of Truth**: Store data in one location and reference it where needed. 2. **Avoid Data Duplication**: Use relationships instead of duplicating data across classes. 3. **Use Page Properties Effectively**: - **Single Page** for one-to-one relationships. - **Page List** for one-to-many relationships. 4. **Normalize Data**: Store data in smaller, related tables to improve performance and scalability. 5. **Document Relationships**: Maintain clear documentation of data relationships to ensure maintainability. ## **5.2 Data Classes and Rule Types** In Pega, **Data Classes** organize data logically, while **Rule Types** (such as properties, data transforms, and data pages) define, manage, and manipulate the data. ### **5.2.1 Data Classes** #### **What are Data Classes?** A **Data Class** is a Pega class used to store, organize, and manage data. It acts as a blueprint for defining **data structure** and **attributes**. #### **Key Characteristics of Data Classes** 1. **Logical Structure**: Defines how data is logically organized. 2. **Reusability**: Data classes can be shared across multiple case types or applications. 3. **Scalability**: Data classes are designed to support large datasets efficiently. 4. **Integration-Friendly**: Data classes can connect to external data sources (e.g., APIs, databases). #### **Types of Data Classes** 1. **System-Defined Classes**: - Predefined Pega classes for out-of-the-box functionality. - Example: `Data-` classes for reusable data structures. 2. **Custom Data Classes**: - User-defined classes to store application-specific data. - Example: `Data-Customer`, `Data-Order`, or `Data-Product`. 3. **Derived Data Classes**: - Inherit properties and behavior from a parent class. #### **Examples of Data Classes** 1. **Data-Customer**: Represents customer information. - Properties: CustomerID, Name, Email, Phone. 2. **Data-Order**: Represents order information. - Properties: OrderID, OrderAmount, OrderDate. 3. **Data-Address**: Represents address details. - Properties: Street, City, State, Zip Code. #### **Steps to Create a Data Class** 1. Go to **App Studio** or **Dev Studio**. 2. Navigate to **Class Explorer** → Add a new class under the appropriate parent. 3. Select **Data-** as the parent class for a custom data class. 4. Define properties for the class (e.g., text, integer, date). #### **Benefits of Data Classes** 1. **Reusable**: A single data class can be used in multiple case types. 2. **Logical Organization**: Keeps data structures clean and organized. 3. **Supports Inheritance**: Allows classes to reuse properties from parent classes. 4. **Enables Integration**: Simplifies fetching and managing data from external systems. ### **5.2.2 Rule Types** Pega provides various **rule types** to define and manage data in a data class. #### **1. Properties** ##### **What are Properties?** **Properties** define the attributes or fields of a data class. Each property represents a specific type of data, such as text, numbers, or dates. ##### **Types of Properties** 1. **Single Value**: Holds a single piece of data. - Example: `Name` (Text), `Age` (Integer). 2. **Page**: Stores a complex data object or single-page structure. - Example: `Address` (Single Page) containing Street, City, State. 3. **Page List**: Stores a list of complex objects. - Example: `Orders` (Page List) containing multiple orders for a customer. 4. **Page Group**: Stores a set of pages grouped under a key. - Example: Multiple addresses for a customer grouped as Home, Office, etc. ##### **Example: Defining Properties for Data-Customer** | **Property Name** | **Type** | **Description** | | ----------------- | ----------- | ------------------------------ | | CustomerID | Integer | Unique identifier for customer | | Name | Text | Customer's full name | | Email | Text | Customer's email address | | Phone | Text | Contact phone number | | Address | Single Page | Reference to Address details | #### **2. Data Pages** ##### **What are Data Pages?** A **Data Page** is a rule that retrieves and caches data for use in applications. It acts as an **abstraction layer** between the application and the data source. ##### **Key Features of Data Pages** 1. **Scope**: Determines who can access the data. - **Thread**: Shared within a single thread (e.g., a single process). - **Requestor**: Shared across the user session. - **Node**: Shared across all users on a server node. 2. **Data Loading**: - **Manual Load**: Data is loaded programmatically using an activity. - **Automatic Load**: Data loads automatically via connectors, reports, or lookups. 3. **Refresh Strategies**: - **Reload if older than**: Reload data after a specified interval. - **Do not reload**: Cached data is reused indefinitely. ##### **Example: Customer Data Page** **Scenario**: Fetch customer data in real time from an external CRM. 1. **Data Page Name**: `D_CustomerData`. 2. **Scope**: Node-level for shared access across users. 3. **Source**: REST Connector to CRM API. 4. **Refresh Strategy**: Reload if older than **30 minutes**. #### **3. Data Transforms** ##### **What are Data Transforms?** **Data Transforms** are rules that allow you to map, manipulate, and transform data between structures or classes. ##### **Key Capabilities of Data Transforms** 1. **Map Data**: Map properties between different classes. 2. **Set Default Values**: Initialize properties with default values. 3. **Manipulate Data**: Perform calculations, concatenations, and conditional logic. ##### **Example: Mapping Data Between Classes** **Scenario**: Map customer data from an external API to the `Data-Customer` class. | **Source Property** | **Target Property** | **Mapping Logic** | | --------------------- | ------------------- | ------------------- | | external_customer_id | CustomerID | Direct mapping | | external_full_name | Name | Direct mapping | | external_email | Email | Direct mapping | | external_phone_number | Phone | Set default if null | ### **Summary of Data Classes and Rule Types** 1. **Data Classes**: Logical structures for storing and managing data. - Example: `Data-Customer`, `Data-Order`, `Data-Address`. 2. **Properties**: Attributes of data (e.g., Single Value, Page, Page List). 3. **Data Pages**: Retrieve and cache data from external or internal sources. 4. **Data Transforms**: Map, manipulate, and initialize data across classes. ## **5.3 Data Pages** A **Data Page** is a rule in Pega that retrieves and caches data for use across the application. It provides an **abstraction layer** for data access, allowing developers to fetch data without worrying about its source or implementation details. ### **Key Concepts of Data Pages** 1. **Definition** 2. **Scopes of Data Pages** 3. **Loading Data** 4. **Refresh Strategies** 5. **Examples** 6. **Best Practices** ### **5.3.1 Definition of a Data Page** A Data Page is a **read-only** data structure that fetches and stores data temporarily for use in an application. It can load data from **external sources** (e.g., REST APIs, databases) or **internal sources** (e.g., reports, case data). #### **Why Use Data Pages?** 1. **Centralized Data Retrieval**: Avoid duplicating logic for fetching data. 2. **Improved Performance**: Use caching to reduce redundant data retrieval operations. 3. **Abstraction Layer**: Decouple data access logic from application processes. 4. **Flexibility**: Fetch data from multiple sources without changing the application flow. ### **5.3.2 Scopes of Data Pages** The **scope** of a Data Page determines its **visibility** and **lifecycle** within the application. Pega provides three scopes: #### **1. Thread Scope** - **Scope**: Data is shared within a single **thread** (e.g., a single case or request). - **Use Case**: When data is specific to a single case, task, or flow. - **Lifecycle**: The Data Page exists as long as the thread is active. **Example**: - Fetch **loan details** for a specific loan case. - The Data Page is visible only within that loan case. #### **2. Requestor Scope** - **Scope**: Data is shared across all threads within a single **user session** (requestor). - **Use Case**: When data is relevant for the entire user session but specific to one user. - **Lifecycle**: The Data Page exists until the user session ends. **Example**: - Fetch the logged-in user’s **profile information** (e.g., name, role, permissions). - The data is available for all cases or flows initiated by the same user during the session. #### **3. Node Scope** - **Scope**: Data is shared across all users and threads on a **server node**. - **Use Case**: When data is **static** or frequently accessed by multiple users. - **Lifecycle**: The Data Page exists as long as the node is running or until the refresh criteria is met. **Example**: - Fetch a **list of available loan products** from a database. - All users accessing the system can reuse the same data without redundant queries. #### **Summary of Scopes** | **Scope** | **Visibility** | **Use Case** | | ------------- | ---------------------------------- | ------------------------------ | | **Thread** | Single thread (case/task-specific) | Loan details for a single case | | **Requestor** | Single user session | Logged-in user profile | | **Node** | All users on a server node | Static product catalogs | ### **5.3.3 Loading Data into a Data Page** Data Pages can load data from various sources. The loading mechanism can be **manual** or **automatic**. #### **Loading Mechanisms** 1. **Manual Load** - Data is loaded programmatically using an **Activity** or **Data Transform**. - Example: Fetch data based on user input during runtime. 2. **Automatic Load** - Data loads automatically from a specified source, such as: - **Connectors**: REST, SOAP, or other integration rules. - **Reports**: Fetch data from internal report definitions. - **Lookups**: Retrieve a specific record from a database table. #### **Example: Automatic Data Page for Customer Data** **Scenario**: Fetch customer data from an external CRM system. | **Configuration** | **Details** | | -------------------- | ------------------------------------ | | **Name** | `D_CustomerDetails` | | **Scope** | Thread | | **Source** | REST Connector to fetch data via API | | **Refresh Strategy** | Reload if older than 30 minutes | #### **Steps to Configure a Data Page** 1. Go to **Records** → **Data Model** → **Data Page**. 2. Define the following: - **Name**: `D_CustomerDetails`. - **Scope**: Thread, Requestor, or Node. - **Structure**: Page (single object) or Page List (list of objects). 3. Select **Source**: Connector, Report Definition, or Lookup. 4. Define **Parameters** (e.g., CustomerID) to pass inputs dynamically. 5. Configure **Refresh Strategy**. ### **5.3.4 Refresh Strategies** The **refresh strategy** determines when the Data Page reloads its data. This is important for ensuring data accuracy and performance. #### **Refresh Options** 1. **Reload if older than**: - Reload the data if it is older than a specified time interval. - Example: Reload every 30 minutes to ensure fresh data. 2. **Do not reload**: - Use cached data indefinitely without reloading. - Example: Static data like a product catalog. 3. **Reload per interaction**: - Always reload data for every interaction. - Example: Real-time data like live account balances. #### **Example: Refresh Strategies** | **Scenario** | **Strategy** | | ------------------------- | ------------------------------- | | Fetch customer data (CRM) | Reload if older than 30 minutes | | Static product catalog | Do not reload | | Live stock price data | Reload per interaction | ### **5.3.5 Examples of Data Pages** 1. **Static Data (Node Scope)**: - `D_LoanProducts`: List of loan products fetched from a database. 2. **User-Specific Data (Requestor Scope)**: - `D_UserProfile`: Logged-in user’s profile information. 3. **Case-Specific Data (Thread Scope)**: - `D_LoanDetails`: Loan details for a specific case. ### **5.3.6 Best Practices for Data Pages** 1. **Choose the Correct Scope**: - Use **Thread Scope** for case-specific data. - Use **Node Scope** for shared static data. 2. **Minimize Data Queries**: - Use caching to reduce frequent data retrieval. 3. **Define Clear Refresh Strategies**: - Set a refresh interval to balance data freshness and performance. 4. **Reuse Data Pages**: - Centralize data access logic by creating reusable Data Pages. 5. **Parameterize Data Pages**: - Pass parameters (e.g., CustomerID) to load specific data dynamically. 6. **Monitor Performance**: - Use **Pega Predictive Diagnostic Cloud (PDC)** to monitor Data Page performance and optimize as needed. ### **Summary of Data Pages** 1. **Definition**: A rule that retrieves and caches data for application use. 2. **Scopes**: - Thread: Case-specific. - Requestor: User session-specific. - Node: Shared across users. 3. **Loading Mechanisms**: - Manual or automatic (via connectors, reports, or lookups). 4. **Refresh Strategies**: Define when data should reload. 5. **Best Practices**: Optimize scopes, refresh strategies, and minimize redundant queries. ## **5.4 Data Integration** Data Integration in Pega allows your application to interact with external systems, ensuring real-time access to accurate and up-to-date data. Integrations are essential for enabling seamless communication between Pega and third-party applications, databases, or APIs. ### **Key Concepts in Data Integration** 1. **Integration Options** - REST, SOAP, and Connect SQL 2. **Data Virtualization** 3. **External System Integration** 4. **Examples** ### **5.4.1 Integration Options** Pega provides several integration methods to connect to external data sources, such as APIs, databases, and middleware. These options are implemented using **connectors**. #### **1. Connectors** ##### **What is a Connector?** A **Connector** is a rule in Pega that allows you to interact with external systems to send, receive, or query data. #### **Types of Connectors** 1. **REST Connectors** 2. **SOAP Connectors** 3. **Connect SQL** #### **1. REST Connectors** ##### **Definition** REST (Representational State Transfer) Connectors integrate with **RESTful APIs** to exchange data using HTTP methods such as GET, POST, PUT, and DELETE. ##### **When to Use** - Real-time data exchange with modern web services. - Lightweight and faster communication. ##### **Example: Customer Data Fetch** **Scenario**: Fetch customer data from an external **CRM API**. 1. **API Endpoint**: `https://crm.company.com/api/customers/{CustomerID}` 2. **HTTP Method**: GET 3. **Request Parameter**: CustomerID 4. **Response**: JSON format: ```json { "CustomerID": "001", "Name": "John Doe", "Email": "john@example.com" } ``` ##### **Steps to Configure a REST Connector** 1. Use the **Integration Wizard** in Dev Studio: - Go to **Integration** → **Connectors** → **Create REST Connector**. 2. Provide the following details: - **Endpoint URL**: URL of the REST API. - **HTTP Method**: GET, POST, PUT, DELETE. - **Parameters**: Inputs such as CustomerID. 3. Define the **Data Page** to use the REST Connector as its source. 4. Map the API response to Pega **properties** using a **Data Transform**. #### **2. SOAP Connectors** ##### **Definition** SOAP (Simple Object Access Protocol) Connectors integrate with older, XML-based web services. ##### **When to Use** - Integrations with **legacy systems** using WSDL (Web Service Definition Language). - Complex operations requiring structured data exchanges. ##### **Example: Insurance Policy Service** **Scenario**: Retrieve an insurance policy from a SOAP web service. 1. **WSDL File**: Provided by the external system. 2. **Request**: Input policy ID. 3. **Response**: XML format: ```xml 12345 John Doe 500 ``` ##### **Steps to Configure a SOAP Connector** 1. Use the **Integration Wizard** to import the **WSDL file**. 2. Configure request and response mappings. 3. Test the connection using **SOAP UI** or Pega tools. #### **3. Connect SQL** ##### **Definition** **Connect SQL** allows Pega to execute **SQL queries** on relational databases for data integration. ##### **When to Use** - Direct interaction with relational databases (e.g., Oracle, MySQL). - Fetch or update large volumes of data efficiently. ##### **Example: Fetch Customer Orders** **Scenario**: Retrieve all orders for a specific customer from a relational database. | **SQL Query** | | ------------------------------------------------ | | `SELECT * FROM Orders WHERE CustomerID = '001';` | ##### **Steps to Configure Connect SQL** 1. Create a **Database Table** rule to connect to the external database. 2. Use **Connect SQL** to write SQL queries. 3. Map query results to Pega **properties**. 4. Use the Connect SQL rule as the source for a **Data Page**. ### **5.4.2 Data Virtualization** #### **What is Data Virtualization?** Data Virtualization allows Pega to **fetch data in real time** from external systems without storing it locally in the Pega database. This avoids redundant data storage and ensures the most up-to-date information is always retrieved. #### **When to Use Data Virtualization** 1. When data is frequently updated in an external system. 2. To avoid duplicating large datasets locally. #### **Example: Real-Time Customer Information** - Fetch customer details directly from an external **CRM system** using a REST Connector. - Use a **Node-Level Data Page** to cache the data and refresh periodically. #### **Benefits of Data Virtualization** 1. Reduces data redundancy and storage costs. 2. Ensures data consistency by fetching real-time updates. 3. Improves performance by caching frequently accessed data. ### **5.4.3 External System Integration** Pega integrates with external systems via: 1. **Middleware Tools**: - Kafka, MuleSoft, or IBM MQ for enterprise integrations. 2. **APIs**: - REST and SOAP APIs to interact with systems like CRM, ERP, and payment gateways. 3. **Databases**: - Direct database connections using Connect SQL. #### **Examples of External Integrations** 1. **Fetch Customer Data**: Use a REST Connector to retrieve customer data from Salesforce. 2. **ERP Integration**: Use a SOAP Connector to fetch inventory levels from SAP. 3. **Payment Processing**: Send payment requests to Stripe or PayPal using a REST API. ### **5.4.4 Summary of Data Integration** | **Integration Method** | **Use Case** | **Key Tool** | | ---------------------------- | ---------------------------------- | ----------------------- | | REST Connectors | Integrate with RESTful APIs | REST Connector Rule | | SOAP Connectors | Integrate with legacy systems | SOAP Connector Rule | | Connect SQL | Interact with relational databases | Connect SQL Rule | | Middleware (Kafka, MuleSoft) | Enterprise integrations | Integration Middleware | | Data Virtualization | Real-time external data access | Data Pages + Connectors | ### **Best Practices for Data Integration** 1. **Centralize Data Access**: Use **Data Pages** to fetch and cache external data. 2. **Avoid Redundant Data**: Implement **data virtualization** instead of duplicating data locally. 3. **Monitor Integrations**: Use **Pega Predictive Diagnostic Cloud (PDC)** to monitor connector performance. 4. **Handle Errors Gracefully**: Implement retry mechanisms and error handling for failed integrations. 5. **Secure Integrations**: Use encryption and secure authentication (e.g., OAuth) for external API connections. 6. **Test Integrations Thoroughly**: Use tools like **Postman** or SOAP UI to validate connector behavior. ## **5.5 Data Validation** **Data Validation** in Pega ensures that data entered by users or retrieved from external sources meets specific rules, constraints, and formats. Proper validation prevents errors, enhances data quality, and ensures consistency across the application. ### **Key Topics in Data Validation** 1. **Validation Rules** 2. **Edit Validate and Edit Input Rules** 3. **Declarative Constraints** 4. **Examples** 5. **Best Practices** ### **5.5.1 Validation Rules** #### **What are Validation Rules?** A **Validation Rule** in Pega defines constraints or conditions that data must meet. These rules are applied to ensure user inputs or external data are valid before progressing in the case flow. #### **Types of Validation** 1. **Field-Level Validation**: - Ensures data entered into a field meets the expected format or condition. - Example: An email field must contain `@` and a domain name. 2. **Form-Level Validation**: - Validates multiple fields within a form before submission. - Example: Ensure required fields like **Name** and **Phone** are not empty. 3. **Business Logic Validation**: - Validates data against business rules or complex conditions. - Example: Loan Amount must be less than the customer’s annual income. #### **Example of a Field-Level Validation** **Scenario**: Validate that the "Email Address" field contains a valid email format. | **Property** | **Validation** | **Message** | | ------------ | ----------------------------- | ----------------------------- | | Email | Must match pattern: `*@*.com` | "Please enter a valid email." | **Steps to Configure**: 1. Create a **Validation Rule**. 2. Add a **Field Validation Condition**: Use an expression like `Email contains @ and ends with .com`. 3. Define the **Error Message**. #### **Example of Form-Level Validation** **Scenario**: Validate that all required fields in a loan application form are filled. | **Field** | **Validation** | **Message** | | ------------ | --------------- | ----------------------------- | | Name | Required | "Name cannot be empty." | | Loan Amount | Required | "Loan Amount is required." | | Phone Number | Must be numeric | "Phone Number must be valid." | **Steps to Configure**: 1. Add a **Validation Rule** to the form. 2. Use **Required Fields** and conditions in the rule definition. ### **5.5.2 Edit Validate and Edit Input Rules** #### **1. Edit Validate Rules** **Definition**: An **Edit Validate** rule checks user-entered data against a specific pattern or condition during input. #### **When to Use Edit Validate Rules** - To validate formats for fields like email, phone numbers, or ZIP codes. - To enforce input conditions during user interactions. #### **Example: Validate Phone Number Format** **Scenario**: Ensure the phone number contains exactly 10 digits. 1. Create an **Edit Validate Rule**: - Use a regex pattern: `[0-9]{10}`. 2. Attach the rule to the **Phone Number** property. **Result**: If the user enters a value other than 10 digits, the system displays an error message. #### **2. Edit Input Rules** **Definition**: An **Edit Input** rule automatically reformats user input into a standardized format. #### **When to Use Edit Input Rules** - To clean or format user-entered data before saving it. - Example: Converting phone numbers into a consistent format (e.g., `(123)-456-7890`). #### **Example: Format Phone Number** **Scenario**: Convert the entered phone number `1234567890` to the format `(123)-456-7890`. 1. Create an **Edit Input Rule**: - Logic to reformat the input: ```java return "(" + input.substring(0,3) + ")-" + input.substring(3,6) + "-" + input.substring(6); ``` 2. Attach the rule to the **Phone Number** property. ### **5.5.3 Declarative Constraints** #### **What are Declarative Constraints?** Declarative Constraints in Pega ensure that data meets specific conditions or business rules **automatically** without requiring manual checks. #### **Key Features** 1. **Automatic**: Constraints are triggered whenever relevant properties are updated. 2. **Reusable**: Define a constraint once and reuse it across multiple workflows. 3. **Error Handling**: Display custom error messages when constraints are violated. #### **Example: Validate Loan Amount** **Scenario**: Ensure the **Loan Amount** does not exceed the **Annual Income**. | **Condition** | **Message** | | --------------------------- | ----------------------------------- | | Loan Amount > Annual Income | "Loan Amount cannot exceed income." | **Steps to Configure**: 1. Go to **Records** → **Decision** → **Constraint Rule**. 2. Define the condition: `LoanAmount > AnnualIncome`. 3. Add an **Error Message** for constraint violation. ### **5.5.4 Examples of Data Validation** 1. **Email Field Validation**: - Edit Validate Rule: Ensure email contains `@` and `.com`. 2. **Numeric Validation**: - Field Validation: Phone Number must contain only digits. 3. **Business Rule Validation**: - Declarative Constraint: Loan Amount ≤ Annual Income. 4. **Data Transformation**: - Edit Input Rule: Format phone numbers as `(123)-456-7890`. 5. **Form-Level Validation**: - Validate all required fields in a loan application form. ### **5.5.5 Best Practices for Data Validation** 1. **Centralize Validation Logic**: Use Validation Rules and Edit Validate Rules to centralize checks. 2. **Use Declarative Constraints**: Automatically enforce business rules whenever relevant properties are updated. 3. **Format Inputs with Edit Input**: Standardize user input formats for consistency. 4. **Validate at the Field Level**: Use property validations for critical fields like email, phone, and SSNs. 5. **Avoid Redundancy**: Do not repeat validation logic; reuse rules wherever possible. 6. **Provide Clear Error Messages**: Ensure error messages are user-friendly and descriptive. 7. **Test Thoroughly**: Validate inputs with edge cases (e.g., invalid formats, empty fields). ### **Summary of Data Validation** 1. **Validation Rules**: Define constraints for properties at field or form level. 2. **Edit Validate Rules**: Validate data input against specific formats or patterns. 3. **Edit Input Rules**: Reformat user inputs into a standardized format. 4. **Declarative Constraints**: Automatically enforce conditions on data. 5. **Examples**: - Validate phone number formats. - Ensure Loan Amount ≤ Annual Income. - Format phone numbers consistently. ## **5.6 Performance Optimization** Performance optimization focuses on improving data retrieval, reducing redundant processing, and ensuring efficient database interactions. Proper optimization techniques enhance scalability, responsiveness, and user experience. ### **Key Topics in Performance Optimization** 1. **Efficient Data Retrieval** 2. **Caching Strategies** 3. **Avoiding Redundancy** 4. **Database Indexing** 5. **Examples** 6. **Best Practices** ### **5.6.1 Efficient Data Retrieval** Efficient data retrieval minimizes the number of queries to the database or external systems, thereby reducing response times and improving application performance. #### **Techniques for Efficient Data Retrieval** 1. **Avoid Unnecessary Queries**: - Use **Data Pages** to cache data instead of querying the database repeatedly. - Example: Use a Node-Level Data Page to store static reference data like product catalogs. 2. **Pagination**: - Retrieve and display large datasets in smaller chunks using pagination. - Example: Fetch 20 records at a time instead of all records at once. 3. **Optimize Report Definitions**: - Use **Report Definitions** instead of custom SQL queries where possible. - Only fetch the required columns and apply filters to minimize data retrieval. 4. **Lazy Loading**: - Load data **on demand** instead of preloading it. - Example: Fetch detailed customer data only when the user clicks on the “View Details” button. 5. **Use Declarative Data**: - Leverage **Declarative Expressions** to calculate property values automatically without redundant queries. #### **Example: Optimize Report Definition for Customer Orders** **Scenario**: Display orders for a customer in a dashboard. | **Before Optimization** | **After Optimization** | | ----------------------------------------- | ---------------------------------------------------------------------------- | | Fetch all columns and all orders at once. | Fetch only required columns (OrderID, Date, Total) and filter by CustomerID. | **Optimized Query**: - Use a Report Definition with filters: ```sql SELECT OrderID, OrderDate, OrderTotal FROM Orders WHERE CustomerID = '001' ORDER BY OrderDate DESC LIMIT 20; ``` ### **5.6.2 Caching Strategies** Caching improves performance by reducing the need for frequent data retrieval from databases or external systems. #### **Types of Caching in Data Pages** 1. **Thread-Level Cache**: - Data is cached within a single process/thread. - Use Case: Case-specific or short-lived data (e.g., loan details for a single application). 2. **Requestor-Level Cache**: - Data is cached for the duration of the user session. - Use Case: User-specific data (e.g., logged-in user’s profile). 3. **Node-Level Cache**: - Data is cached at the server node level and shared across users. - Use Case: Static or frequently accessed data (e.g., product catalogs, exchange rates). #### **Refresh Strategies for Caching** 1. **Reload if older than X minutes**: - Reload data after a specified interval. - Example: Refresh product catalogs every 2 hours. 2. **Do not reload**: - Use cached data indefinitely. - Example: Static reference data that rarely changes. 3. **Reload per interaction**: - Reload data every time it is accessed. - Example: Real-time stock prices. #### **Example: Cache Static Product Data** **Scenario**: Fetch product details from a database and cache them for 1 hour. 1. **Data Page Configuration**: - Scope: Node - Refresh Strategy: Reload if older than 1 hour. **Benefit**: The product data is fetched once and shared across all users, reducing database queries. ### **5.6.3 Avoiding Redundancy** Avoid storing duplicate or unnecessary data, as it leads to performance bottlenecks and inconsistency. #### **Techniques to Avoid Redundancy** 1. **Normalization**: - Break data into logical tables to avoid duplication. - Example: Store customer and address details in separate tables and link them using keys. 2. **Use Data Virtualization**: - Fetch real-time data from external systems instead of storing it locally. 3. **Reference Data Pages**: - Centralize data access using **Node-Level Data Pages** for reusable and shared data. ### **5.6.4 Database Indexing** Database indexing improves query performance by enabling faster searches and retrieval of data. #### **What is Indexing?** An **index** is a database structure that allows faster lookup of specific rows in a table. #### **When to Use Indexing** 1. For frequently queried columns. 2. For columns used in **WHERE** clauses, filters, or sorting. 3. For foreign keys and primary keys. #### **Example: Indexing for Customer Lookup** **Scenario**: Frequently query the `CustomerID` field in the **Customer** table. 1. Add an **index** on the `CustomerID` column: ```sql CREATE INDEX idx_customer_id ON Customer (CustomerID); ``` 2. Result: Queries using `WHERE CustomerID = '001'` will run faster. #### **Benefits of Indexing** 1. Reduces query response times. 2. Improves application performance for data-intensive operations. 3. Enhances scalability as data volume grows. ### **5.6.5 Examples of Performance Optimization** 1. **Efficient Queries**: Optimize Report Definitions to fetch only required data. 2. **Node-Level Cache**: Cache frequently accessed product catalogs. 3. **Lazy Loading**: Load detailed customer data only when needed. 4. **Indexing**: Add indexes to frequently queried fields like `CustomerID`. 5. **Avoid Redundancy**: Use normalized data structures and reference Data Pages. ### **5.6.6 Best Practices for Performance Optimization** 1. **Use Node-Level Data Pages**: Cache static or frequently used data to reduce queries. 2. **Optimize Queries**: Fetch only required columns and apply filters efficiently. 3. **Implement Pagination**: Load large datasets in smaller chunks. 4. **Leverage Indexing**: Add indexes on frequently filtered or sorted database fields. 5. **Reduce Redundancy**: Follow normalization principles and use virtualized data. 6. **Monitor Performance**: Use tools like **Pega Predictive Diagnostic Cloud (PDC)** to identify and resolve performance bottlenecks. 7. **Minimize External Calls**: Avoid unnecessary API or database calls by caching results. 8. **Test with Realistic Data**: Simulate production data volumes to evaluate performance. ### **Summary of Performance Optimization** 1. **Efficient Data Retrieval**: Minimize queries, use lazy loading, and optimize reports. 2. **Caching Strategies**: Use Thread, Requestor, or Node-level caches for different use cases. 3. **Avoid Redundancy**: Normalize data and use virtualization for real-time access. 4. **Database Indexing**: Add indexes to improve query performance. 5. **Best Practices**: Optimize queries, leverage caching, and monitor system performance. ### **Conclusion of Data Model Design** We have now covered all the key topics in **Data Model Design**: 1. **Data Relationships**: One-to-One, One-to-Many, and Many-to-Many relationships. 2. **Data Classes and Rule Types**: Organize data with properties, transforms, and Data Pages. 3. **Data Pages**: Centralize and cache data for efficient access. 4. **Data Integration**: Connect external systems via REST, SOAP, and SQL. 5. **Data Validation**: Ensure data integrity with validation rules, Edit Validate, and constraints. 6. **Performance Optimization**: Retrieve data efficiently, use caching, and leverage indexing. --- # Reporting Design Reporting in Pega enables you to retrieve, filter, and visualize application data to extract meaningful insights and support data-driven decisions. Reports help business users analyze case progress, operational performance, and overall application behavior. ## **6.1 Report Definitions** ### **What is a Report Definition?** A **Report Definition** is a rule in Pega that retrieves, filters, and displays application data from the Pega database. It is the foundation of reporting in Pega and provides business users with the ability to generate **list reports** and **summary reports**. ### **Purpose of Report Definitions** 1. Retrieve data from one or more tables in the database. 2. Apply filtering, sorting, and grouping logic to organize data. 3. Display the retrieved data in a **tabular** or **chart** format. 4. Optimize performance using indexing and best practices. ### **6.1.1 Key Features of Report Definitions** 1. **Columns** 2. **Sorting and Grouping** 3. **Filtering** #### **1. Columns** **Definition**: Columns define which **properties** (fields) to include in the report. ##### **Example: Loan Application Report** **Scenario**: Display a list of loan applications with the following details: | **Property** | **Column Header** | | -------------- | ----------------- | | LoanID | Loan ID | | CustomerName | Customer Name | | LoanAmount | Loan Amount | | LoanStatus | Status | | SubmissionDate | Submission Date | **Steps to Add Columns**: 1. Open the **Report Definition** rule. 2. Go to the **Columns** tab. 3. Add the required properties and specify column headers. #### **2. Sorting and Grouping** **Sorting**: Arrange rows in ascending or descending order based on a column. **Grouping**: Combine rows that share the same value into a single group. ##### **Example: Group Loan Applications by Status** **Scenario**: Group loan applications by their status (e.g., Approved, Pending, Rejected) and sort them by submission date. 1. **Group By**: LoanStatus 2. **Sort By**: SubmissionDate (Ascending) | **Loan Status** | **Loan ID** | **Customer Name** | **Submission Date** | | --------------- | ----------- | ----------------- | ------------------- | | Approved | 001 | John Doe | 2024-06-01 | | Approved | 002 | Mary Smith | 2024-06-02 | | Pending | 003 | Alice Johnson | 2024-06-03 | **Steps to Configure Sorting and Grouping**: 1. In the Report Definition rule, go to the **Sorting** tab. 2. Add the property (e.g., SubmissionDate) and set the order (Ascending or Descending). 3. In the **Columns** tab, specify properties for grouping under **Group By**. #### **3. Filtering** **Filtering**: Apply conditions to limit the data retrieved by the report. ##### **Example: Filter Loan Applications Submitted After June 1, 2024** **Condition**: `SubmissionDate >= "2024-06-01"` **Steps to Add Filters**: 1. Go to the **Query Tab** in the Report Definition. 2. Add a filter condition: - Property: `SubmissionDate` - Operator: `>=` - Value: `"2024-06-01"`. ### **6.1.2 Example: Build a Loan Application Report** #### **Scenario**: Generate a report for approved loans submitted after June 1, 2024. **Requirements**: - Display columns: Loan ID, Customer Name, Loan Amount, Status, and Submission Date. - Filter: Status = “Approved” and SubmissionDate >= “2024-06-01”. - Sort: Submission Date in ascending order. #### **Steps to Build the Report** 1. **Create Report Definition**: - Go to **Reports** → **Create Report Definition**. - Name: **ApprovedLoanApplications**. 2. **Add Columns**: - LoanID → Column Header: Loan ID. - CustomerName → Column Header: Customer Name. - LoanAmount → Column Header: Loan Amount. - LoanStatus → Column Header: Status. - SubmissionDate → Column Header: Submission Date. 3. **Add Filters**: - Filter 1: `LoanStatus = "Approved"`. - Filter 2: `SubmissionDate >= "2024-06-01"`. 4. **Add Sorting**: - Property: `SubmissionDate`. - Order: Ascending. 5. **Save and Run**: - Save the rule and run the report to display the filtered and sorted results. #### **Result** | **Loan ID** | **Customer Name** | **Loan Amount** | **Status** | **Submission Date** | | ----------- | ----------------- | --------------- | ---------- | ------------------- | | 001 | John Doe | $50,000 | Approved | 2024-06-01 | | 002 | Mary Smith | $75,000 | Approved | 2024-06-02 | | 004 | Chris Lee | $30,000 | Approved | 2024-06-04 | ### **6.1.3 Optimization Techniques** To ensure that reports run efficiently and perform well, follow these optimization techniques: 1. **Use Indexed Columns**: - Apply database indexes to frequently filtered or sorted columns. - Example: Add an index to `SubmissionDate` for faster filtering. 2. **Limit Data Retrieval**: - Avoid retrieving large datasets by adding filters and pagination. - Example: Fetch only the top 100 records. 3. **Fetch Only Required Columns**: - Include only necessary properties in the report to reduce database load. 4. **Avoid Complex Filters**: - Simplify WHERE clauses to minimize query execution time. 5. **Monitor Report Performance**: - Use **Pega Predictive Diagnostic Cloud (PDC)** to identify and optimize slow-running reports. ### **Summary of Report Definitions** 1. **Purpose**: Retrieve, filter, and display application data. 2. **Key Features**: - **Columns**: Define which properties to display. - **Sorting/Grouping**: Organize and aggregate data. - **Filters**: Limit the retrieved data based on conditions. 3. **Example**: Generate a report for approved loan applications submitted after June 1, 2024. 4. **Optimization**: - Use database indexes. - Fetch only necessary columns. - Add filters to limit data retrieval. ## **6.2 Report Types** Pega provides three main types of reports: 1. **List Reports** 2. **Summary Reports** 3. **Charts** These reports allow business users and developers to present data in both detailed and aggregated formats, including visualizations like charts and graphs. ### **6.2.1 List Reports** #### **What is a List Report?** A **List Report** displays data in a **tabular format**, showing records in rows and columns. It is ideal for presenting detailed, itemized data from the database. #### **Features of List Reports** 1. **Column Selection**: Choose which properties (fields) to display in the table. 2. **Sorting**: Sort rows in ascending or descending order based on a column. 3. **Filtering**: Apply conditions to limit the data displayed. 4. **Pagination**: Display data in smaller chunks for large datasets. #### **Example: Loan Applications List Report** **Scenario**: Display all loan applications with their details. **Fields to Display**: - LoanID - CustomerName - LoanAmount - LoanStatus - SubmissionDate **Filters**: - LoanStatus = “Pending” **Steps to Create the List Report**: 1. Open **App Studio** or **Dev Studio**. 2. Create a new **Report Definition**. 3. Add columns for LoanID, CustomerName, LoanAmount, LoanStatus, and SubmissionDate. 4. Add a filter condition: `LoanStatus = "Pending"`. 5. Configure sorting and enable pagination. 6. Run the report. **Result**: | **Loan ID** | **Customer Name** | **Loan Amount** | **Status** | **Submission Date** | | ----------- | ----------------- | --------------- | ---------- | ------------------- | | 003 | Alice Johnson | $40,000 | Pending | 2024-06-02 | | 005 | Tom Harris | $30,000 | Pending | 2024-06-03 | #### **Use Case for List Reports** - Generate detailed, itemized views of data. - Use in dashboards for displaying case or task records. ### **6.2.2 Summary Reports** #### **What is a Summary Report?** A **Summary Report** aggregates and organizes data using functions like **SUM**, **AVG**, **MIN**, **MAX**, and **COUNT**. It is ideal for analyzing trends and high-level summaries. #### **Features of Summary Reports** 1. **Aggregation Functions**: Perform calculations on numeric data: - **SUM**: Total of a numeric column. - **AVG**: Average value. - **MIN** and **MAX**: Minimum and maximum values. - **COUNT**: Number of records. 2. **Group By**: Group data by a specific field to organize the report. 3. **Drill Down**: Allow users to click on aggregated values to view underlying detailed data. #### **Example: Loan Applications Summary Report** **Scenario**: Summarize total loan amounts grouped by Loan Status. **Fields**: - **Group By**: LoanStatus - **Aggregate Function**: SUM of LoanAmount **Steps to Create the Summary Report**: 1. Open **App Studio** or **Dev Studio**. 2. Create a **Report Definition**. 3. Select **LoanStatus** as the **Group By** field. 4. Add **SUM(LoanAmount)** as the aggregate function. 5. Run the report. **Result**: | **Loan Status** | **Total Loan Amount** | | --------------- | --------------------- | | Approved | $200,000 | | Pending | $70,000 | | Rejected | $50,000 | #### **Use Case for Summary Reports** - Generate high-level business summaries for reporting dashboards. - Analyze trends and aggregated metrics. ### **6.2.3 Charts** #### **What are Charts?** Charts provide a **visual representation** of report data, making it easier to analyze trends, compare values, and gain actionable insights. #### **Types of Charts in Pega** 1. **Bar Chart**: Compare data across categories. - Example: Total loan amounts by loan status. 2. **Line Chart**: Display trends over time. - Example: Monthly loan application submissions. 3. **Pie Chart**: Show proportions as slices of a circle. - Example: Percentage of loan statuses (Approved, Pending, Rejected). 4. **Column Chart**: Similar to bar charts but vertical. - Example: Number of cases by priority. #### **Steps to Add a Chart to a Report** 1. Open the **Report Definition** rule. 2. Go to the **Chart** tab. 3. Select the **Chart Type** (Bar, Line, Pie, etc.). 4. Configure the **X-Axis** (Category) and **Y-Axis** (Values). 5. Save and run the report. #### **Example: Loan Applications Pie Chart** **Scenario**: Visualize the percentage of loan applications by Loan Status. **Chart Type**: Pie Chart - **Group By**: LoanStatus - **Value**: COUNT(LoanID) **Steps**: 1. Create a **Summary Report** grouped by LoanStatus. 2. In the **Chart Tab**, select **Pie Chart**. 3. Configure: - X-Axis: LoanStatus (Category). - Y-Axis: COUNT(LoanID). 4. Save and run the report. **Result**: - **Approved**: 50% - **Pending**: 30% - **Rejected**: 20% A Pie Chart will visually display these proportions as slices. #### **Use Cases for Charts** - Business dashboards for data visualization. - Compare values across categories. - Identify trends, outliers, and proportions. ### **Summary of Report Types** | **Report Type** | **Description** | **Use Case** | | ------------------- | ----------------------------------------------- | -------------------------------------------- | | **List Reports** | Displays detailed, tabular data. | View detailed records (e.g., task list). | | **Summary Reports** | Aggregates data using functions like SUM. | Analyze high-level metrics (e.g., totals). | | **Charts** | Visualizes data using bar, line, or pie charts. | Display trends, comparisons, or proportions. | ## **6.3 Reporting Performance** Efficient reporting is essential to ensure your Pega application performs well and delivers timely results. Poorly designed reports can lead to slow response times, database overload, and a poor user experience. ### **Key Performance Areas for Reporting** 1. **Avoid Large Datasets** 2. **Optimize Report Definitions** 3. **Use Database Indexes** 4. **Declarative Reports for Efficiency** 5. **Monitor and Troubleshoot Reports** ### **6.3.1 Avoid Large Datasets** #### **Why Avoid Large Datasets?** Retrieving excessive rows of data can: - Slow down report execution. - Overload the database and impact application performance. - Make reports difficult for users to analyze. #### **Techniques to Limit Data Retrieval** 1. **Apply Filters**: - Use **WHERE clauses** to fetch only relevant data. - Example: Retrieve only pending or approved loan applications. **Filter Example**: ```sql SELECT * FROM LoanApplications WHERE LoanStatus = 'Approved'; ``` 2. **Pagination**: - Break large datasets into smaller chunks using pagination. - Example: Display 20 rows per page in a loan report. 3. **Limit Results**: - Restrict the number of rows returned using row limits. - Example: Fetch the **top 100 records**. 4. **Fetch Only Required Columns**: - Avoid selecting unnecessary columns in your report. **Optimized Query**: ```sql SELECT LoanID, CustomerName, LoanAmount FROM LoanApplications; ``` #### **Best Practice Example** **Scenario**: Generate a Loan Report for pending loans. - **Filters**: Add LoanStatus = "Pending". - **Row Limit**: Set a maximum of 50 rows. - **Columns**: Display only essential fields (LoanID, CustomerName, LoanAmount, SubmissionDate). ### **6.3.2 Optimize Report Definitions** Report Definitions can be optimized using the following strategies: 1. **Use Indexed Properties**: - Filters should be applied on **indexed columns** to improve database query performance. - Example: Add an index to `SubmissionDate` and `LoanStatus`. 2. **Avoid Computed Columns**: - Avoid applying complex calculations or transformations in the report, as they increase query load. 3. **Minimize Joins**: - Avoid excessive table joins. If possible, flatten data for reports. - Use **Lookup** tables or precomputed aggregates for performance. 4. **Aggregate at the Database**: - Perform data aggregation (SUM, AVG, COUNT) at the database level rather than in the Pega UI. #### **Example: Optimize a Loan Application Report** **Before Optimization**: - Query retrieves all fields and performs client-side sorting. - Result: Slow execution time. **After Optimization**: 1. Use filters on **indexed columns**: `LoanStatus`. 2. Select only required fields: `LoanID, CustomerName, LoanAmount`. 3. Add a row limit of 50. 4. Perform server-side sorting on `SubmissionDate`. ### **6.3.3 Use Database Indexes** #### **What are Database Indexes?** A **database index** improves query performance by enabling faster data retrieval. Without indexes, the database must scan the entire table, which is time-consuming. #### **When to Use Indexes** 1. **Frequently Filtered Columns**: - Columns used in the **WHERE clause** of reports. - Example: LoanStatus, SubmissionDate. 2. **Sorted Columns**: - Columns used for sorting data. 3. **Foreign Keys**: - Columns that link tables together. #### **Steps to Add Indexes** 1. Identify the frequently queried or filtered properties. 2. Use **Pega’s Database Schema Optimization** to add indexes to these columns. 3. Test the report performance before and after applying indexes. #### **Example: Add an Index to SubmissionDate** If a report frequently filters loans by `SubmissionDate`, add an index: ```sql CREATE INDEX idx_submission_date ON LoanApplications (SubmissionDate); ``` ### **6.3.4 Declarative Reports for Efficiency** #### **What are Declarative Reports?** Declarative reports use **Declarative Indexing** to improve performance by precomputing frequently queried data into a separate index table. #### **When to Use Declarative Reports** - For reports that query complex relationships or properties in **embedded pages**. - To avoid the overhead of computing data at runtime. #### **Steps to Configure Declarative Indexing** 1. Enable **Declarative Indexing** for the property. 2. Pega creates a separate index table in the database. 3. Use the index table as the data source for reports. #### **Example: Reporting on Embedded Data** **Scenario**: Generate a report on child cases within parent loan cases. - Use **Declarative Indexing** to store the embedded child case details in a separate table. - Reference the index table in the Report Definition. ### **6.3.5 Monitor and Troubleshoot Reports** Monitoring report execution helps identify bottlenecks and optimize performance. #### **Tools for Monitoring Reports** 1. **Pega Predictive Diagnostic Cloud (PDC)**: - Monitor slow-running reports. - Identify inefficient queries and excessive data retrieval. 2. **Performance Analyzer (PAL)**: - Analyze database interactions and execution times for reports. 3. **Log Files**: - Check logs for query performance issues or errors. #### **Steps to Troubleshoot a Slow Report** 1. Identify the **report execution time** using Pega PDC. 2. Check the **SQL query** generated by the Report Definition. 3. Optimize: - Add filters to limit data. - Use indexed properties. - Simplify joins and computed columns. ### **Summary of Reporting Performance** | **Technique** | **Description** | **Use Case** | | ------------------------------- | --------------------------------------------- | -------------------------------------- | | **Limit Large Datasets** | Fetch only relevant data using filters. | Avoid unnecessary row retrieval. | | **Optimize Report Definitions** | Use indexed columns and minimal columns. | Faster execution of queries. | | **Database Indexes** | Add indexes to frequently queried properties. | Improve filtering and sorting speed. | | **Declarative Reports** | Precompute data into index tables. | Query embedded or complex data faster. | | **Monitoring Tools** | Use PDC and PAL to identify slow reports. | Optimize slow-running reports. | ## **6.4 Business Intelligence Exchange (BIX)** The **Business Intelligence Exchange (BIX)** is a Pega feature that enables the **extraction** of application data for external reporting and analytics tools. BIX allows you to export structured data from the Pega database to external systems in formats like **XML**, **CSV**, or **database tables**. ### **6.4.1 Purpose of BIX** BIX is designed to: 1. **Export Pega Data**: Extract case and data object information for use in external BI tools. 2. **Support External Analytics**: Enable integration with reporting tools like Tableau, Power BI, or SQL-based dashboards. 3. **Enable Historical Analysis**: Store extracted data in external databases for historical and trend analysis. 4. **Scheduled or On-Demand Exports**: Configure BIX to run automatically on a schedule or manually as needed. ### **6.4.2 Key Features of BIX** 1. **Multiple Export Formats**: - CSV: Simple and lightweight format for tools like Excel. - XML: Structured format for integration with other systems. - Database Tables: Export data directly into external relational databases. 2. **Scheduled vs. On-Demand Exports**: - Schedule data extraction jobs to run periodically (e.g., daily, weekly). - Trigger exports manually as needed. 3. **Incremental Extraction**: - Extract only data that has changed since the last export to optimize performance. 4. **Extensive Filtering**: - Apply filters to include only specific records or properties in the export. 5. **Integration with ETL Tools**: - Exported data can be fed into external ETL (Extract, Transform, Load) tools like Talend, Informatica, or middleware solutions. ### **6.4.3 BIX Data Extraction Flow** Here is a step-by-step explanation of how BIX works: 1. **Identify Source Data**: - Select the Pega classes or case types containing the data to extract. 2. **Configure BIX Rules**: - Define an **Extract Rule** to specify: - Properties to export. - Export format (CSV, XML, or Database). - Filters to limit the records. 3. **Export Data**: - Run the BIX Extract Rule manually, or configure it to run on a **schedule**. 4. **Store Data Externally**: - Export data into: - Flat files (CSV/XML). - External databases (via JDBC connections). 5. **Load into Reporting Tools**: - Use tools like Tableau or Power BI to create dashboards and reports using the extracted data. ### **6.4.4 Steps to Configure BIX** #### **1. Create an Extract Rule** 1. Go to **Dev Studio** → **Create** → **SysAdmin** → **Extract Rule**. 2. Configure the following: - **Class**: Specify the data class or case type to extract data from (e.g., `Work-LoanApplication`). - **Properties**: Select the properties (fields) to include in the export. - **Format**: Choose the output format: CSV, XML, or Database Table. - **Filters**: Add conditions to limit the records being exported. #### **2. Specify the Destination** - **For CSV/XML**: Specify a file path or location where the data will be stored. - **For Database**: Configure the target database connection (e.g., Oracle, SQL Server). - Use a **JDBC connection** to connect to the external database. #### **3. Run the BIX Extract Rule** 1. **Manual Execution**: - Run the Extract Rule manually from Dev Studio. 2. **Schedule the Export**: - Configure a **Job Scheduler** or a **Job in Admin Studio** to run the extract rule periodically (e.g., every night at 2 AM). #### **4. Verify Exported Data** - Validate that the exported data matches the required fields, format, and filters. - Test the integration with external reporting tools like Tableau or Power BI. ### **6.4.5 Example: Exporting Loan Applications for Tableau** **Scenario**: A business team wants to analyze loan application data using Tableau for external reporting. **Steps**: 1. **Create Extract Rule**: - Class: `Work-LoanApplication` - Properties: LoanID, CustomerName, LoanAmount, LoanStatus, SubmissionDate. - Format: CSV. - Filters: LoanStatus = “Approved”. 2. **Configure Destination**: - Output Path: `/data/exports/loanapplications_approved.csv`. 3. **Schedule the Export**: - Use a **Job Scheduler** to run the Extract Rule daily at 2 AM. 4. **Load into Tableau**: - Tableau reads the exported CSV file from the specified location. - Business users create reports and dashboards based on the loan application data. #### **Result**: | **Loan ID** | **Customer Name** | **Loan Amount** | **Loan Status** | **Submission Date** | | ----------- | ----------------- | --------------- | --------------- | ------------------- | | 001 | John Doe | $50,000 | Approved | 2024-06-01 | | 002 | Mary Smith | $75,000 | Approved | 2024-06-02 | The data can now be visualized in Tableau as charts, graphs, or summary reports. ### **6.4.6 Incremental Data Extraction** #### **What is Incremental Extraction?** Incremental Extraction enables BIX to export only the records that have **changed** since the last extraction. This reduces the amount of data exported and improves performance. #### **How to Enable Incremental Extraction** 1. Configure the **"Last Updated"** column (e.g., `pxUpdateDateTime`) in the Extract Rule. 2. BIX will extract only records where `pxUpdateDateTime` > Last Export Date. **Example**: - Run an incremental extraction daily to fetch only new or updated loan applications. ### **6.4.7 Best Practices for BIX** 1. **Select Only Necessary Properties**: Export only the data fields required for reporting to avoid large files. 2. **Use Incremental Extraction**: Minimize data volume by exporting only new or updated records. 3. **Optimize Scheduling**: Schedule BIX jobs during off-peak hours to avoid performance impact. 4. **Test Exported Data**: Verify the accuracy of data before integrating with external BI tools. 5. **Monitor Performance**: Track export job execution times and optimize as needed. ### **Summary of BIX** | **Feature** | **Description** | | -------------------------- | ------------------------------------- | | **Formats** | CSV, XML, Database Tables | | **Scheduled/Manual** | Run exports manually or schedule them | | **Incremental Extraction** | Export only new/updated records | | **Integration** | Use Tableau, Power BI, or ETL tools | | **Use Cases** | External reporting, trend analysis | ### **Conclusion of Reporting Design** We have now completed all key topics in **Reporting Design**: 1. **Report Definitions**: Retrieve and filter data using columns, sorting, and filters. 2. **Report Types**: Generate List Reports, Summary Reports, and Charts. 3. **Reporting Performance**: Optimize reports by limiting data, using indexes, and monitoring queries. 4. **Business Intelligence Exchange (BIX)**: Export Pega data for external reporting tools like Tableau and Power BI. --- # Security Design Security in Pega applications ensures data and system integrity, protecting against unauthorized access, breaches, and misuse. It comprises **authentication** (verifying users), **authorization** (controlling access), **data security**, and **audit and compliance** measures. ## **7.1 Authentication** **Authentication** verifies a user's identity to allow secure access to Pega applications. Pega supports multiple authentication methods to accommodate enterprise requirements and industry standards. ### **Key Authentication Methods in Pega** 1. **LDAP Authentication** 2. **SAML Single Sign-On (SSO)** 3. **OAuth 2.0 for API Authentication** 4. **Multi-Factor Authentication (MFA)** ### **7.1.1 LDAP Authentication** #### **What is LDAP Authentication?** **LDAP (Lightweight Directory Access Protocol)** is a protocol used to authenticate users against a centralized **directory service**, such as Microsoft Active Directory or OpenLDAP. #### **How LDAP Authentication Works** 1. A user attempts to log in to the Pega application. 2. Pega sends the user's credentials (username and password) to the **LDAP server**. 3. The LDAP server verifies the credentials and returns a success or failure response. 4. Pega grants or denies access based on the LDAP server's response. #### **Example of LDAP Authentication** **Scenario**: A company uses **Active Directory** for centralized user management. **Steps**: 1. The user enters their corporate username and password. 2. Pega forwards these credentials to the Active Directory server. 3. If credentials are correct, the user is authenticated, and the system loads their **Access Group**. #### **Steps to Configure LDAP Authentication in Pega** 1. **Create an Authentication Service**: - Go to **Records** → **SysAdmin** → **Authentication Service**. - Select **LDAP** as the authentication type. 2. **Configure LDAP Server Details**: - Specify the LDAP server hostname and port (e.g., `ldap.company.com:389`). - Define the **Base DN** (Distinguished Name) for user lookups, such as `dc=company,dc=com`. 3. **Map User Attributes**: - Map LDAP attributes (e.g., `sAMAccountName`) to Pega properties like `Operator ID`. 4. **Test the Configuration**: - Use the **Test Connectivity** option to verify the LDAP server connection. 5. **Assign Access Groups**: - Map LDAP users to Pega **Access Groups** to control their roles and permissions #### **Advantages of LDAP Authentication** 1. Centralized management of user credentials. 2. Users can log in with their corporate credentials. 3. Simplifies user provisioning and de-provisioning. ### **7.1.2 SAML Single Sign-On (SSO)** #### **What is SAML SSO?** **SAML (Security Assertion Markup Language)** Single Sign-On enables users to authenticate once using an **identity provider (IdP)**, such as Okta, Azure AD, or Google, and access multiple systems (including Pega) without re-entering credentials. #### **How SAML SSO Works** 1. The user accesses the Pega application. 2. Pega redirects the user to the **SAML Identity Provider** (IdP) for authentication. 3. The IdP verifies the user's credentials and sends a **SAML Assertion** back to Pega. 4. Pega grants access based on the assertion. #### **Example of SAML SSO** **Scenario**: A company uses **Okta** as the Identity Provider (IdP). **Flow**: 1. The user logs in to Okta. 2. Okta sends a **SAML Assertion** to Pega, confirming the user’s identity. 3. Pega grants access and assigns the appropriate **Access Group**. #### **Steps to Configure SAML SSO in Pega** 1. **Create a SAML Authentication Service**: - Go to **Records** → **SysAdmin** → **Authentication Service**. - Select **SAML 2.0** as the authentication type. 2. **Configure Identity Provider Details**: - Enter the **Issuer URL** and **SSO Endpoint URL** provided by the IdP. - Import the **IdP Certificate** for secure communication. 3. **Map User Attributes**: - Map SAML attributes (e.g., `email`, `role`) to Pega properties like `Operator ID` and `Access Group`. 4. **Test SSO Login**: - Attempt login through the SSO flow and verify successful authentication. #### **Advantages of SAML SSO** 1. Users log in once and access multiple applications. 2. Enhances user experience with seamless authentication. 3. Centralized management of user credentials. ### **7.1.3 OAuth 2.0 for API Authentication** #### **What is OAuth 2.0?** **OAuth 2.0** is an industry-standard protocol for **API authentication**. It allows secure access to APIs by using **access tokens** rather than user credentials. #### **How OAuth 2.0 Works** 1. A client application requests an **access token** from an OAuth Authorization Server. 2. The server issues a token upon verifying the user’s identity and permissions. 3. The token is passed with API requests to authenticate access. 4. The resource server (Pega) validates the token and grants access. #### **Example of OAuth Authentication** **Scenario**: A third-party application wants to access a Pega REST API. **Flow**: 1. The client application sends a request to the OAuth server to obtain an access token. 2. The OAuth server validates the request and issues a token. 3. The token is included in the API call to Pega: ``` GET /api/v1/cases Authorization: Bearer ``` 4. Pega validates the token and processes the API request. #### **Steps to Configure OAuth 2.0 in Pega** 1. **Set Up OAuth Authentication**: - Go to **Records** → **SysAdmin** → **Authentication Profile**. - Select **OAuth 2.0** as the authentication type. 2. **Register a Client Application**: - Define the client ID and client secret for the application. 3. **Configure Token Validation**: - Specify the OAuth Authorization Server and Token Endpoint URL. 4. **Secure APIs**: - Enable OAuth 2.0 protection for Pega REST services using the configured Authentication Profile. #### **Advantages of OAuth 2.0** 1. Secure authentication for APIs using access tokens. 2. Eliminates the need to share user credentials with third-party applications. 3. Supports modern authentication standards for integration. ### **7.1.4 Multi-Factor Authentication (MFA)** #### **What is Multi-Factor Authentication?** **MFA** adds an extra layer of security to user authentication by requiring **two or more verification factors**. This ensures that even if one factor (e.g., password) is compromised, unauthorized access is prevented. #### **MFA Verification Factors** 1. **Something You Know**: Password. 2. **Something You Have**: OTP (One-Time Password) sent to a mobile device. 3. **Something You Are**: Biometrics (e.g., fingerprint, facial recognition). #### **Steps to Implement MFA in Pega** 1. Use an external authentication provider (e.g., Okta, Azure AD) that supports MFA. 2. Configure Pega to redirect users to the external provider during login. 3. The external provider enforces MFA by sending an OTP or biometric verification. 4. Once verified, the provider redirects the user back to Pega. #### **Advantages of MFA** 1. Protects against stolen or weak passwords. 2. Meets compliance standards for secure authentication. 3. Enhances overall security for sensitive applications. ### **Summary of Authentication** | **Authentication Method** | **Purpose** | **Use Case** | | ------------------------- | --------------------------------------- | --------------------------------------------- | | **LDAP Authentication** | Verify users with a directory service. | Authenticate corporate users via LDAP. | | **SAML SSO** | Enable single sign-on for applications. | Users log in once to access multiple systems. | | **OAuth 2.0** | Secure API authentication with tokens. | Third-party apps access Pega APIs securely. | | **MFA** | Add extra verification layers. | High-security applications (e.g., banking). | ## **7.2 Authorization** **Authorization** determines the level of access a user has within a Pega application. It ensures that users can only view or interact with the parts of the application that are relevant to their roles and permissions. ### **Key Components of Authorization** 1. **Access Groups** 2. **Access Roles and Access Control** 3. **Privileges** ### **7.2.1 Access Groups** #### **What is an Access Group?** An **Access Group** is a Pega rule that defines the **roles, application versions**, and **portal access** for a group of users. It acts as a bridge between users and their permissions. #### **Features of Access Groups** 1. **Define Roles**: Specify access roles to control user permissions. 2. **Associate Applications**: Link users to specific applications and versions. 3. **Portals**: Configure the default portal (e.g., Case Manager, User Portal) a user will access. 4. **Customization**: Define landing pages, home views, and workspaces. #### **Example: Access Groups for a Loan Application System** | **Access Group** | **Roles** | **Application** | **Portal** | | ---------------------- | ---------------------- | ---------------- | ------------------- | | LoanAdminAccessGroup | AdminRole, ManagerRole | LoanApp 01.01.01 | Admin Portal | | LoanManagerAccessGroup | ManagerRole | LoanApp 01.01.01 | Case Manager Portal | | LoanUserAccessGroup | UserRole | LoanApp 01.01.01 | User Portal | #### **Steps to Configure Access Groups** 1. Go to **Records** → **Security** → **Access Group**. 2. Create a new Access Group and configure: - **Application**: Specify the application and version. - **Roles**: Assign one or more Access Roles. - **Portal**: Select the portal the user will access (e.g., User Portal, Admin Portal). 3. Assign the Access Group to users: - Open the **Operator ID** record. - Set the **Default Access Group** and additional groups as needed. #### **Benefits of Access Groups** 1. Centralize user role management. 2. Control which application version users can access. 3. Customize portals and workspaces for different user groups. ### **7.2.2 Access Roles and Access Control** #### **What is an Access Role?** An **Access Role** is a collection of permissions that determines what actions a user can perform within an application. Roles are linked to **Access Control** rules that define these permissions. #### **Types of Access Control** 1. **Access Control Lists (ACLs)** 2. **Rule-Based Access Control** #### **1. Access Control Lists (ACLs)** **Access Control Lists (ACLs)** are rules that specify the level of access (e.g., read, write, delete) a user has to specific classes or rules. | **Access Level** | **Description** | | ---------------- | --------------------------------- | | **Read** | View records or data. | | **Write** | Modify or create records. | | **Delete** | Delete records. | | **Execute** | Run activities or specific rules. | #### **Example: Access Role Configuration** **Scenario**: A loan system has the following roles: | **Role** | **Permission** | | --------------- | -------------------------------------------------- | | LoanAdminRole | Read/Write/Delete access to LoanApplication class. | | LoanManagerRole | Read/Write access to LoanApplication class. | | LoanUserRole | Read-only access to LoanApplication class. | **Steps to Configure Access Roles and ACLs**: 1. Go to **Records** → **Security** → **Access Role**. 2. Create a role (e.g., LoanAdminRole). 3. Configure **Access Control**: - Add ACL rules to define access levels for classes (e.g., LoanApplication). 4. Assign the role to an **Access Group**. #### **2. Rule-Based Access Control** Access Roles can control access to specific rules (like activities, sections, or data transforms). You can specify whether a role can **execute**, **modify**, or **view** the rule. #### **Benefits of Access Roles** 1. Enforce fine-grained control over rules and data. 2. Limit user permissions to reduce security risks. 3. Enable role-based security across the application. ### **7.2.3 Privileges** #### **What is a Privilege?** A **Privilege** is a security rule that restricts access to **specific functionalities** or rules within the application. Privileges are often used to control sensitive actions. #### **When to Use Privileges** - To protect sensitive rules (e.g., activities, flows) from unauthorized access. - To restrict advanced actions like approving high-value loans or deleting cases. #### **Example: Restricting High-Value Loan Approvals** **Scenario**: Only managers can approve loans greater than $100,000. **Steps to Configure**: 1. **Create a Privilege**: - Go to **Records** → **Security** → **Privilege**. - Name: `ApproveHighValueLoan`. 2. **Assign Privilege to Rule**: - Open the **Flow Action** rule for approving loans. - Add the `ApproveHighValueLoan` privilege. 3. **Grant Privilege to Roles**: - Go to the **Access Role** for managers (LoanManagerRole). - Add the `ApproveHighValueLoan` privilege. #### **Benefits of Privileges** 1. Protect sensitive rules or actions. 2. Implement additional layers of security. 3. Control access to advanced functionalities for specific roles. ### **Summary of Authorization** | **Component** | **Purpose** | **Example** | | ----------------- | ----------------------------------------------------- | --------------------------------------- | | **Access Groups** | Define user roles, application versions, and portals. | LoanAdminAccessGroup for admin users. | | **Access Roles** | Control permissions (read, write, delete) for rules. | LoanUserRole has read-only permissions. | | **Privileges** | Restrict access to specific functionalities. | Privilege to approve loans > $100,000. | ## **7.3 Data Security** **Data Security** ensures that only authorized users can access, view, or modify sensitive data within a Pega application. It applies to both **application data** and **user-specific data**. Data security is implemented at the following levels: 1. **Row-Level Security** 2. **Field-Level Security** 3. **Encryption** ### **7.3.1 Row-Level Security** #### **What is Row-Level Security?** **Row-Level Security** controls access to specific records (rows) based on the user’s role, attributes, or context. This ensures that users only see or interact with data that they are authorized to access. #### **How is Row-Level Security Implemented in Pega?** Pega uses **Access When Rules** and **Access Control Policies** to implement Row-Level Security: 1. **Access When Rules**: Define conditions that determine whether a user can access a record. 2. **Access Control Policies**: Enforce row-level access rules using **Access When Rules**. #### **Example: Restrict Access to Loan Applications** **Scenario**: - Loan Officers should only see loan applications assigned to them. - Managers should see all loan applications within their region. **Steps to Implement Row-Level Security**: 1. **Create an Access When Rule**: - Go to **Records** → **Security** → **Access When**. - Define the condition: ``` .AssignedTo == pxRequestor.OperatorID ``` - This condition ensures that a record is visible only if it is assigned to the current user. 2. **Create an Access Control Policy**: - Go to **Records** → **Security** → **Access Control Policy**. - Set: - **Class**: LoanApplication. - **Policy Type**: **Read**. - **Condition**: Reference the Access When Rule. 3. **Test Access**: - Log in as a Loan Officer and verify that they can only see their assigned loan applications. - Log in as a Manager and confirm they see region-specific records. #### **Benefits of Row-Level Security**: 1. Limits visibility of sensitive records based on user roles. 2. Ensures compliance with privacy and regulatory requirements. 3. Improves application performance by restricting data access. ### **7.3.2 Field-Level Security** #### **What is Field-Level Security?** **Field-Level Security** controls access to specific fields (properties) within a record. It is useful for masking or hiding sensitive data from unauthorized users. #### **How to Implement Field-Level Security in Pega** Field-Level Security is implemented using: 1. **Property-Level Access Control**. 2. **Access Control Policies** for specific properties. #### **Example: Masking Customer SSN for Non-Admin Users** **Scenario**: - The **SSN (Social Security Number)** field should only be visible to Admins. - For non-admin users, the SSN field should be masked (e.g., `XXX-XX-1234`). **Steps to Implement Field-Level Security**: 1. **Create a Property** for SSN: - Property Name: `CustomerSSN`. 2. **Configure Field Visibility** in Section Rules: - Use **Visibility Conditions**: - Visible if **CurrentUserRole == "Admin"**. - Mask or hide otherwise. 3. **Apply Field Masking**: - Add custom logic to display only the last 4 digits for non-admin users: ```java return "XXX-XX-" + .CustomerSSN.substring(7); ``` 4. **Add Access Control Policy**: - Go to **Records** → **Security** → **Access Control Policy**. - Define the policy: - **Class**: CustomerDetails. - **Policy Type**: **Read**. - **Field**: CustomerSSN. - **Condition**: Only accessible if the user is an Admin. #### **Benefits of Field-Level Security**: 1. Protects sensitive information like SSNs, credit card numbers, or salaries. 2. Supports compliance with data protection laws (e.g., GDPR, HIPAA). 3. Provides fine-grained control over data visibility. ### **7.3.3 Encryption** #### **What is Encryption?** **Encryption** protects sensitive data by converting it into an unreadable format. It ensures that data remains secure **at rest** (stored in databases) and **in transit** (during communication between systems). #### **Types of Encryption in Pega**: 1. **Encryption at Rest**: Protects data stored in the Pega database. 2. **Encryption in Transit**: Protects data transmitted between clients and servers. #### **1. Encryption at Rest** Pega supports **database encryption** to protect sensitive data fields stored in tables. ##### **Steps to Enable Encryption at Rest**: 1. Use **Pega Platform Data Encryption**: - Go to **Records** → **SysAdmin** → **Keystore**. - Configure a **Keystore** with encryption keys. 2. Enable Encryption for Specific Properties: - Use **Encrypt** checkbox when defining a property (e.g., CustomerSSN). - Specify the encryption key for the property. #### **2. Encryption in Transit** To ensure data security during communication: - Use **HTTPS/TLS** for secure connections between clients and servers. - Enable encryption for APIs and integrations. ##### **Steps to Secure APIs**: 1. Enable HTTPS on the Pega server. 2. Configure REST/SOAP services to require **SSL/TLS** encryption. #### **Example: Encrypting Customer SSN** 1. Property: `CustomerSSN`. 2. Enable encryption: - Select **Encrypt** in the property configuration. 3. Keystore: Use a **256-bit encryption key** to protect the field. #### **Benefits of Encryption**: 1. Prevents unauthorized access to sensitive data. 2. Ensures data security at rest and in transit. 3. Supports compliance with regulatory requirements (e.g., PCI-DSS, HIPAA). ### **Summary of Data Security** | **Security Level** | **Purpose** | **Implementation** | | ------------------------ | ---------------------------------------------- | ------------------------------------------ | | **Row-Level Security** | Restrict access to specific records (rows). | Access When Rules, Access Control Policies | | **Field-Level Security** | Mask or hide sensitive fields from users. | Field masking, Access Control Policies | | **Encryption** | Protect sensitive data at rest and in transit. | Database encryption, HTTPS/TLS | ## **7.4 Audit and Compliance** Audit and compliance mechanisms ensure that user actions and data changes within a Pega application are tracked, monitored, and logged. These mechanisms are critical for maintaining **accountability**, **transparency**, and **security** while adhering to regulatory requirements. ### **Key Components of Audit and Compliance** 1. **Audit Trails** 2. **Logging** ### **7.4.1 Audit Trails** #### **What is an Audit Trail?** An **Audit Trail** records and displays a history of user actions, data changes, and case updates. It provides a detailed log of **who** performed an action, **what** the action was, and **when** it occurred. #### **Types of Audit Trail Information** 1. **Case-Level Audit Trail**: Tracks actions and changes made within a case. 2. **Field-Level Audit Trail**: Tracks changes to specific fields within a case. #### **How Audit Trails Work** 1. Pega automatically tracks case updates, such as: - Creating or updating a case. - Changing the value of fields. - Changing the case status. 2. Audit trails are stored and displayed in the **History Tab** of a case. #### **Example: Tracking Case Updates** **Scenario**: A loan application case is updated multiple times. **Audit Trail Details**: | **Date/Time** | **User** | **Action** | **Details** | | ------------------- | --------- | ------------------- | ------------------------------- | | 2024-06-10 10:00 AM | JohnDoe | Created Case | Loan ID: 001, Status: Pending | | 2024-06-10 11:00 AM | MarySmith | Updated Loan Amount | Changed LoanAmount: $50K → $75K | | 2024-06-10 12:00 PM | JohnDoe | Changed Case Status | Status: Pending → Approved | #### **Steps to Enable and Configure Audit Trails** 1. **Enable History for Case Types**: - In **App Studio**, open the **Case Type**. - Navigate to **Settings** → **History**. - Enable history tracking for case actions. 2. **Field-Level Audit**: - Go to the **Property** rule for the field you want to track. - Select the option **Track Changes**. 3. **Customize the Audit Trail** (Optional): - Use a **History-Add** method in an activity to log custom actions or events. #### **Benefits of Audit Trails** 1. Provides transparency by tracking user actions. 2. Ensures accountability and data integrity. 3. Supports compliance with regulations (e.g., GDPR, HIPAA, SOX). 4. Helps troubleshoot and analyze system behavior. ### **7.4.2 Logging** #### **What is Logging?** **Logging** records detailed information about system events, errors, and security-related activities. Logs help administrators monitor application health, identify security breaches, and troubleshoot issues. #### **Types of Logs in Pega** 1. **System Logs**: Record system events, errors, and warnings. 2. **Security Logs**: Track authentication failures, access violations, and other security events. 3. **Audit Logs**: Record user activities and changes. #### **Key System Log Files** | **Log File** | **Purpose** | | -------------------- | --------------------------------------------- | | `PegaRULES.log` | General log for system errors and exceptions. | | `PegaSecurity.log` | Logs security-related events. | | `PegaAlert.log` | Captures performance and alert information. | | `PegaStackTrace.log` | Provides detailed stack traces for errors. | #### **How to Monitor Logs in Pega** 1. **Access Logs in Admin Studio**: - Open **Admin Studio** → **Resources** → **Log Files**. - View live log details or download log files. 2. **Configure Logging Levels**: - Use the **Logging Level Settings** tool to adjust logging levels for specific classes (e.g., DEBUG, ERROR, WARN). - Steps: - Navigate to **Dev Studio** → **Configure** → **System** → **Operations** → **Logging Level Settings**. - Set appropriate levels for troubleshooting. 3. **Security Event Monitoring**: - Monitor failed login attempts, unauthorized rule access, and other security breaches in the `PegaSecurity.log`. 4. **Add Custom Log Messages**: - Use the **Log-Message** method in an activity to write custom log entries: ```java Log-Message "Loan application status updated to Approved by user: " + .OperatorID ``` #### **Example: Logging Failed Login Attempts** **Scenario**: Track failed login attempts for a user. - **Log Entry in `PegaSecurity.log`**: ``` 2024-06-10 12:05:00 [SECURITY] Login failed for user: JohnDoe. IP Address: 192.168.1.10. Reason: Invalid password. ``` #### **Benefits of Logging** 1. Detects and alerts administrators about potential security breaches. 2. Helps troubleshoot errors and performance issues. 3. Provides a detailed audit trail of system events. 4. Ensures compliance by logging access and authentication activities. ### **Best Practices for Audit and Logging** 1. **Enable Audit Trails**: Track user actions and field-level changes to ensure accountability. 2. **Monitor Security Logs**: Regularly review `PegaSecurity.log` for suspicious activities. 3. **Set Appropriate Logging Levels**: - Use **ERROR** for production environments to reduce log noise. - Use **DEBUG** temporarily for troubleshooting. 4. **Secure Log Files**: Protect log files with access controls to prevent tampering. 5. **Archive Logs**: Set up log rotation and archiving to manage disk space. 6. **Alert on Security Events**: Integrate logs with tools like **SIEM** (Security Information and Event Management) for proactive security monitoring. ### **Summary of Audit and Compliance** | **Feature** | **Purpose** | **Implementation** | | ---------------- | ---------------------------------------------------- | ------------------------------------------------------ | | **Audit Trails** | Track user actions, case changes, and field edits. | Enable case history, use field-level tracking. | | **Logging** | Record system events, errors, and security breaches. | Use system logs (`PegaRULES.log`, `PegaSecurity.log`). | ### **Conclusion of Security Design** We have now covered all topics in **Security Design**: 1. **Authentication**: Secure user login with LDAP, SAML SSO, OAuth 2.0, and MFA. 2. **Authorization**: Control access using Access Groups, Roles, and Privileges. 3. **Data Security**: Implement Row-Level Security, Field-Level Security, and Encryption. 4. **Audit and Compliance**: Track actions with Audit Trails and monitor events with Logging. These security measures ensure that Pega applications are protected against unauthorized access, data breaches, and misuse. --- # Deployment and Testing Design Proper **Deployment and Testing Design** ensures that Pega applications are deployed efficiently, errors are minimized, and testing is conducted to maintain quality and performance. ## **8.1 Deployment Pipelines** A **Deployment Pipeline** in Pega refers to the automated and systematic process of moving an application from development to higher environments, such as **staging**, **testing**, and **production**. This process is achieved through **Continuous Integration** and **Continuous Deployment (CI/CD)** methodologies. ### **Key Concepts in Deployment Pipelines** 1. **CI/CD Tools** 2. **Rule Migration with Product Rules** 3. **Environment Management** ### **8.1.1 CI/CD (Continuous Integration / Continuous Deployment)** **What is CI/CD?** CI/CD automates the build, test, and deployment process, ensuring that new changes are quickly tested and safely deployed to higher environments. #### **CI/CD Tools for Pega** Pega integrates with external CI/CD tools like: 1. **Jenkins** 2. **Azure DevOps** 3. **GitLab CI/CD** 4. **Bamboo** These tools automate tasks such as **code versioning**, **rule export/import**, **testing**, and **deployment**. #### **Steps to Set Up CI/CD Pipelines in Pega** 1. **Version Control**: Store application rules and configurations in a version control system (e.g., Git). 2. **Rule Packaging**: Use **Product Rules** to package the application artifacts. 3. **Automated Builds**: Configure tools like Jenkins to trigger builds when code is committed to version control. 4. **Deployment to Higher Environments**: Automate rule import to staging or production using CI/CD tools. 5. **Testing Integration**: Run **PegaUnit tests** or other automated tests to validate the changes. #### **Example: CI/CD Pipeline with Jenkins** **Scenario**: Automate deployment from Development to Staging. #### **Steps**: 1. **Prepare Product Rule**: - Create a **Product Rule** to package the application rules, data instances, and configurations. - Example: - Name: `LoanApp_Deployment_01_01_01`. - Contents: Application rules, Data Types, Access Groups, etc. 2. **Store Artifacts in Version Control**: - Export the packaged Product Rule to a repository like **GitHub** or **Bitbucket**. 3. **Set Up Jenkins Job**: - Install **Pega Deployment Manager** (a Jenkins plugin for Pega). - Define the following Jenkins stages: - **Build**: Trigger rule export from Development. - **Deploy**: Import rules into the Staging environment. - **Test**: Run PegaUnit tests to validate changes. 4. **Trigger Pipeline**: - Developers commit changes to GitHub → Jenkins automatically starts the pipeline → Application is deployed to Staging. #### **Benefits of CI/CD Pipelines**: 1. **Faster Deployments**: Automates the process of rule migration and testing. 2. **Error Reduction**: Detects errors early through automated testing. 3. **Consistency**: Ensures consistent deployments across environments. 4. **Improved Collaboration**: Integrates with version control systems for better team collaboration. ### **8.1.2 Rule Migration: Using Product Rules** **What are Product Rules?** A **Product Rule** in Pega is used to package application components, such as rules, data, and configurations, for deployment to higher environments. #### **Steps to Create a Product Rule** 1. Go to **Records** → **SysAdmin** → **Product**. 2. Create a new Product Rule: - **Name**: `LoanApp_Deployment_01_01_01`. - **Version**: `01-01-01`. 3. **Add Components**: - Add the application ruleset versions. - Include specific rule types, such as: - Case Types - Data Pages - Access Groups 4. **Include Data Instances**: - Include data that is required for the deployment (e.g., WorkQueues, Operators). 5. **Export Product Rule**: - Export the Product Rule as a **ZIP file**. 6. **Import to Target Environment**: - Log in to the target environment (e.g., Staging). - Use the **Import Wizard** to upload and validate the Product Rule ZIP file. #### **Example: Deploying a Loan Application** **Steps**: 1. **Create Product Rule**: Include all rules and necessary data for the loan application. 2. **Export the Product**: Generate the ZIP file. 3. **Move to Staging**: Import the ZIP file into the Staging environment. 4. **Test Application**: Validate the deployment using PegaUnit tests. #### **Benefits of Product Rules**: 1. **Simplified Deployment**: Package all components into a single file. 2. **Reusable**: Use the same Product Rule for multiple deployments. 3. **Versioning**: Maintain version control for deployment artifacts. ### **8.1.3 Environment Management** Pega applications typically move through the following environments: 1. **Development**: - Developers build, test, and refine rules. 2. **Staging (Testing)**: - Application is tested for functionality, integration, and performance. 3. **Production**: - The live environment used by end-users. #### **Best Practices for Environment Management** 1. **Version Control**: Maintain versioned rule artifacts in a source control repository (e.g., Git). 2. **Automate Migrations**: Use CI/CD pipelines for automated rule movement across environments. 3. **Environment-Specific Data**: Use **Dynamic System Settings (DSS)** for configurable values that change across environments (e.g., endpoints, API keys). 4. **Validate Changes**: Test all changes in **Staging** before deploying to Production. 5. **Rollback Strategy**: Configure rollback plans to restore the previous version in case of deployment failures. ### **Summary of Deployment Pipelines** | **Component** | **Purpose** | **Tools/Methods** | | -------------------------- | ----------------------------------------------- | ----------------------------------------- | | **CI/CD Pipelines** | Automate build, test, and deployment processes. | Jenkins, Azure DevOps, GitLab CI/CD | | **Rule Migration** | Package and move rules to higher environments. | Product Rules, Import/Export Wizard | | **Environment Management** | Manage Development, Staging, and Production. | Dynamic System Settings, CI/CD automation | ## **8.2 Testing Strategies** Testing ensures that the application functions correctly, meets business requirements, and performs well under varying loads. Pega supports multiple testing strategies, including **unit testing**, **UI testing**, and **performance testing**. ### **8.2.1 PegaUnit Testing** #### **What is PegaUnit?** **PegaUnit** is Pega’s built-in testing framework for validating rules, such as **data transforms**, **activities**, **decision rules**, and **flows**. It helps developers identify and fix issues early in the development cycle. #### **Types of Rules Tested Using PegaUnit** 1. **Decision Rules**: Decision Tables, Decision Trees, and When Rules. 2. **Data Transforms**: Validate data mapping and transformations. 3. **Activities**: Verify logic and step execution. 4. **Flows**: Test the flow execution, including flow paths and assignments. #### **Steps to Create a PegaUnit Test Case** **Example**: Testing a **Data Transform** rule that calculates loan eligibility. 1. **Open the Rule to Test**: - Navigate to the **Data Transform** rule (e.g., `CalculateLoanEligibility`). 2. **Create a Test Case**: - Click **Actions** → **Create Test Case**. 3. **Define Input Data**: - Provide sample input values: - Input Property: `Income = 100,000`. - Input Property: `LoanAmount = 75,000`. 4. **Set Expected Results**: - Define the expected outputs: - Output Property: `Eligible = true`. 5. **Run the Test**: - Run the test case to validate that the Data Transform produces the expected output. 6. **Save and Reuse**: - Save the test case for future regression testing. #### **Automating PegaUnit Tests** 1. Use **Deployment Manager** in Pega for CI/CD pipelines. 2. Integrate PegaUnit tests to run automatically as part of the deployment process. 3. Generate test reports to track success and failure rates. #### **Benefits of PegaUnit Testing** 1. **Automated Testing**: Reduces manual effort and saves time. 2. **Early Issue Detection**: Identify bugs during development. 3. **Reusable Test Cases**: Test cases can be reused for regression testing. 4. **Improved Quality**: Ensures consistent rule execution and reliability. ### **8.2.2 UI Testing** #### **What is UI Testing?** **UI Testing** verifies that the user interface behaves as expected, ensuring a seamless and error-free user experience. #### **Tools for UI Testing** 1. **Selenium**: An open-source tool for automating web-based UI testing. 2. **Pega Test Automation Kit (TAK)**: Pega’s framework for automating UI interactions. #### **Steps to Automate UI Testing Using Selenium** **Example**: Test the loan application submission flow. 1. **Set Up Selenium**: - Install Selenium WebDriver and configure the testing environment (e.g., Java, Python, or C#). 2. **Locate UI Elements**: - Use **XPath** or **CSS Selectors** to identify UI components: ```python driver.find_element_by_id("LoanAmount").send_keys("75000") driver.find_element_by_id("Submit").click() ``` 3. **Verify Expected Results**: - Assert that the UI displays the correct message after submission: ```python success_message = driver.find_element_by_id("SuccessMsg").text assert success_message == "Loan application submitted successfully" ``` 4. **Run and Debug the Test**: - Execute the Selenium script and fix any issues. 5. **Integrate with CI/CD**: - Include Selenium scripts in your CI/CD pipeline for automated UI testing. #### **Benefits of UI Testing** 1. Verifies that the UI works as expected. 2. Ensures cross-browser compatibility. 3. Detects issues with navigation, buttons, and input forms. ### **8.2.3 Performance Testing** #### **What is Performance Testing?** **Performance Testing** evaluates how well an application performs under various load conditions. It identifies bottlenecks, slow response times, and scalability issues. #### **Tools for Performance Testing** 1. **Apache JMeter**: Simulates user load and measures system performance. 2. **LoadRunner**: Another tool for large-scale performance and stress testing. #### **Performance Testing Steps Using JMeter** **Example**: Simulate 100 concurrent users submitting loan applications. 1. **Install JMeter**: - Download and install Apache JMeter. 2. **Create a Test Plan**: - Define the test plan to simulate user actions: - **Thread Group**: Set 100 users, ramp-up time, and iterations. - **HTTP Sampler**: Configure the API endpoint or form submission details. 3. **Add Listeners**: - Use listeners to capture test results, such as: - Response time - Throughput - Error rate 4. **Run the Test**: - Execute the JMeter test plan to simulate 100 users submitting loan applications. 5. **Analyze Results**: - Review JMeter results for: - Average response time. - Maximum load handled. - Errors encountered. #### **Performance Metrics to Monitor** 1. **Response Time**: Time taken for the system to process a request. 2. **Throughput**: Number of transactions processed per second. 3. **Error Rate**: Percentage of failed transactions. 4. **CPU/Memory Utilization**: Resources consumed under load. #### **Benefits of Performance Testing** 1. Ensures the application can handle high user loads. 2. Identifies bottlenecks before production. 3. Improves scalability and reliability. ### **Summary of Testing Strategies** | **Testing Strategy** | **Purpose** | **Tools** | **Example** | | ----------------------- | ----------------------------------------------- | ------------------ | ------------------------------------------------ | | **PegaUnit** | Test rules like activities and data transforms. | PegaUnit | Test `CalculateLoanEligibility` Data Transform. | | **UI Testing** | Verify user interface behavior and usability. | Selenium, Pega TAK | Automate loan submission flow. | | **Performance Testing** | Test application performance under load. | JMeter, LoadRunner | Simulate 100 users submitting loan applications. | ## **8.3 Error Handling** **Error Handling** focuses on managing deployment failures gracefully, logging errors for analysis, and ensuring the system remains stable. Proper error handling helps maintain application reliability during deployments. ### **Key Aspects of Error Handling** 1. **Rollback Strategies** 2. **Logging Deployment Errors** 3. **Best Practices for Deployment Error Management** ### **8.3.1 Rollback Strategies** #### **What is a Rollback Strategy?** A **rollback strategy** ensures that if a deployment fails, the system can automatically revert to the previous stable state. This minimizes downtime and prevents the deployment of faulty changes. #### **Common Rollback Approaches** 1. **Manual Rollback**: - Restore the previous version of the application manually in case of deployment failure. 2. **Automated Rollback**: - Use automation tools (e.g., Jenkins, Azure DevOps) to automatically roll back changes if errors occur during deployment. 3. **Version Control Rollback**: - Use a version control system (e.g., Git) to revert the rules to the previous version. #### **Steps to Implement Rollback in Pega** **Example**: Rollback changes if a deployment to the **Staging Environment** fails. 1. **Version Control Integration**: - Ensure the application is version-controlled in a system like **GitHub** or **Bitbucket**. 2. **Pre-Deployment Backup**: - Before deploying, create a backup of the current stable state: - Export the existing Product Rule as a ZIP file. 3. **CI/CD Pipeline Rollback**: - In Jenkins or Azure DevOps, configure a step to revert to the previous version: - If the deployment fails, re-import the previous Product Rule ZIP file. 4. **Validation Checks**: - Include automated tests (e.g., PegaUnit) to validate changes before allowing deployment to Production. - If tests fail, trigger the rollback step. #### **Example Jenkins Pipeline with Rollback** ```groovy pipeline { stages { stage('Deploy') { steps { script { try { sh 'deploy-to-staging.sh' // Deployment script sh 'run-tests.sh' // Run automated tests } catch (Exception e) { echo "Deployment failed. Rolling back..." sh 'rollback.sh' // Rollback script error("Deployment and rollback completed.") } } } } } } ``` #### **Benefits of Rollback Strategies** 1. Reduces downtime caused by failed deployments. 2. Ensures the system can recover to a stable state quickly. 3. Minimizes the risk of faulty changes reaching Production. ### **8.3.2 Logging Deployment Errors** #### **Why Log Deployment Errors?** Logging deployment errors allows teams to: 1. Identify the root cause of deployment failures. 2. Troubleshoot and fix issues efficiently. 3. Maintain an audit trail for compliance and accountability. #### **Steps to Configure Error Logging in Pega** 1. **Enable System Logs**: - Use **PegaRULES.log** to capture deployment errors and warnings. - Ensure the logging level is set to **ERROR** for production environments. 2. **Custom Logging for Deployments**: - Use the **Log-Message** method in an activity to log custom deployment events. - Example: ```java Log-Message "Deployment failed for LoanApp_01_01_01. Error: " + .ErrorMessage ``` 3. **Monitor Security Logs**: - Use **PegaSecurity.log** to track access violations and security-related errors during deployments. 4. **Integrate with Monitoring Tools**: - Use external monitoring tools (e.g., Splunk, ELK Stack) to aggregate and analyze logs. #### **Example: Capturing Deployment Errors** **Scenario**: Log errors when a Product Rule fails to import. **Steps**: 1. Add custom error logging to the import process. 2. Log details such as: - Timestamp - Error Message - Deployment User **Sample Log Entry**: ``` 2024-06-11 10:00:00 [ERROR] Product Rule import failed. Application: LoanApp_01_01_01 User: admin@company.com Error: Missing dependent ruleset version. ``` #### **Benefits of Logging Deployment Errors** 1. Helps identify and resolve issues quickly. 2. Provides detailed information for troubleshooting. 3. Tracks deployment history and compliance audits. ### **8.3.3 Best Practices for Deployment Error Management** 1. **Automate Rollbacks**: - Configure CI/CD pipelines to automatically roll back failed deployments. 2. **Validate Before Deployment**: - Run **PegaUnit** and **automated tests** to catch errors early. 3. **Log Detailed Errors**: - Include timestamps, user details, and error messages in deployment logs. 4. **Monitor Logs in Real Time**: - Integrate logs with real-time monitoring tools like **Splunk** or **ELK Stack**. 5. **Test Rollback Procedures**: - Regularly test rollback processes in lower environments to ensure reliability. 6. **Document Failures**: - Maintain a deployment error log and document fixes for future reference. ### **Summary of Error Handling** | **Aspect** | **Purpose** | **Implementation** | | ----------------------------- | ----------------------------------------------- | ---------------------------------------------- | | **Rollback Strategies** | Revert changes when deployment fails. | Manual, automated rollback, version control. | | **Logging Deployment Errors** | Capture and analyze deployment failures. | System logs, custom error logging, monitoring. | | **Best Practices** | Ensure smooth deployment and minimize failures. | Automate rollbacks, validate before deploying. | ### **Conclusion of Deployment and Testing Design** We have now completed all key topics in **Deployment and Testing Design**: 1. **Deployment Pipelines**: Automate deployments using CI/CD tools like Jenkins and Azure DevOps. 2. **Testing Strategies**: Use PegaUnit for rule testing, Selenium for UI testing, and JMeter for performance testing. 3. **Error Handling**: Implement rollback strategies, log deployment errors, and follow best practices for deployment management. These strategies ensure that your Pega application is deployed reliably, thoroughly tested, and capable of handling errors effectively. --- # Pega Platform Design (Additional Content) ### **1. Weighting and Emphasis of Key Topics** To help learners prioritize their study focus, it's valuable to indicate **which topics frequently appear in exams**, especially in scenario-based or multiple-choice questions. #### **Recommended High-Frequency Topics in Pega Platform Design** - **Center-out Architecture**: - This concept often appears in **scenario-based questions**. - You may be asked to identify why center-out is preferable over top-down or bottom-up design in a given use case. - **Label suggestion**: *“High-frequency concept: often tested in case-based questions.”* - **Rule Resolution and RuleSet Versioning**: - Many questions test your understanding of how Pega resolves rules based on RuleSet stack and availability. - Questions may involve identifying which rule executes or how versioning impacts runtime behavior. - **Class Structure (ECS Model)**: - Commonly tested, especially around choosing the correct class to place a rule. - Students are often asked to fix class structure issues or identify violations of ECS best practices. - **Reuse and Modularity**: - Scenarios may ask which design allows for **maximum reuse** or **future maintainability**, especially related to **rules reuse**, **circumstancing**, and **specialization**. ### **2. Reinforcement through Practice and Visual Aids** #### **Mini Quiz Example (After ECS Model Section)** **Question**: Which layer in the ECS (Enterprise-Class Structure) model is primarily responsible for shared reusable rules across multiple applications? A. Implementation Layer B. Framework Layer C. Organization Layer D. Application Layer **Correct Answer**: C. Organization Layer **Explanation**: The Organization layer defines reusable components and rules shared across multiple applications under the same organization. #### **Suggested Visual: ECS Four-Layer Diagram** Use a labeled diagram showing: - Organization Layer - Division Layer - Framework Layer - Implementation Layer Each layer should include: - **Purpose** - **Typical rules placed** - **Reusability scope** This helps learners understand class hierarchy and rule placement in a glance. ### **3. Common Mistakes and Exam Traps** #### **Example: RuleSet Versioning – Common Pitfall** **Common Mistake**: - **Forgetting to lock previous RuleSet versions before creating a new version**. **Why This Matters**: - In real development, an unlocked older version can lead to rules being mistakenly edited or checked in there, which violates versioning integrity. - In exams, you may see a question like: **Scenario**: You’re releasing version 01-01-10 of your application. A team member accidentally checks in a rule to 01-01-01. What should you have done to prevent this? A. Removed 01-01-01 from the RuleSet list B. Created a new application version C. Locked 01-01-01 before development began on 01-01-10 D. Disabled access to 01-01-01 via privileges **Correct Answer**: C **Explanation**: Locking previous versions ensures rules are only added to the intended development version. #### **Other Frequently Missed Areas** - **Wrong class placement of rules**: Misunderstanding the ECS model. - **Incorrect use of rule delegation**: Confusion between business users and system admins. - **Misuse of application layers**: For instance, putting reusable logic into implementation instead of framework layer. ### **Summary of Enhancements for Pega Platform Design Module** | **Enhancement Type** | **Description** | | --- | --- | | **Topic Weighting** | Mark topics like Center-out Architecture as high-frequency. | | **Quick Quizzes** | Insert 2–3 MCQs per subtopic for review. | | **Visual Summaries** | Use diagrams for ECS model, rule resolution path, and class hierarchy. | | **Common Pitfall Alerts** | Highlight frequent mistakes like RuleSet version misuse. | --- # Pega Platform Design Extended (Additional Content) ### **1. Exam-Oriented Summary at the End of Each Section** To reinforce the **exam-driven learning mindset**, each module should end with a brief note clarifying how the concept typically appears in the LSA (Lead System Architect) exam. #### **Recommended Format**: *“In the LSA exam, this topic typically appears as a scenario-based multiple-choice question, often assessing your ability to compare Job Schedulers with Agents based on system behavior.”* #### **Benefits**: - Helps learners prioritize **how** to study each topic. - Builds awareness of **exam patterns**, such as configuration scenarios vs. conceptual distinctions. ### **2. Emphasizing High-Frequency Exam Concepts** Some concepts are statistically more likely to appear in exam scenarios. These **high-frequency topics** should be clearly highlighted using visual emphasis techniques in the final format (e.g., bold text, border blocks, or shaded callouts). #### **Examples of High-Frequency Content to Emphasize**: - **Job Scheduler vs Standard Agent** - **Three Decisioning Criteria in NBA**: Eligibility, Applicability, Suitability - **Predictive vs Adaptive Models** - **Container vs On-Premise Deployment Impacts** - **Common REST/SOAP integration patterns** #### **Example Format**: **Important for Exam**: **Job Scheduler** is preferred in modern cloud deployments due to its scalability and monitoring advantages over **Agents**, which are more suited for traditional on-premise batch processing. Expect this distinction to be tested in configuration scenario questions. ### **3. Visual Aids for Complex Architectural Topics** Although not mandatory in text-based study material, **well-designed diagrams** significantly enhance understanding of layered structures and process flows—especially valuable for visual learners and during revision. #### **Recommended Visuals**: - **ECS (Enterprise Class Structure)**: - Graphically depict Organization, Division, Framework, and Implementation layers. - Show typical rule types per layer and inheritance flow. - **NBA (Next-Best-Action) Flow**: - Visualize the decisioning path: *Eligibility → Applicability → Suitability → Prioritization*. - **Integration Comparison Table**: - REST vs SOAP visual grid: highlight key differences in format, transport, error handling, and configuration. #### **Best Practice for Visual Aids**: - Use **color-coded** or **border-separated** visuals when creating slide decks or HTML learning materials. - Maintain **consistency in iconography, hierarchy, and labeling** to ease retention. ### **Summary of Enhancements for Pega Platform Design Extended** | **Area** | **Recommendation** | | --- | --- | | **Exam Awareness** | Add a one-line exam note at the end of each section to indicate how it’s tested. | | **Concept Emphasis** | Visually highlight exam-priority content (e.g., Job Scheduler vs Agent). | | **Visual Support** | Include ECS diagrams, NBA flows, and integration comparisons to aid comprehension. | --- # Application Design (Additional Content) ### **1. Visualizing Microjourneys: Case Life Cycle Model** Pega’s Microjourney approach focuses on delivering end-to-end business outcomes. To help learners understand how Microjourneys are implemented visually in Pega, include a **Case Life Cycle Model diagram** as shown in App Studio's **Case Designer**. #### **Breakdown of Case Visualization Components** - **Stages (Blue rectangles)**: - Represent major milestones or phases in a case (e.g., “Intake”, “Approval”, “Resolution”). - Always sequential, high-level flow grouping. - **Steps (White rectangles within stages)**: - Represent individual actions or tasks (e.g., “Collect Customer Info”, “Validate Identity”). - Can be user assignments, automated steps, or subflows. - **Processes (Icon indicating flow)**: - Define how steps are carried out using flow logic (e.g., conditions, parallel paths). - Clicking into a step shows the underlying flow rule. #### **Why This Matters for Exams and Projects**: Understanding this visual model helps in: - Designing intuitive, maintainable Microjourneys. - Answering scenario-based questions in LSA exams. - Communicating design logic with business stakeholders. ### **2. Case Reopening & Exception Handling** #### **Case Reopening** Include a dedicated section explaining **how and when to reopen a case**, such as: - Via a post-resolution action. - Using the **Reopen Case** smart shape in a flow. - Automating reopening through service-level violations or business rules. **Example**: A customer support case is marked “Resolved-Completed” but reopens automatically if negative feedback is received within 48 hours. #### **Exception Handling** Explain strategies for error recovery: - **Alternate Stage**: - Define a fallback stage (e.g., “Manual Review”) when a primary stage fails. - **Error Handling Flow**: - Catch exceptions in flow execution (e.g., failed integration call). - Use **Error Handler** shapes to route to exception handling subflows. #### **Why Include**: - Common in real-world implementations. - Regularly appears in LSA and architect-level interviews as troubleshooting and design validation questions. ### **3. Rule Resolution Mechanism** Add a new subsection under **Application Modularity** to demystify the **Rule Resolution Process**, which governs **which rule version is ultimately executed**. #### **Core Rule Resolution Factors**: 1. **Class Hierarchy**: Inheritance from most specific to general class. 2. **RuleSet and Version**: Highest version in scope is chosen. 3. **Circumstancing**: Based on property values or dates. 4. **Availability and Status**: Availability (Yes, Blocked, Withdrawn) affects visibility. #### **Example Scenario**: Given two versions of a data transform: - One in `Data-LoanApplication`, version 01-01-01. - One circumstanced for `.LoanType = "Personal"`. If a case has `.LoanType = "Personal"`, the circumstanced version is selected. #### **Why Include**: - Critical for designing **modular, scalable applications**. - Directly impacts **rule overrides, reuse, and maintainability**. - Frequently tested in scenario-based questions. ### **4. Pega DX API – Extending with Headless Frontends** Introduce a short section under “Extending Applications” or “User Interface Design”: #### **What is the DX API**: - A set of **RESTful APIs** that allow **external frontend applications** to interact with Pega cases and forms. - Supports **headless architecture**, enabling developers to decouple the UI from the Pega backend. #### **Integration Use Case**: - External frontend built in **React** displays a loan application form. - The frontend calls Pega’s DX API to render views and submit user input. #### **Why It Matters**: - Enterprises increasingly adopt **frontend frameworks** like Angular, Vue, or React. - LSA exams may reference **modern architecture patterns** like Headless UI or micro frontends. ### **5. Guardrails and Application Quality** Suggest adding a recurring section at the end of relevant modules explaining **Guardrails**: #### **What Are Guardrails**: - Pega’s design guidelines and **best practices** to ensure maintainable, upgrade-friendly applications. #### **Key Guardrail Tools**: - **Warnings Panel**: Lists violations like hardcoded values, deprecated rules, or missing documentation. - **App Quality Score** (App Studio): Reflects adherence to guardrails on a scale. #### **Common Violations**: - Using hardcoded values instead of references or parameters. - Creating flows with no SLA or with unreachable conditions. - Rules that are not reused or violate modularity. #### **Why It Matters**: - Guardrail adherence is a **grading metric in the LSA exam**. - Helps align technical implementation with enterprise standards. ### **6. Comparative Table of Flow Types** Add a **comparison table** summarizing **flow design choices**. This helps learners quickly choose the correct type during design or in exams. | **Flow Type** | **Purpose** | **User Interaction** | **Concurrent Execution** | **Use Case Example** | | --- | --- | --- | --- | --- | | Screen Flow | Step-by-step user form | Yes | No | Customer registration | | Process Flow | Automated background processing | No | Yes | Document verification | | Subflow | Reusable logic segment | Optional | No | Manager approval | | Parallel Flow | Execute tasks simultaneously | Yes | Yes | Background check + Credit check | #### **Why It’s Useful**: - Promotes **better flow design decisions**. - Makes it easier to choose between performance, reusability, and interactivity. - Matches LSA exam scenarios where **flow orchestration** is tested. --- # Application Design Extended (Additional Content) ### **1. Routing to Work Group Pool** While basic routing strategies such as **route to operator**, **route to work queue**, and **route using decision logic** are typically covered, it’s important to also mention the mechanism of routing **to a Work Group’s Default Work Queue** — especially in dynamic workload distribution scenarios. #### **Key Detail**: Pega allows you to configure routing **to a Work Group**, which **automatically places the assignment into the group's default Work Queue**. This design ensures: - Tasks are routed **not to a specific user**, but to a **shared queue**. - Any operator associated with that **Work Group** and **Work Queue** can **pull** and work on the task. - It's useful for **load balancing** in high-volume or rotating shift environments. #### **Example Use Case**: In a loan processing application, the “Verify Documents” assignment is routed to the **Work Group: LoanReviewers**, which has a default Work Queue called **LoanReview-Q**. Any user in that Work Group can work on the task based on availability. #### **Exam Tip**: This pattern may appear in questions involving **workload distribution** or **routing configuration traps**, where the routing target is a **Work Group**, not a specific queue. ### **2. Pulse Collaboration – Social Engagement Use Cases** Beyond its core functionality of **in-app communication and collaboration**, **Pulse** in Pega can also be extended for **social engagement integrations**. #### **Advanced Use Case**: Pulse can be customized to: - **Send notifications externally** (e.g., via email or integrated messaging platforms like Slack or Microsoft Teams). - **Receive inbound updates** or comments from external sources through APIs or webhooks. This allows **cross-team collaboration**, even with users who are **not logged into Pega**, thereby enabling use cases such as: - **Customer service agents** responding to social media complaints. - **Loan reviewers** getting alerts through enterprise chat tools. #### **Why Include**: While not standard out-of-the-box, these are **commonly implemented in enterprise solutions** and may be mentioned in **design scenario questions** or as LSA project discussions. ### **3. Circumstance Rules – Additional Types** Most Pega learners are familiar with **Property-Based Circumstancing**, but to ensure a well-rounded understanding, the following types should be briefly introduced: #### **a. Date-Based Circumstancing**: - Allows a rule to become active only **on or after a specified date** or **within a specific time range**. - Commonly used for: - **Time-sensitive pricing policies** - **Deadline-driven business rules** #### **b. Template Circumstancing**: - Used when the **circumstancing logic relies on multiple properties**. - Requires: 1. A **template rule** with property placeholders. 2. One or more **definition rules** specifying actual values. #### **Example**: A loan eligibility decision rule might use a **template** circumstancing rule with properties like `.LoanType` and `.CustomerSegment`. #### **Exam Note**: LSA exams often test scenario-based rule resolution involving **multiple circumstancing types**. A solid grasp of this topic is critical for resolving **which rule will be executed** in different contexts. ### **4. Queue Processor – Standard vs Dedicated** When covering **asynchronous processing** in Pega using **Queue Processors**, it's crucial to distinguish between the two types: #### **Standard Queue Processor**: - **Managed by the system**. - Shared across multiple operations. - Configured via **System Runtime Context**. - Typically used for **generic background tasks** such as audit logging or notification processing. #### **Dedicated Queue Processor**: - **Created and configured by the application developer**. - Offers **fine-grained control**, such as: - **Threading model** (number of threads) - **Delay settings** - **Error handling policies** - Best for **business-critical or performance-sensitive tasks** like: - Transaction posting - Fraud check processing - Integration queueing #### **Design Tip**: - Use **Standard** when tasks are lightweight and non-blocking. - Use **Dedicated** when tasks require **specific isolation**, performance tuning, or **error recovery control**. --- # Data Model Design (Additional Content) ### **1. Data Relationships – Advanced Join Table Reuse** #### **Many-to-Many with Keyed Page Group for Reusability** In complex many-to-many relationships, a **Join Table** class (e.g., `Data-Enrollment`) is commonly used to relate two entities (e.g., Students and Courses). To make this relationship more **reusable and extensible**, consider modeling the association using a **Keyed Page Group**. #### **Why Use Keyed Page Group**: - Allows the system to index relationships using a **meaningful key**, such as Course ID or Student ID. - Supports easy access and iteration over specific related records. - Enhances **clarity** and **reuse** across multiple case types or modules. #### **Example**: ```text Property: Enrollments (Page Group) Class: Data-Enrollment Key: CourseID ``` You can now access enrollment details using: `.Enrollments(C101).Status`, `.Enrollments(C102).Grade`, etc. This design is particularly powerful when you need **structured, indexed access to relationship data** in reports, UI sections, or integrations. ### **2. Data Classes and Rule Types – Enhanced Usage** #### **a. Reusing Data Classes Across Case Types** To avoid duplication and promote reuse, logic and properties encapsulated in **Data Classes** should be shared across multiple **Case Types** using **Page or Page List references**. #### **Best Practice for Reuse**: 1. **Create a reusable Data Class**, e.g., `Data-Product`. 2. In your Case Type, define a **Single Page or Page List**: - `.ProductDetails (Page)` → `Data-Product` - `.ProductList (Page List)` → `Data-Product` 3. Reference this page across steps, UI forms, validations, and transforms. This enables **centralized updates** and ensures **data standardization** across the application. #### **b. Data Transform – Iterating a Page List** A common real-world pattern involves **looping through a Page List** to process or aggregate values. #### **Example Use Case**: Sum total value of all order items. ```plaintext Loop: OrderItems() .TotalAmount += OrderItems().ItemAmount ``` This logic in a **Data Transform** accumulates item values into a single `.TotalAmount` property — often used in invoicing or summary screens. ### **3. Data Pages – Structural Clarification and Parameterization** #### **a. Page vs Page List Data Pages** Pega supports two structures for Data Pages: | Structure | Description | Example | | --- | --- | --- | | **Page** | Holds a **single object** | `D_CustomerDetails` for one customer | | **Page List** | Holds **multiple objects** | `D_AllLoanTypes` returning all loan types | This is frequently tested in exams — especially in **scope + structure** pairings like: - Node + Page List → Static reference data - Thread + Page → Case-specific dynamic fetch #### **b. Parameterized Data Pages – Use Case** Use parameters in Data Pages to fetch **context-specific** data. **Example**: ```plaintext D_CustomerDetails[CustomerID: "C1001"] ``` This pattern supports: - **Real-time queries** to external systems - **Dynamic data fetches** for form population - **Avoids hardcoding**, promotes reuse ### **4. Data Integration – Error Handling Strategy** When integrations (e.g., REST or SOAP connectors) fail, it is critical to handle them **gracefully and predictably**. #### **Best Practice: Use Error Handling Flows** - Configure **Flow-level error handling** via **Error Paths** or **Alternate Stages**. - Use **`StepStatusFail`** in activities or **`HasMessages`** condition in Data Transforms to detect failures. - Redirect users to: - A **“Retry or Contact Support”** screen - A manual processing queue via assignment This approach aligns with **robust enterprise-grade resilience design**, and is a **common exam scenario**. ### **5. Data Validation – Complex Conditions and Declarative Constraints** #### **a. Multi-Field Validation Scenario** Sometimes, validation requires **composite logic**: e.g., "Field A and Field B must be filled together, or both left blank." ##### **Declarative Expression or Validate Rule Logic**: ```plaintext IF (IsMissing(.A) AND NOT IsMissing(.B)) OR (NOT IsMissing(.A) AND IsMissing(.B)) THEN Show Error: "Please fill both A and B or leave both empty." ``` #### **b. Declarative Constraint – Under the Hood** Declarative Constraints are implemented via: - A **When rule** (evaluating the condition) - Bound to a property through a **Constraint rule** - Upon violation, Pega automatically displays an **error message** This is **reactive validation**, triggered whenever data changes — and commonly appears in rule resolution and form validation questions. ### **6. Performance Optimization – Monitoring & Indexing Practices** #### **a. Monitoring with Clipboard Analyzer & PDC** Use tools like: - **Clipboard Analyzer**: To inspect whether Data Pages are **overused, stale, or large**. - **Pega PDC (Predictive Diagnostic Cloud)**: To detect **high-frequency queries**, **slow report execution**, or **repeated page reloads**. These tools support **data-driven optimization** of performance. #### **b. Index Usage in Report Definitions** Exam questions often focus on **how to design efficient reports**. Emphasize: - **Filter and sort by indexed properties** (e.g., `.SubmissionDate`, `.Status`) - Avoid filters on **non-indexed computed properties** - Use **database views or pre-aggregated tables** when joining multiple large tables Failing to do so leads to full table scans — a **common performance bottleneck**. ### **7. Data Reuse and Governance – Enterprise-Level Practices** #### **Why Governance Matters** Strong data modeling governance ensures: - **Avoidance of rule duplication** - **Modular and maintainable data structures** - **Compliance with standards and enterprise architecture policies** #### **Best Practices and Tools**: 1. **Use built-on applications** to centralize reusable Data- classes. 2. Organize reusable assets in **shared RuleSets** (e.g., `Common-Data`, `Enterprise-Rules`). 3. Enforce **naming conventions**: - Page names: `CustomerInfo`, `ProductList` - Property names: CamelCase or enterprise-standard styles 4. Leverage **Application Quality Metrics** in **Dev Studio** to audit violations or unused rules. #### **LSA Perspective**: LSA exam scenarios often test **design consistency and governance**, especially in modular application setups and reuse strategies across business lines. --- # Reporting Design (Additional Content) ### **1. Report Definitions – SQL Bridge and Technical Foundations** #### **Clarification: Report Definition and `pzQueryBuilder`** A **Report Definition** in Pega isn't just a user interface configuration — it's a powerful tool that generates **SQL queries under the hood** via an internal engine called **`pzQueryBuilder`**. #### **Why This Matters** - The `pzQueryBuilder` engine **translates your visual report configuration** (columns, filters, grouping, etc.) into an executable SQL statement targeting the Pega database. - Understanding this helps developers **optimize reports** by predicting how filters, joins, and aggregates behave in SQL — crucial for performance. #### **LSA Relevance** - You might be asked to **analyze SQL output**, debug slow reports, or optimize Report Definitions without writing raw SQL — knowing that `pzQueryBuilder` builds the query logic is essential. ### **2. Report Types – Summary Reports, Drill Down, and Structure** #### **Clarification: Summary Reports are Extensions of List Reports** Although presented as separate types, **Summary Reports** are actually an **enhanced form of List Reports** with additional grouping and aggregation features (SUM, AVG, COUNT, etc.). #### **Key Insight** - A Summary Report starts with a **base List Report structure**, then applies **grouping logic and aggregate functions** on top of it. | Feature | List Report | Summary Report | | --- | --- | --- | | Tabular data | Yes | Yes | | Grouping | No | Yes | | Aggregation (e.g., SUM) | No | Yes | #### **Drill Down Capability** - Summary Reports can be configured with **Drill Down functionality** — allowing users to **click on a grouped or aggregated value** to open a **detail-level List Report**. - This provides a **hierarchical view**: from high-level metrics down to individual records. #### **Example** - Summary: “Total loan amount by status” - Drill-down: Click on “Approved” → See all loans with status = Approved #### **LSA Relevance** - Drill Down Reports are commonly used in dashboards and often feature in exam case studies involving **report reuse and navigation design**. ### **3. Reporting Performance – Debugging with Clipboard Analyzer** #### **New Tool Insight: Clipboard Analyzer for Report Debugging** During report execution, data retrieved from the database is loaded into the **Clipboard (memory)**. The **Clipboard Analyzer**, available in Dev Studio, allows developers to **inspect report-related data pages** and their structure. #### **Use Cases** - Inspect the output structure of a Report Definition (especially `D_` prefixed pages) - Validate whether grouping and aggregation results are structured correctly - Identify performance bottlenecks related to **large result sets** or **unnecessary data fetching** #### **LSA Tip** - In large-scale applications, you're often asked to diagnose reports that: - Timeout - Return incorrect structures - Overload memory Understanding how to **trace and analyze report execution** on the clipboard is key to providing architectural guidance. ### **4. Business Intelligence Exchange (BIX) – Positioning and Usage Differences** #### **Clarification: BIX vs Traditional Extracts** While both **BIX (Business Intelligence Exchange)** and **standard extract functions** retrieve data, their purpose and implementation differ. | Feature | Traditional Extracts | BIX | | --- | --- | --- | | Use Case | Real-time or UI-driven data export | Scheduled batch export for reporting | | Format Support | CSV, Excel via UI | CSV, XML, Relational DB | | Scale | Small to moderate | Enterprise-grade large-scale exports | | Integration Target | Users or UI download | BI systems like Tableau, Power BI | | Filtering/Incremental Support | Limited | Extensive filtering + incremental logic | #### **When to Use BIX** - Nightly data extraction for analytics - External warehousing for historical analysis - Scheduled export to downstream systems #### **LSA Perspective** - You may be asked to **design a reporting strategy** for enterprise analytics. - Knowing when to recommend **BIX over UI extracts** — especially for **offline, high-volume, or scheduled integration** — is essential. --- # Security Design (Additional Content) ### **1. Authentication – Real-World Use Cases and Platform Capabilities** #### **SAML vs OAuth: B2B vs B2C Contextual Usage** While both **SAML** and **OAuth 2.0** are supported in Pega, they are generally suited for different use cases: | Protocol | Best Fit | Use Case Example | | --- | --- | --- | | **SAML SSO** | B2B (Enterprise-level) | Employees accessing Pega via Okta or Azure AD | | **OAuth 2.0** | B2C / API Integration | Mobile apps or 3rd-party systems consuming Pega APIs | **Explanation**: - **SAML** is commonly used in **enterprise (B2B)** environments where centralized Identity Providers (IdPs) manage internal users. - **OAuth 2.0** is more flexible and lighter for **consumer-grade or system-to-system (B2C/API)** authentication, where token-based access is required. #### **MFA Support in Pega: Native vs External** Pega **does not natively implement a full-featured MFA experience**. Instead, it relies on **external Identity Providers (IdPs)** such as **Okta, Azure AD**, or **Ping Identity**, which enforce MFA as part of their login workflows. **Key Notes**: - MFA can be enforced **before** the user reaches the Pega application. - Pega acts as the **Service Provider (SP)** in a federated authentication model. - All verification (OTP, biometric) is handled **by the IdP**. ### **2. Authorization – Technical Details for ACL and Privilege Management** #### **ACL Numeric Access Levels (0–5)** Pega uses **numeric access levels (0 to 5)** to define what a role can do within a class. Here's how they work: | Level | Permission Description | | --- | --- | | 0 | No access | | 1 | View | | 2 | Modify (limited) | | 3 | Create | | 4 | Modify (full) | | 5 | Delete / Full Control | **Best Practice**: - Only **grant level 5 (delete access)** when absolutely necessary. - This numeric system is applied in **Access of Role to Object (ARO)** rules under each Access Role. #### **Privilege Combination Example (Multi-Factor Rule Gating)** In complex enterprise use cases, **multiple privileges may be required simultaneously** to access sensitive actions or rules. **Example Scenario**: To **approve a high-value loan** over $250,000, a user must: 1. Have `ApproveLoanPrivilege` 2. AND possess `FinanceManagerPrivilege` This is configured in the Flow Action or Activity using a condition such as: ```java @HasPrivilege("ApproveLoanPrivilege") && @HasPrivilege("FinanceManagerPrivilege") ``` This ensures **fine-grained, layered authorization**, often required in regulated industries like banking or insurance. ### **3. Data Security – Field Encryption, REST Transport, and Risk Considerations** #### **Encrypting Sensitive Fields – Technical Constraints** When using the **Encrypt** checkbox on properties (e.g., SSN, credit card numbers), it’s critical to understand limitations: - Encrypted fields **cannot be used in indexes** or **referenced in report filters**, as their stored values are unreadable to SQL. - Encrypted properties **should not be exposed in Search or Reporting** unless decrypted at runtime in a secure UI layer. **Best Practice**: - Use encryption only for **PII (Personally Identifiable Information)** such as: - `CustomerSSN` - `BankAccountNumber` - `NationalID` - Avoid encrypting high-usage keys like `CaseID`, `Status`, or `LoanType`. #### **REST API Transport Security – Enforcing HTTPS** For secure system-to-system integration: - All **external systems consuming Pega REST APIs** should access endpoints via **HTTPS only**. - Pega allows enforcement via: - Reverse proxy (e.g., Apache, NGINX) - API Gateway (e.g., Apigee, AWS API Gateway) - Direct server configuration (`tomcat.xml` or load balancer rules) **Why It Matters**: - Unencrypted API access (HTTP) **exposes token and data payloads**, violating compliance standards (e.g., PCI-DSS, HIPAA). ### **4. Audit and Compliance – Best Practices for Fine-Grained Logging and Performance** #### **Field-Level Audit Trail – When NOT to Enable** While **Field-Level Tracking** provides visibility into specific data changes, it can degrade performance if applied to: | Field Type | Reason to Avoid Audit Trail | | --- | --- | | Large Text Areas | High storage & query load | | Frequently Updated Fields | Excessive log volume | | System-generated fields | No meaningful user activity | **Best Practice**: - Limit field-level auditing to **key business fields** like `ApprovalStatus`, `LoanAmount`, or `CustomerType`. #### **Log Integration with SIEM Tools** To meet enterprise security and observability standards: - Pega logs (`PegaSecurity.log`, `PegaRULES.log`) can be **piped into SIEM tools** such as: - Splunk - QRadar - Elastic Stack (ELK) - This allows **centralized monitoring, anomaly detection, and audit compliance**. **Example Use Case**: Detect repeated login failures across nodes and raise alerts via SIEM dashboard. **LSA Relevance**: - In large implementations, you may be asked to **design a logging and monitoring architecture** — knowing how Pega integrates with existing security infrastructure is crucial. --- # Deployment and Testing Design (Additional Content) ### **1. Deployment Manager – Pega's Native DevOps Orchestration Tool** Although external CI/CD tools like Jenkins and Azure DevOps are widely used, **Deployment Manager** is Pega’s **official, built-in DevOps solution**, designed specifically to support model-driven DevOps for Pega applications. #### **Key Highlights of Deployment Manager**: - **Visual Pipeline Design**: Pipelines are configured through a **no-code visual interface**. No scripting or YAML files are required. - **Native Pega Integration**: Seamlessly integrates with: - **PegaUnit** tests - **Rule Coverage Analysis** - **Manual approvals** - **Static code scanning (guardrail checks)** - **Out-of-the-Box Stages**: Includes common CI/CD stages such as: - Package generation - Rule deployment - Test execution - Manual or automated promotion - **Cloud and On-Prem Support**: Can be used in both **Pega Cloud** and **on-premises** environments. - **Alternative to Jenkins**: While Jenkins or GitLab CI/CD can be used, **Deployment Manager is often the preferred choice** for Pega-native teams and is frequently mentioned in exams and certifications. ### **2. Static Code Analysis – Rule Quality and Coverage Assurance** Static analysis in Pega ensures that code meets quality, maintainability, and best-practice standards. #### **Key Tools and Metrics**: - **Guardrails Compliance Score**: - Evaluates rule configuration against Pega’s best practices. - Identifies **violations** such as hardcoding, unused flows, and unreferenced activities. - Available via **App Studio** and **Dev Studio**. - **Pega Quality Dashboard**: - Provides visibility into: - Rule compliance status - Application complexity scores - Outstanding guardrail warnings - Especially useful for **project managers** and **release managers**. - **Rule Coverage Tool**: - Shows which rules are **tested by PegaUnit cases**. - Highlights **uncovered rules** to improve test completeness. - Supports **regression readiness** for production releases. **LSA Relevance**: These tools form a critical part of **enterprise-grade governance** and are often included in design justifications and exam scenario responses. ### **3. DevOps Governance – Approval and Security Controls** In a secure deployment pipeline, **manual approvals** are crucial for controlling access to production environments and enforcing compliance standards. #### **Governance Mechanisms in Deployment Manager**: - **Manual Approval Steps**: - Can be inserted into any stage of the pipeline. - Typically required before **production deployment** or high-risk promotion steps. - **Role-Based Approvals**: - Approvals are tied to specific **operator roles** (e.g., `ReleaseManager`, `DevOpsLead`). - This ensures only authorized individuals can approve critical actions. - **Audit and Traceability**: - Each approval step is logged for **audit purposes**, helping satisfy compliance frameworks such as **SOX**, **GDPR**, and **ISO 27001**. **Best Practice**: - Configure approval tasks in Deployment Manager for: - Production environment - Schema changes - Emergency hotfixes ### **4. Branching Strategy – Best Practices for Collaborative Development** Pega supports **branch-based development**, which aligns with modern CI/CD workflows and enables **parallel, isolated development** across teams. #### **Recommended Strategy: Feature or Task Branching** - Developers create **branch rulesets** (e.g., `LoanFeature_v1`) to isolate changes. - Branching helps: - Avoid conflict in shared environments. - Facilitate **code review** before merging. - Support **trunk-based integration** with reduced deployment risk. #### **Branch Lifecycle in Pega**: 1. **Create Branch** in Dev Studio or App Studio. 2. **Develop and Test** isolated features or bug fixes. 3. **Submit Branch Review**: - Validate changes - Check for guardrail violations - Execute unit tests 4. **Merge to Main Ruleset**: - Manually or via Deployment Manager after approval. **Tools Used**: - Dev Studio (for individual rule review) - Deployment Manager (for **automated branch merge pipelines**) ---

Shopping cart

Subtotal:

Examination Introduction

Learning Method

Study Plan

Exam Center