Professional Documents
Culture Documents
System Architecture Understand the difference between a Business Rules Engine (BRE) and a Business Process Management System(BPMS)
Business Rules Engine (BRE) is a software system that manages business rules, it separates the business rules from the application code. Engine Types Inference Derives a conclusion based on a knowledge base Answers questions when a user or application submits them Example: Should this customer be allowed a mortgage? Reactive Detects and reacts to patterns of events occurring Performs an action automatically when a certain rule is violated Example: Alert a manager when certain items are out of stock No User Interface External systems communicate through open interfaces with the Rules Engine
Business Process Management System (BPMS) is a software system which allows for the direct execution of business processes. Removes the costly and time intensive development of process specific software Allows the full business process to be defined Can invoke external services to perform business operations Can send messages to human workers requesting they perform certain tasks Can call a Business Rules Engine to make automated decisions Provides a process driven User Interface
Pega Rules Business Rules Engine Separates business logic from your mission-critical applications and enables your enterprise to capture, manage and execute your business policies and practices Pega Rules Provides An inference engine to perform dynamic business decision making A reactive engine using declarative rules that are used only when underlying data changes This combination of rule types and processing approaches provides Rapid time to production Increased ROI
Java vs. JavaScript Originally developed by Netscape Is typically interpreted by a Web Browser Does not use a JVM Only similarity to Java is the C like syntax Java Enterprise Edition is a platform for developing and running distributed multi-tier architecture Java applications Formerly known as Java 2 Platform, Enterprise Edition (J2EE) The Java EE platform is defined by a specification Platform vendors must agree to certain conformance requirements in order to declare their products as Java EE compliant Multi Tired Architecture is a client-server architecture in which an application is executed by more than one distinct software agent The Java EE standard facilitates a multi-tiered architecture Often referred to as n-tier architecture
Client Tier
Web Browser
Java EE Platform Database Server
Example
Web Tier
Data Tier
Enterprise java Bean is a server-side component that encapsulates the business logic of an
application EJBs are deployed in an EJB container within the application server
Data Tier
Java Servlets are Java programming language classes that dynamically process requests and construct responses Servlets are deployed in a web container within the application server Typically generate HTML
Client Tier Web Tier Servlets Business Tier EJB Data Tier
HTML
Java Server Pages are Text based documents May contain HTML tags Contain Java specific tags May contain Java code pieces A JSP compiler is used to generate a Servlet from the JSP page Typically produces HTML
JSP
Servlet
HTML
Java Data Base Connectivity is an application programming interface (API) specification for database connectivity -Encodes database request statements in structured query language (SQL)
SQL
Users Work
XML
XML
Work Database
System Architects modify and create object instances that are saved to the database Known as Rules Rules are stored as XML documents which are written to the rule repository database At runtime the XML documents are parsed and converted to Java code for execution
Java
Rules Repository
Reusability and Hierarchy Design Define reusability and its impact on application design
Reusability Of assets across an organization is integral to the success of a project By gathering the right requirements, and applying the principles of reusability and class hierarchy design heuristics, you will always create systems that deliver on the value promised . Ultimately, the reusability requirements drive the selection of your class hierarchy design pattern .
Application Assets are specific to an application and common to more than one business unit
For example, all divisions across BIG have some type of Policy Administration Organization Assets common across multiple divisions or applications For example, LDAP integration
Generalized Define a common interface for its sub-application Defers some of or all of its implementation to application assets defined in its sub-applications The assets that an generalized application declares but does not implement are called generalized assets.A solution framework is an generalized application
Specialized
Applications that are not generalized are called specialized applications One Off application is a specialized one.
Classes and Class Groups/ Work Pools Create Classes and Class Groups
A Class group is an instance of the Data-Admin-DB-ClassGroup. A class group instance causes the system to store the instances corresponding to two or more concrete classes that have a common key format in a single database table. Class groups are commonly used to cause the system to store instances of similar or related Work- concrete classes together in one relational database table. While Creating the class group we need to specify the key for the group. Generally it is pyID.
Rule Sets and Rule Resolution Design and create a Rule set hierarchy and its prerequisites
A Rule Set is a container that stores a related group of business rules and provides: Security Version control Ability to deploy your application in a different Process Commander environment Rule Set Hierarchy Design
Rule Set Hierarchy at runtime Searches RuleSets in the order in which they appear in users Profile list User Profile list is assembled from: Requestor Organization Division Access group
Best Practice for Ordering RuleSets Personal RuleSets first (happen automatically) Production RuleSets RuleSets that are unlocked to allow changes RuleSets in an Application rule RuleSets that are locked Pega-ProCom, Pega-IntSvcs, Pega-WB Pega-RULES (always last and happens automatically) Rule Set Hierarchy at runtime When editing a rule Not possible to guarantee what the profile of the user is Therefore, RuleSet list of requestor is not used A RuleSet list is generated from the rule being edited and its prerequisites
Tips for Rule Set Hierarchy design Limit the number of RuleSets to the minimum amount necessary Create a RuleSet only if it has a reasonable chance of holding rules Use the Initial Setup Wizard to create the organizational RuleSet Use the Application Accelerator to create the first RuleSet needed for each application A RuleSet can inherit features from other, prerequisite RuleSets and also from lower-numbered versions of itself As a best practice, update the RuleSet Version rules created by the Application Accelerator to identify Pega-ProCom:04-02 as a prerequisite to each of your application RuleSets
Versioning at configuration management controls the exact application behavior, at development time it controls the access to the developers.
Significance of adding rulesets at Access Group: We can add one or more rulesets to access group when we think that security needs to be controlled basing on the specific job function. Assume that an application like Heart allocation request application is being developed for all the Project Managers in Virtusa for making resource requests for their projects. Then we can think of adding this application Ruleset in an access group called PM, so that all PMs across all the divisions in Virtusa can access this application.
You can use the Security tab to lock the Ruleset by requiring developers to enter a password when they update the Ruleset, or add or update version instances for the Ruleset. We can avoid tampering/misuse of rules (assets) by locking the rule set when the application is shipped for production.
Dynamic selection of rule involves the following steps Business process Product Organization Ruleset and version Date Time Circumstance Security We have to design the rule set hierarchy considering the process of rule resolution. At run time it checks for the order we have configured rule sets in the access group. We have to check for where exactly a particular rule fits in the organization and accordingly we need to create multiple rule sets to modularize the application into different rule set constituents.
Availability of the rules: Availability is an important aspect of any rule for it to be considered by Rule resolution algorithm. pyRuleAvailable property represents whether a given rule is available or not ? At any point of time, this property can be set with either of the following four values YES : Indicates that this rule is available. Rules with a Yes value are visible to rule resolution processing and executed. NO : Indicates that is rule is not available and become invisible to the rule resolution algorithm for all users (including yourself). The No setting is useful in experimentation and troubleshooting to assess the effect of two rule versions. Ex : If you are setting No status for a rule of version 01-01-03, still 01-0101, 01-01-02, 01-01-04 of same rule are visible to rule resolution algorithm BLOCKED : This is a stronger form of No because it affects all lower-numbered versions of the rule and it makes all lowered numbered including this version not to be visible to rule resolution algorithm. Note : A blocked rule does not prevent rule resolution from finding (and running) higher-numbered versions Ex: If you are setting BLOCKED status for a rule of version 01-01-03, only upper versions like 01-01-04.. of same rule are available to rule resolution algorithm. Lower version like 01-01-01 and 01-01-02 are not available for rule resolution algorithm FINAL : We need to set availability to Final if we want this rule to be available (equivalent to Yes), but want to prevent others from overriding this rule in any other RuleSet. A final rule can be superceded by a higher-numbered version (in the same RuleSet), but not by any version in any different RuleSet. A rule is said to be available only when its availability is either Yes or Final
Application Deployment Create a Rule-Admin-Product instance to create a zip file of an application and its data instances
Rule-Admin-Product instance allows you to specify in great detail which rules to save RuleSets (and versions) Data instances When rules specify criteria for data instances Creates a zip file containing rule and data instances to upload into a separate system
Understand the impact of RuleSet versioning on the deployment and migration of rules
You can use these tools to copy a product or RuleSet from one Process Commander system to another. (Also called migrating or moving, this procedure doesn't alter or delete the source rules.) For example, you can move a product from a smaller development or test Process Commander system into a production Process Commander system. The source and destination systems may have different servers, operating systems, database vendors, Web server software vendors and so on. Information inside the ZIP file consists entirely of XML documents in Unicode characters. Confirm that you have a working Operator ID with a PegaRULES:SysAdm4 access role on both the source system and destination system. Confirm that the Process Commander version number of the destination system is not less than the version number of the source system. Don't attempt to move a RuleSet created in version 05-01-06 into a system based on version 04-02-01. Review the RuleSets version rules to be included. Note the prerequisite RuleSets and versions they reference. If moving more than one RuleSet, note whether and how they are interdependent. On the destination system, access the Rules by Type Explorer. Confirm that the destination system includes all the prerequisite RuleSets and versions needed. On the source system, create a Product rule or Product Patch rule if you need to include data instances or an installation activity in the ZIP archive. On the source system, examine the All Checkouts report to make sure none of the rules to be migrated is checked out. Choose the View > Rules > All Checkouts menu item to produce this report. On the source system, use Rules per RuleSet, Version, Class report (in the Rule Reports area of the Monitor Activity slice to estimate a count of rules to be included in the ZIP archive. (The reports show only up to 10,000 rules. The ZIP archive may contain more than 10,000 rules.) Export the ZIP archive. Copy the ZIP archive to the destination system. Import the ZIP archive. Adjust your access group as necessary to provide access to the uploaded RuleSets and versions. Log off, then log in with the updated access group, and review the uploaded results. If they are satisfactory, this may be a good moment to lock the imported RuleSets and versions. Consider whether a new class group and work type structure is appropriate for deployment of the application.
Able to port an application and install it to run in parallel with an existing application
Following are the common steps to port an application 1. Save all the rules 2. Make a Rule-Admin-Product 3.Use the import archive tool to import the zip file
Rule-Application is the place where we specify the RuleSet lists so that this list can be shared across multiple user configurations. This ensures the following benefits: Reduce the namespace problems Smaller and efficient caching A user can have multiple applications. Allows users to have different privileges across different applications. Previously though multiple applications are allowed, its only through the mixed ruleset lists i.e., the Rulesets required are combined as a single long list. So multiple applications coexist in the single ruleset list. The PegaRules 5.1 is so developed to adopt the application focused user configuration. RuleApplication alone remains as the center where we mention the rulesets list, which the user has access to. If the user works with a particular application, then that particular ruleset list becomes the pxThreads active ruleset list.
Understand the connection between application rules, Rule Sets and rule resolution
In the rule resolution process the engine checks for the application rules which are configured in the access group and also the order in which the rule sets are configured in Rule-Application also important.
Units of Work Define and understand the differences between the basic units of work and their associated work classes:
Work-Object
A work object is the primary unit of work completion in an application, and the primary collection of data that a flow operates on. As an application is used, work objects are created, updated, and eventually closed (resolved). Every work object has a unique ID (property pyID), an urgency value, and a status (property pyStatusWork).
A cover is a work object that is also a parent to one or a few other related work objects. Typically one work party such as the customer party is present in the cover work object and also present in all of the covered work objects associated with it. The covered work objects are the children in a parent-child relationship. Internally, a cover is a work object in a concrete class derived from the WorkCover- abstract class. A cover work object provides a means to coordinate processing of the related work objects. Normally, the system resolves a cover work object once all its "member" covered work objects are resolved. The standard ticket rule WorkCover-.AllCoveredResolved alerts a cover flow that all the member work objects have been resolved.
Work-Cover
Locking a covered work object normally also locks the cover work object. This is desirable as the cover work object may contain totals, balances, counts or other derived information that require single-threaded access. Normally, the cover work object is added to the clipboard using a page named pyCoverPage; the covered work object is on a page named pyWorkPage. The covered work objects may be of various work types. However, the work type of the cover and the work type of the covered objects must all belong to the same work pool. A folder is a work object in a concrete class that inherits from the Work-Folderclass. A folder object holds a collection of one or more other work objects (which themselves may be basic work objects, other folders, or covers) providing access for analysis and reporting. By convention, the work object ID of folders has the format F-99999. In contrast to covers: One work object may be associated with multiple folders, but only with one cover. Members of a folder can belong to various work types, which need not be all in a single work pool. The relationships between folder work objects and their contents may be manyto-many.
Work-Folder
Understand when to inherit from work-objectversus work-coverGenerally we use Work-Object- inheritance for individual work objects, if we want to process multiple dependent work objects which are tightly coupled, covers (work-cover-) can be used. If the work objects are not tightly coupled then we can use Folders for resolution of multiple tasks.
Explain how a work object ID is defined A work object ID is the permanent, external identifier of a work
object, the value of property Work-.pyID. Prefixes and suffixes For every work object, either the prefix or suffix must be present. Normally the system assigns a permanent work object ID automatically as a work object is created. The standard utility activity named Work.GenerateID uses the standard properties pyWorkIDPrefix and pyWorkIDSuffix in its computation. For example, the prefix of work object Q-1432 is Q. The prefix of the work object MORT-763-K4 is MORT. The suffix of work object 15378-DR is DR. If you don't specify a prefix, the Work-.GenerateID activity uses W as the prefix and no suffix. The Work-Cover-.GenerateID activity uses C as the default prefix. Conventionally, the F prefix identifies folder work objects. The internal class Data-UniqueID supports work object numbering, and ensures that work object IDs are unique system-wide, not just within an application or organization.
Describe how flow execution moves between a work object and its cover during processing
When the flow belongs to class which inherits form Work-Cover- Cover related data can be seen in pyWorkPage. When the flow belongs to Covered class, Cover related information can be seen in pyWOrkCover and CoveredWork can be seen in pyWorkPage
Wizards and Accelerators Understand the purpose and output of external setup wizard
An optional step during installation or upgrade of a Process Commander system, the External Setup wizard creates a starter kit of rules and data instances based on a single input text value. Ordinarily, the External Setup wizard is not started from within the Process Commander portal. For example, if the installer enters Alpha, the External Setup wizard creates these instances: A RuleSet named Alpha and a Version 01-01-01 An organization Alpha.com, a division AlphaDiv in the organization, and a unit AlphaUnit within the division A top-level abstract class Alpha- referenced in the Organization data instance An application rule AlphaApp A workbasket named default@Alpha.com A work group named default@Alpha.com An Operator ID named Administrator@Alpha.com, linked to the Developer portal and the application rule.
Understand what needs to be created prior to and after running the Application Accelerator in advanced mode
Pre Application Accelerator set up
Create Rule Sets Add new Rule Sets to application rule Reset your Ruleset Access Create new classes Post-Accelerator manual Entry Complete Set up of your application Create RuleSet and RuleSet versions Create classes Add new class group to work classes
Understand the purpose and output of the Application Accelerator when run in advanced mode
Streamlines the process of setting up the foundation for your application Guides you through the initial development steps when you construct a new application Allows you to build the elements of your application from the Class Group down Application Accelerator Creates A RuleSet and version for the application which is added to your access group
Application Guardrails Identify the guard rails and describe their intent
Adopt an Iterative Approach Establish a Robust Foundation Do Nothing That Is Hard Limit Custom Java Build For Change Design Intent-Driven Processes Create Easy-To-Read Flows Monitor Performance Regularly Calculate and Edit Declaratively, Not Procedurally Keep Security Object-Oriented Too