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