Explore topic-wise InterviewSolutions in .

Spinoff join shape:

When one flow execution starts another flow execution that runs asynchronously and independently of the first flow execution, this is known as a spinoff. The first flow does not pause or wait for the second flow's results. The second flow could work on the same or a different work item than the first flow.

At the workflow level, spinoffs enable parallel processing of work. While one department or BUSINESS unit performs its functions for the work item at its own pace and according to its own flow, another department works on the same work item. Increased parallelism can reduce end-to-end resolution times, allowing for more efficient staffing and better customer service.

Split Join Shape:

On the Diagram tab of a flow rule, a Split Join shape can be found. This shape causes work item processing to divide into two or more distinct flow executions that run asynchronously and then rejoin later at runtime.

At the business process level, this capability allows for multitasking or parallel work processing. While one department or business unit performs its functions for the work item at its own pace and according to its own flow, another department works on the same work item. Similarly, if the split creates six subflows, each of them could be assigned to and worked on by six separate USERS who are all working on their assignments at the same time.

In this article, we discussed the most frequently asked interview QUESTIONS on Pega. BPM is a framework for managing an organization's working systems and processes. It is a top-down, holistic governance concept that focuses on improving CONSUMER loyalty through developing market practises. BPM is a coupled and persistent trend that is continually changing the best way to manage projects and partnerships all over the world, making them much more adaptable, robotic, and, to a considerable extent, innovative. As a result, Pega BPM provides the firm with remarkable business efficiencies.

To learn more about Pega, you can visit this LINK.

Forward chaining:

Forward chaining is an internal mechanism that allows changes in one property value to be automatically propagated to other property values or indexes. For EXAMPLE, if the area property is dependent on the length and width properties, forward Chaining will cause the area property to be recalculated if the length or width values change.

Backward Chaining:

Backward chaining allows for AUTOMATIC property calculation by executing the declarative rule when the value for the property is required rather than when the INPUT changes. If the area property is dependent on the length and width properties, for example, backward chaining forces the area property to be computed each time it is NEEDED. Except for the Rule-Declare-Expression, almost all declarative rules only implement forward chaining. We have the option of going forward or backward chaining in rule-Declare-Expression.

DECLARE Trigger Rules establish the relationships between events in your case types. Declare Trigger rules, which conduct activities in response to a case's specified event. As a result, you're able to develop adaptable apps that PROPERLY fit your company's requirements. When your application creates, changes, or deletes a class in the database, declare Trigger rules to start actions. Actions in a case, such as storing a case or modifying information in a case, are related to operations on classes. Declare Trigger rules can also be used to track property changes and for auditing.

Following steps must be followed to create a declare trigger in PEGA :

1. Click Create Decision Declare Trigger in Dev Studio's header.
2. Provide a descriptive name for the rule you want to establish in the Label area.
3. Indicate where your application SAVES the rule in the Context section:
   1. Select an application to store the rule from the list of application layers.
   2. Enter the class to which the rule applies in the Apply to field. Property values in this class and classes that inherit from it are monitored by the system at runtime.
   3. Select a rule-set and a rule-set version to store the rule in the Add to rule-set list.
4. Click on Create and Open.
5. Select a type of event to trigger the rule in the Trigger when an instance is list on the Triggers tab:
6. In the Condition section, in the When box, enter a When condition rule to run the rule only when a case fulfill given circumstances. The system checks the conditions at runtime and only EXECUTES the Declare Trigger rule if the When condition is true.
7. Enter the activity that the rule initiates in the Name field of the Trigger activity section.
8. Determine how the action will run in the Execute list.
9. Click on Save and the Declare Trigger would be created.

• Work List: 
  • A worklist is a list of open, unfinished assignments that are waiting for a user to complete them. As a result, a worklist display reveals selected Assign-Worklist instances. 
    A column that indicates a work item ID is commonly included in worklist presentations, but a worklist is not a list of work items. One work item may have two or more open tasks at any given moment. These assignments may appear on the worklist of a single user or on the worklists of multiple users.
    Assignments usually appear on a worklist because they were created by an Assignment shape in a flow. Assignments are ordered by assignment URGENCY, with the most urgent assignments appearing first and having the largest pxAssignUrgency value. If the user is inactive or exclusively works in a workspace other than Process Work, the information on the worklist display may become stale (outdated). To refresh the contents of the worklist, click the refresh symbol or interact with it.
