Users of the Pega Platform can reuse rules across case types and applications. Rules are frequently reused by developers in their systems, ranging from single data pieces to entire processes. Reusing rules improves an application's quality while decreasing development time. Pega Platform classifies rules based on their reusability within an application. Each cluster is known as a class. Each application is made up of three different types of classes.

• Work Class : The Work class contains processes, data items, and user interfaces, as well as the rules that govern how to process a case or cases.
• Integration Class : The Integration class contains the rules that govern how the application interacts with other services, such as integration resources that connect it to a customer database or a third-party web server.
• Data Class : The Data class stores the rules that specify the data objects used in the application, such as a customer data type or order items data type.

We can create a work object in Pega in the following steps :

• Make a button that resembles a section or a header.
• After expanding the cell property within the button, click the action tab.
• Set an action for the button.
• A focus class and a flow name should be assigned to the button.
• Using "Param.prevRecordkey," we can obtain the current work object ID.
• Open the case by using "Obj-Open-By-Handle."
• Page-Copy is used to copy data from pagers.

DCO is an acronym that stands for Direct Capture of Objectives. It is the process of gathering, organising, and storing data with the help of Pega's integrated solution, the Pega Platform. DCO includes processes and tools for collecting and organising application artefacts. More importantly, this enabling technology is used by IT, business, and testing teams, as well as other resources. It saves time, effort, and money while improving project quality and people's lives.

DCO is not a methodology or a stage in the development of a methodology. It is not a single tool. Instead, the goals and benefits are to centralise the data so that it can be used continuously across departments at the appropriate time and level. DCO removes communication barriers by centralising linked application artefacts (objectives, requirements, specifications, and implementation rules). All resources have as-built documentation in real time and a unified view of the application.

DCO enables collaborative teams to model situations that end users of the application must address. The modelling and simulation tools enable users to perform a critical interim step after documenting the application but before incurring development costs to determine whether the software meets our objectives. We are less likely to be caught off guard in production if we can think through and work out solutions as part of the software development life cycle.

DCO can help organisations improve their efforts and use iterative processes. Issues and risks cannot be discovered and mitigated at the end of a project; they must be detected and mitigated in real-time. The software development process is more visible, allowing teams to constantly learn and improve. DCO technologies and best practises provide organisations with multiple ways to deliver go-live, increasing their return on investment and allowing them to consistently meet their goals.

A Service Level Agreement (SLA) specifies time intervals as a goal and time frame for standardising how your application solves work. It sets a deadline for completing the work. When we set a goal and a deadline, Pega creates a SLA. Service levels can be defined for processes, steps, stages, and classes as a whole.

SLA is divided into four levels. These are their names:

• Start : This is the time when the service level timer begins to tick. Everything begins at the zeroth hour.
• Goal : The goal is to specify how long the assignments should take. This step is calculated from the beginning of the assignment or case.
• Deadline : The term "deadline" refers to the amount of time it takes for a case or process to be considered late. It is computed from the beginning of the assignment or case.
• Passed Deadline : When an assignment or case has passed its deadline, the term "passed deadline" is used to indicate when further action should be taken. It computes the amount of time that has passed since the deadline for an assignment.

• SLA ensures that you and your service provider are on the same page in terms of standards and services. Setting explicit and measurable rules is critical because it reduces client dissatisfaction and provides remedies if commitments are not met.
• SLAs specify the steps to be taken if service commitments are not met. If your service provider fails to meet their obligations, the consequences for your company's reputation will be severe. As a result, if performance standards are not met, we must include consequences in the SLA.
• With SLA, your clients will be at ease. They have a contract to which they can refer to hold their service provider accountable and specify the type of service they expect. If the agreed-upon conditions are not met, they can mitigate some of the consequences by receiving financial compensation from their supplier.

