PEGA SAE-2 Materials | pega CSA Training in Bangalore

  • View
    73

  • Download
    14

Embed Size (px)

Text of PEGA SAE-2 Materials | pega CSA Training in Bangalore

  • SAE-2

    1. Effective Application Development with PRPC

    1. Introduction

    2. Building blocks of PRPC application

    i. Case types define what the application will do

    ii. Processes will define how the work defined for case or sub-case is completed

    iii. Processes are broken down into:

    1. Assignments that users need to complete

    2. Business logic that determines what assignment should be given to user

    iv. Rules defines and configures applications. Rules are the building blocks of application

    v. Rules has different categories:

    1. Data Model

    2. UI

    3. Decision

    4. Process

    vi. A class is a container for rules which defines the applicability (scope) of the rule. For e.g., SAE-HRServices-Data is a class.

    vii. An application is a collection of rules

    3. Managing building blocks of PRPC Application

    i. Ruleset is a deployment unit for a set or group of rules. It helps to identify, store and manage the rules.

    ii. Ruleset versions consists of 3 two-digit numbers. xx-yy-zz where xx = Major version, yy = Minor version and zz = Patch version

    iii. Inheritence: Application contains the most specialized version of reusable rules

  • iv. Rule Resolution: It is the process of determining appropriate rule to use when a process is run. The rule is selected based on the below factors:

    1. Purpose: Look for name and type of the rule and return if matches (e.g. Approve (Name) UI (Action))

    2. Availability: usability of the rule. If in development, does not return

    3. Applicability: Look for scope or if intended for the application

    4. Permission: Security permission to use the rule

    5. More (Refer to PDN) (This means there are more factors while resolving a rule using rule resolution process)

    v. PRPC uses a dual-inheritance model while resolving a rule.

    1. Pattern inheritance: Optional and involves parsing of class names. Enables to reuse Application classes

    2. Directed inheritance:

    a. Specified in the rule form which defines related classes

    b. Allows to access rules from PRPC standard classes such as Work-, Work-Cover, and @baseclass

    c. Is meant to reuse the objects (rules) provided by standard packaged classes.

    vi. Application explorer is the resource used to view the structure of the classes and rules

    vii. Rulesets and class inheritance enables to build reusable applications

    4. Guided Application Development using Guardrails

    i. It is about best practices and guidelines about situations that contains risky conditions or that might result in an undesirable outcome

    ii. Guardrail warning = Severity level + Warning type

    1. Severity levels:

    a. Severe: Data integrity related issues. E.g., Unreachable action in Data Transform

  • b. Moderate: Impacts maintenance. Property used in a report is not optimized for reporting

    c. Caution: Least severity level. E.g., Draft mode of process,

    2. Warning Type:

    a. Data Integrity

    b. Maintainability

    c. Performance

    2. Designing Enterprise Applications Using Case Management

    1. Case Management Design

    i. Cases:

    1. Have a life cycle

    2. It is a business transaction to resolve. It is what we do

    3. Have at least one process

    4. Contains: Actors, Tasks, Data, Status and History, Resolution

    5. Provides a more holistic view of a business transaction

    ii. Processes:

    1. The path a case may take. It defines how we do

    2. It is a way of ensuring a business transaction can be adapted to frequently changing business conditions

    2. Stage based case designing

    i. Case type:

    1. Defines tasks and decisions needed to complete a business transaction

    2. It is a collection of artifacts including data elements, UI Screens, processes and sub-cases, decisions, integrations

  • ii. Stage:

    1. Is a 1st level grouping for related tasks

    2. Represents:

    a. Transfer of case from one authority to another

    b. From one part of organization to another

    c. Significant change in the status of the case

    3. Best practice is to limit the count to 7 +/- 2

    4. Alternate stages:

    a. Special circumstances or exceptions

    b. Must be manually called

    c. Cannot be sequenced

    5. Resolution Stages:

    a. Stage where case can be resolved

    b. There can be more than one resolution state

    c. No automatic status changes

    iii. Exercise

    iv. Effective Case decomposition

    1. Steps:

    a. A distinct action taken to help resolve a case

    b. Should have a goal that can be expressed as a singular outcome

    c. Rule of seven: No of steps in a stage, +/- 2

    d. Single step: Single action by single user. Can be only a UI screen. No logic

    e. Multi-step:

  • i. Any combination of actions represented by different shapes depending on action

    ii. Involves multiple users

    iii. Logic between shapes

    f. Case:

    i. Automated single steps

    ii. Performed by PRPC

    iii. Have their own life cycle, but are still related to parent case

    iv. Focus on subset of data transferred from main case

    v. Usually involves different parties than the main case

    vi. Executed outside the context of main case

    v. Effective Process decomposition

    1. Role of a system architect during process decomposition is:

    a. Focus on areas of flows that may be reusable

    b. Look for manual steps that can be automated and

    c. Keep an eye on efficiency

    2. The flow diagram should provide a view into the process that is clearly and easily communicated in 5 minutes or less

    3. Use shapes for their intended purpose

  • 4. Consider limiting the number of shapes on any given flow rule to 15 or less

    5. Limit the number of connectors emanating from assignments to no more than 5

    6. Limit the number of results emanating from a decision shape to five or less

    vi. Guardrails for Case Management design

    1. Most common guardrail warning encountered during case design is Caution-Best practice

    3. Creating an Effective Data Model

    1. Best Practices for Designing a Data Model

    i. Two different types of data in an application:

    1. Flow Data:

    a. Info needed by application to determine what to perform and who to perform

    b. Can be gathered directly from participants but can also be retrieved from external sources including: LDAP, Databases and Web Services.

    2. Business Data:

    i. Provides context for a given task for a given participant

    ii. Data required from 3 different vantage points (User or Position point perspective):

    1. Process participant: Task level view of data. Immediate perspective of data

    2. Process Analyst: Data needed for reporting, metrics and analysis. Use historical metrics to improve process

    3. Process Designer: Implementation perspective of data. Define efficient data structure for development. Plan for future data changes and maintenance

    2. Best Practices for Managing Data