• Work Basket: 
  • A workbasket is a named list of open assignments that aren't assigned to a specific operator. An instance of the Data-Admin-WorkBasket class defines a workbasket. An ORGANISATION unit, a work group, and a calendar can all be linked to a workbasket. During system installation, a default@pega.com workbasket is generated as a last resort for assignment routing.
    The system makes assignments as work items proceed through a flow EXECUTION. Assignments can be linked to either human users (and display on their worklists) or workbaskets. A workbasket's "contents" are a collection of unprocessed tasks ARRANGED in decreasing order of priority, comparable to a worklist's contents. The work queue is a term used to describe these assignments.

There are three ways that assignments leave a workbasket:

• Users who are qualified can process an assignment by removing it from the workbasket.
• Based on work schedules, due dates, talents, WORKLOADS, and other parameters, an application can automatically route assignments in a workbasket to users.
• Managers can move assignments from a workbasket to the worklists of their employees.

Following are the different ways by which we can measure the performance of our application in Pega :

DBTrace: The Performance Analysis Tool (PAL) has a feature called DBrace that provides a THOROUGH log of calls to the PegaRULES database. DBTrace shows the time spent on each operation as well as the SQL queries delivered to the database.

Performance Analyzer Tool: The Performance Analyzer (PAL) displays all of the performance statistics COLLECTED by Pega PlatformTM. You can utilise PAL to figure out how much system resources a single requestor session uses. The Performance landing page (Dev Studio > System > Performance) and the Performance tool in the toolbar both have PAL.

The features of PAL includes the following:

• To add reading
• To add reading with clipboard size
• To reset data
• To save data
• To configure DBTrace options
• To start profiler
• To show alerts

Alerts: Process Commander inserts a succession of text entries called alert messages to the performance alert log during application execution to identify mostly performance-related issues or faults. PegaRULES-ALERT-YYYY-MMM-DD is the most common name for the performance alert log.

Autonomic Event Services (AES): Exceptions are handled in the same way that alerts are. Exceptions generated by a Process Commander server are sent to the AES system via SOAP. The system parses the exceptions and REGISTERS them in the AES database's pegaam exception table. AES aggregates these records into work objects called AES exception items based on how frequently an exception occurs and the system events that produced those exceptions. The pegaam exception work table in the AES database is used to store these objects.

In Pega, Declare Index is a rule TYPE that exposes aggregate properties like Page/ List/ Group for reporting purposes.They are rule instances of the Rule-Declare-Index.  When an Insert/ Update/ Delete operation on the work object is followed by a commit, it helps to populate the corresponding index table. They can be found under the SysAdmin Category in Records explorer.

There are two ways to set up a declare index in Pega. They are as follows :

Using the Declarative Wizard Approach : 

1. Prepare ahead of time to identify the RuleSet and Version that will contain the wizard's rules.
2. Check existing Declare Index rules to SEE if the property has already been indexed. (Do not try to index a property that has previously been indexed with this wizard.)
3. In the Application Explorer, look for the embedded property. A Page, Page List, or Page Group property can contain the property.
4. To get to the Application Explorer context menu, right-click. From the menu, choose Index Property.
5. Select a RuleSet and Version in the FIRST pop-up window to store the rules generated by this wizard. Submit the form.
6. The class, property, and Declare Index rule produced are identified on a confirmation form. The indexing process has begun. To review the regulations, click the pencil symbol.

Using the Manual Approach :

• Determine which property(ies) on the source object will be used to create the index instance.
• Create a concrete class that extends the Index base class and holds the new index objects. The key for concrete classes generated from the Index base class is made up of three attributes in that order: pxInsIndexedKey, pxIndexCount, and pxIndexPurpose.
• Determine which database table the new indexes will be stored in. If NECESSARY, create a database table and associate it with the class using a Database Table instance. The table's three important characteristics must be visible columns.
• In the new index class, define Single Value attributes to RETAIN the values of the source instance properties. Confirm that all of these characteristics are exposed columns in the database with your database administrator, or change the database schema as needed.
• Choose a name for the Declare Index rule.
• Create a Declare Index rule, noting the source of each property value and the index property name it corresponds to.