• Screen Layout : Only used within a harness, screen layouts are typically used to create portals for an application.
• Dynamic Layout : A dynamic layout is a DIV-based layout that allows content to be displayed in various ways.
• Column Layout : A Columns layout allows you to display major content, such as a work item, alongside supporting information, such as an attachment.
• Grid Layout : Table layouts make data retrieval and comparison easier for users. Tables can be used as a versatile foundation for users to process large amounts of data in your apps. Tables in price comparison software, for example, can help customers find the best deal quickly.
• Tree Grid Layout : A tree layout can be used to view, navigate, and access the properties in pages in an embedded Page List property. The user can quickly extend and collapse branches of the tree to identify entries of current interest.

• Page-Validate : This method examines all of the properties on a page. If a page contains embedded pages, this method recursively validates all of the attributes. This method takes a long time and consumes a lot of system resources. To validate specified properties, use the Obj-Validate method in conjunction with the Rule-Obj-Validate rule.
• Property-Validate : This method is used to set limits on a property's value. Use the Edit validate rule in conjunction with the Property-Validate method to implement constraints. Multiple properties can be validated using the Property-Validate method.

A requestor type is defined by a Data-Admin-Requestor instance. The BROWSER requestor type, for example, denotes the characteristics of interactive user connections, such as guest connections, that use Internet Explorer or another web browser. For background processing, agents use the BATCH requestor type.

For the system name we specify during installation, Pega Platform includes four requestor types, as well as a reserved requestor type prpc.BROWSER for exceptional cases. We usually only need the four requestor types that include your system name. After installation, we go to Designer Studio => System => Settings => System Name to access a landing page tab where we can change the system name. When we change the name of a system, we create new requestor instances that correspond to the previous name's instances. If, for some reason, the previous system name did not include all requestor types, the missing requestors are also produced when the system is renamed.

Following are the different requestor types in Pega:

• Application : Listeners and external client systems use this to access the Pega Platform, such as via a service request (other than JSR-168 requests using Rule-Service-Portlet rules). In requestor sessions that use this requestor type instance, requestor IDs that begin with the letter A are used.
• Batch : This is used by background processing listeners, services, agents, and daemons. For requestor sessions that use this instance, the requestor ID starts with the letter B. When the PRPC:Agents access group is first implemented, all BATCH requestors have access to it. If you make a modification to Data-Admin-Requestor.When you BATCH so that it no longer has access to the PRPC:Agents access group and then upgrade the Pega Platform, the system may fail to boot.
• Browser : This is used to access the Pega Platform portal via HTTP or HTTPS from a web browser, or from a browser displaying a Pega composite application. For requestor sessions that use this instance, the requestor ID starts with the letter H. When the PRPC:Unauthenticated access group is first implemented, all BROWSER requestors have access to it.
• Portal : For HTTP access as a portlet, this is used in conjunction with Service Portlet rules. For requestor sessions that use this instance, the requestor ID starts with the letter P.

Rule resolution refers to the system's search technique for locating the best or most appropriate rule instance to apply in a given situation.

Rule resolution applies to all rule types except a few — classes that inherit from the Rule- class. Rule resolution has no effect on instances of classes derived from the Work-, Data-, or any other base class.

The following are some of the advantages of rule resolution:

• Across apps and organizations, rules can be shared.
• Rules defined at a lower level can override rules defined at a higher level.
• Even within a single rule-set, rules can have multiple versions, and security rules restrict which users can see and execute which versions. This facilitates application development, testing, and patching.
• A single Pega Platform system can host many apps, multiple organisations, and multiple versions of a single application with minimal conflict and interference.
• Applications can be built independently of one another, but they can all be based on the same set of locked (and thus unchanging) rules.

• Structure of the page
• Object Type of the page’s content
• Edit Mode supported
• Scope of the data page

A single value property that is visible as a column in a database table is an exposed property. A Storage Stream or BLOB column that is particularly structured contains aggregate properties, properties within an embedded page, and properties that are not exposed. Most PegaRULES database tables contain a Storage Stream column called pzPVStream.

Which properties are exposed affects the record selection actions in list view and summary view rules. In many cases, your database administrator can convert a property that was previously only saved within the Storage Stream column into a separate exposed column.

Single Value properties can only be exposed at the top level. If your application requires a column for embedded property values, the values can be transferred to the top level or indirectly provided using Index-class instances.