Rule Delegation

 Summary of Rule Delegation

• The purpose of Rule Delegation is to make the rule available in the production environment for customization for the business users.
• Can be delegated to either a Access Group or a specific user.

• The delegated rule should be available in the production ruleset which should be an unlocked ruleset.

Once the rule is delegated another link will be available in the left panel as configuration for the managers (refer above)

• All the delegated rule will be added to the table System-User-MyRules class.

Once we open the record related the particular Access Group it will open the all the delegated rule records with in that that Access Group. If we check the check box related the particular record it will ignore rule resolution. i.e. even though the never version of the delegated ruleset is pushed which has an undelegated rule version it will not be picked. Therefore, User is still able to make changes to the delegated rule.

Important considerations when deploying the delegated rule the production environment 

When taking a product rule, there is a condition to check if all the rules are unlocked. Since the production ruleset should be remained unlocked we must check on the check box to include unlocked rulesets

Alternatively, we may have to manually push the delegated rule as a data instance in the product rule keeping the check box unchecked to include only locked rulesets.

OAuth 2.0

Implementing OAuth 2.0 In Pega As Consumer

OAuth 2.0 is an open-standard authorization framework that allows third-party applications to obtain limited access to user accounts on an HTTP service, without the need for the user to share their credentials with the third-party application.

n Pega, OAuth 2.0 can be used to allow Pega applications to access data or resources from external applications, such as Salesforce or Google Drive. This can be useful for a variety of purposes, such as:

• Integrating Pega with a customer relationship management (CRM) system to access customer data
• Connecting Pega to a document management system to store and retrieve documents
• Integrating Pega with a payment processing system to accept payments

There are five Authorization grant types

1. Authorization Code
2. Client Credentials
3. Implicit (Pega doesn't support this type)
4. Resource owner password credentials (Use this approach when there is high trust between the applications as this requires password sharing)
5. JWT bearer (OpenID Connect token)

Authorization Code 

This grant type can be used when there is a user involved to grant the access. Imagine a scenario where the user is prompted to login to Quora with his Google or Facebook login.

Client Credentials

Use this grant type when two backend applications wants to OAuth2.0  protocol. There are two legs in this authorization type. First we are trying to get the access token with the help of App credentials. Next we try to get the access to the application using the access token.

Implementing OAuth2.0 with client credentials grant type

Step 1

Establishing the client credentials with the application

For further details click on the link and check the implementation information

Now you can run the API call using Postman and get the Access Token.

Eyonsis Interview Feedback

 1. How do you ensure the Pega application is secure?

2. What are the tools you use to debug services?

3. If there are multiple layers in Pega applications in which layer do we define the data classes when creating a REST service?

4. Should possess more LSA type of thinking

5. Security configurations in Integrations.

6. File Listeners/ Email listeners etc.

Email Listener

 Create A Case From Email

Create An Email Account

1. Records -> Integration - Resources -> Email Account

    Name the labels with the respective work class

2. Click Next and select the type of email account provider.

3. Now set the account setting as follows.

4. Now verify the connection using Test Connectivity link

OBJ and RDB Methods

 OBJ Methods

Obj-Save-Cancel will cancel the immediate member of uncommitted Obj-Save in the differed queue.

Rollback will cancel all the DB methods which are not committed prior to the method step in the differed queue.

RDB Methods

There are 4 main variations in RDB methods where we need to provide mandatory parameters when calling.

1. RDB-List --> Obj-browse
2. RDB-Delete --> Obj-Delete
3. RDB-Save --> Obj-Save
4. RDB-Open --> Obj-Open

Mandatory parameters

• Class Name - The class which is corresponding to datatable

• RequestType - This refers to the ConnectSQL rule. In practice it is possible to define separate ConnectSQL for each RDB method or alternatively we can define all the RDB methods in the same ConnectSQL rule since we have separate tabs for each RDB method.
  
  
• Access - Which is about which type of Database type we are connecting to eg:- Oracle, PostgreSQL, MySQL etc. we set it as All allowing all types of Databases.

Why do we use RDB methods?

Sometimes it's a bit difficult to create a query using obj methods due to complexity. In such situations we go for RDB methods we can directly write the query inside it which also improve the performance also since it will save the time to generate the SQL query also.

Enterprise Class Structure | Situational Layer Cake | Components

 Enterprise Class Structure (ECS)

Situational Layer Cake is a patent term for Pega Platform. It's about placing the source code facilitating the enterprise specializations.

Above is an example of how directed and pattern inheritance work in ECS.

Components 

A component is a collection of rulesets that create a small feature that can be added to any application created in the Pega Platform.

For more details on Components follow the below link

https://docs-previous.pega.com/sites/default/files/help_v73/basics/v6portal/landingpages/application/components.htm#:~:text=A%20component%20is%20a%20collection,ruleset%20to%20avoid%20naming%20conflicts.

After Pega 7.2, the platform has allowed to build applications on top of another applications restricting only to frameworks. Therefore, it's we can directly base application instead of a framework and also we can use components when building the applications. It further facilitates the further reuse of the existing functionalities. 

Agents in Pega

 Agents

Standard Agents and Auto Queue Management 

Standard Agent is the legacy version of the Queue Processor in Pega 8.In Pega 8 if we want to call it in a case step we need to call a utility shape and pass the required parameters AgentRuleSet and AgentName.

How the Standard Agent work

1. Once the item is queued, this particular item will be pushed to PR_SYS_QUEUES table, where the entire WO data will be copied.
2. Then once the Agent wakes up it refers the PR_SYS_QUEUES table and picks each item one by one and executes.
3. Once the Queue item is successfully executed the item will be removed from the table.(Agent activity will be executed to the number of times equal to the number of items in the table)
4. Once the Agent finishes executing all the queue items it will go to sleep.

Once the queue item is moved to PR_SYS_QUEUES table it will the table will hold property value called pyItemStatus where its value will be Scheduled

if the agent activity fails while executing an item in the list that item will be updated in the table with the status of Broken-Process

This entire process is managed by PRPC there for its called Auto Queue Management.