An exposed property is a Single Value property that is viewable as a COLUMN in a database table. A particularly STRUCTURED Storage Stream or BLOB column contains aggregate properties, properties WITHIN an embedded page, and properties that are not exposed. A Storage Stream column named pzPVStream may be found in most PegaRULES database tables.

The record SELECTION actions in list view and summary view rules are influenced by which properties are exposed. Your database administrator can make a property that was previously only saved inside the Storage Stream column into a distinct exposed column in many circumstances.

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

When two or more actions try to update a CASE at the same time, the most recent action may overwrite data written by the prior action. Overwrites can cause data corruption or loss, causing delays in case processing and possibly resulting in an inaccurate case resolution. If an application supports several users at the same time, a case locking strategy is critical for data integrity.

In Locking, we configure an appropriate locking technique for each case TYPE to avoid data corruption or loss due to overwrites. Pessimistic locking and optimistic locking are two solutions that Pega PLATFORM enables to balance the need for user access with the necessity for data security.

Pessimistic Locking: 

When an application uses a pessimistic locking approach to open an object, it uses an exclusive lock. When a person or a system opens an object, they have exclusive access to it until the application unlocks it. Other users are unable to edit the item while it is locked.

For example, an underwriter examines an open life insurance claim to determine the amount of benefit that a claimant is entitled to. As the underwriter collects evidence and updates the case, a complex claim may necessitate extensive computations and referrals to third parties, and any additional modifications may OVERRIDE claim values and generate an inaccurate payout to the claimant. APPLY a pessimistic locking approach in this situation to prevent other users from overwriting data when the underwriter updates the claim and changes the payout amount.

Optimistic Locking: 

When an application uses an optimistic locking approach, it does not use an exclusive lock when opening an object. Instead, the item can be opened and edited at any moment by any user or the system itself. Before making any modifications to the item, the program checks to see if it has changed.

A manager, for example, may need to evaluate the most recent data for a given service request instance. A case worker may need to update the case at the same time as the manager does not need to update any information. Apply an optimistic locking approach in this situation to prevent the manager from locking the case and preventing a case worker from completing an assignment that would push the case toward resolution.

Case management is a software-based strategy to assist people with day-to-day tasks and automating work from start to end. Case management entails visualising your business process, encompassing people, data, and actions, in order to plan a flexible path that leads to your goal. By addressing business cases from start to finish and combining human activities with digital automations, we employ case management to produce goal-oriented solutions.

For example, we can simulate the process of accepting candidates after examining job applications, from gathering documentation from a candidate to CONDUCTING a job interview to receiving final approval. In case management, you can dynamically alter your work to respond to changing conditions, in addition to designing the most common path to resolution. When this STEP is relevant to the current circumstance, your business procedure can include an additional EMPLOYMENT interview. You can successfully address business procedures that follow an ambiguous or unexpected workflow with case management.

Following are the benefits of Case Management :-

• Visualization of business processes: Visualization allows users to better comprehend and assess a business process. Users can take the most efficient path to their business target after generating a visual depiction of the workflow, people, and data involved in the business process. Pega Platform is a simple editor that allows you to define your business process in a way that matches the work you need to do. You may transparently explain your business process to others, such as stakeholders, using visualization.
• Goal-focused business outcome: Users can concentrate on the most IMPORTANT aspect of a business process: achieving a specified goal. Users can achieve their business goals by following a predetermined path or by modifying the order of operations in response to dynamically changing conditions.
• Non-linear commercial actions are supported: Users can begin supporting business procedures that are most relevant to the current SITUATION on a flexible basis.
• Ad-hoc Tasks: By establishing dynamic tasks and allocating them to individuals, users can go beyond the established order of assignments. The assignment resolution is aided by adding instructions and defining goals and deadlines.
• Increased business adaptability: Users can shift a business process to a previous or subsequent milestone for more processing to guarantee that the task is completed completely.
• Increased transparency: Users can see exactly how a business process gets to a specific point, even after re-routing and additional processing, by following an audit trail and examining changes in individual fields and values.