HSBC interview questions 1. Integrators 1. Connectors 2.

Services Connector A connector is a Process Commander programmatic component that defines and implements an interface between a Process Commander application acting as a client and an external system acting as a server. A connector is implemented by any of these ten rule types. Connect BPEL rules (Rule-Connect-BPEL rule type) Connect dotNet rules (Rule-Connect-dotNet rule type) Connect EJB rules (Rule-Connect-EJB rule type) Connect File rules (Rule-Connect-File rule type) Connect HTTP rules (Rule-Connect-HTTP rule type) Connect Java rules (Rule-Connect-Java rule type) Connect-JCA rules (Rule-Connect-JCA rule type) Connect JMS rules (Rule-Connect-JMS rule type) Connect MQ rules (Rule-Connect-MQ rule type) Connect SQL rule (Rule-Connect-SQL rule type) Connect SOAP rules (Rule-Connect-SOAP rule type)

You can use the Connector and Metadata accelerator to develop many connectors without the need to enter class rules, property rules, or connector rules. When debugging connectors, you can test using a simulator. Connectors support the research function, one of the six R terms defining business processes, by providing users with information retrieved from external systems Connector rule types are part of the Integration-Connectors category. Service A service is a Process Commander programmatic component that defines and implements an interface between an external application acting as a client and a Process Commander system acting as a server. Service BPEL (Rule-Service-BPEL rule type) Service COM (Rule-Service-COM rule type) Service dotNet (Rule-Service-dotNet rule type)

Service EJB (Rule-Service-EJB rule type) Service Email (Rule-Service-Email rule type) Service File (Rule-Service-File rule type) Service HTTP (Rule-Service-HTTP rule type) Service Java (Rule-Service-Java rule type) Service Portlet (Rule-Service-Portlet rule type) Service JMS (Rule-Service-JMS rule type) Service JSR94 (Rule-Service-JSR94 rule type) Service MQ (Rule-Service-MQ rule type class) Service SOAP (Rule-Service-SOAP rule type)

Services using the SOAP protocol to transmit XML-formatted messages are known as Web services. Multiple service rules supporting a single interface are known as a package, defined through the Service Package form. In many situations, the service instructs Process Commander to call a single activity. This is known as the service activity. Service rule types belong to the Integration-Services category. 2. What is the difference between Stateful and Stateless on service package? On the Context tab of the Service Package form, select Stateful when you want to maintain a clipboard across second and subsequent service requests. Select Stateless to perform a simple calculation from inputs: the service request arrives, your activity performs a calculation, and then sends the response, and nothing you've done is needed to process later service requests. On the Service tab of the Service SOAP form, the End requestor when done check box has no impact on stateless services. Regardless of the check box setting, when a service completes, the requestor is not destroyed so that Process Commander can re-use it for later service requests, thereby avoiding the overhead of creating another requestor. For Stateful services, select the End requestor when done check box only on a service that is the last one of a series of requests. This indicates that you're finished with the requestor, so that it can be destroyed. Earlier requests in the series have the box cleared, so that the same requestor is used throughout. Select Stateless if the services in this package can be executed by any requestor in of a pool of requestors, without regard to processing that the requestor performed earlier.

3. What is BLOB? A BLOB or Storage Stream is a column in a PegaRULES database table that contains property data in a compressed format. Most tables in the database contain a Storage Stream column, identified as the pzPVStream column. Don't confuse the Storage Stream with stream processing, an unrelated feature than involves generating HTML (or XML) text from HTML rules, XML Stream rules, and other rule types. In Oracle, Microsoft SQL Server and most other database vendor software, the Storage Stream is stored as a binary large object or BLOB data type. For example, an aggregate such as a Value List property can have multiple values. When the system saves an object that includes an aggregate property, its values are compressed together (or "deflated") into a single column. When the instance is later opened and placed on a clipboard, the column is decompressed (or "inflated"). When deflated, the property names and values are present in a single text value. This text value has a proprietary format; the values are obfuscated. Compressing or decompressing the BLOB column in PegaRULES database can be done by enabling or disabling the value DeflateStreams to true. To enable compression, change the value for DeflateStreams to "true."S. The pegarules.xml entry is as follows:
<node name="Compatibility"> <map> <entry key="DeflateStreams" value="false"/> </map> </node> To report the state of the database in the system (compression enabled or disabled), you can add the following line to the log4j.xml file: <category name="com.pega.pegarules.engine.database.PageDatabaseMapper"> <priority value ="info" /> </category>

4. How to debug connector and service rules? 5. Difference between Obj-List, Obj-ListView, Obj-Filter and Obj-Browse. Obj-Browse Executes an SQL SELECT statement; with the WHERE condition limited to exposed properties Obj-List-View Executes the selection, retrieval, and sorting capabilities of a list view rule, without report display These methods improve performance along multiple dimensions CPU, database demand, and clipboard size (memory) compared with the Obj-List command. (The Obj-List command is deprecated as of V5.4, with certain exceptions.) As demonstrated by one simple comparison, performance improvements with the ObjBrowse and Obj-List-View methods can be substantial. Results vary depending on the number of rows of the table, search criteria, and the number and size of columns returned, so a universal best approach cannot be determined.

Analysis Note these performance improvements:

The Obj-List-View method (with the ReadOnly setting checked) required 62% less CPU time, 55% less elapsed time, and produced a final clipboard size 92% smaller in bytes than the Obj-List method. The Obj-Browse method (with the ReadOnly parameter setting selected) required 61% less CPU time, 57% less elapsed time, and produced a final clipboard size about 20% smaller than the Obj-List method.

The bottom two rows show the substantial performance impact of removing the readonly restriction on the Obj-Browse and Obj-List-View cases.

For Obj-Browse, CPU times and elapsed times are still better than the Obj-List results, but by less impressive margins. For the Obj-List-View case, the entire property instances are loaded into each embedded page, resulting in a 41 Megabyte clipboard.

In other circumstances, percentages (and relative rankings) of the three methods will differ, depending on the hardware and software environment, the search criteria, the need to retrieve the Storage Stream (blob) column, and other conditions. However, the new V5.4 methods are significantly superior to the deprecated Obj-List method in a wide variety of situations. 6. Usually work object will save in pc_work. If we want to save in another table how can we do that?

Usually the work objects are mapped to pc_work table of PegaRULES database. To save to another table other than pc_work, in the above fig change the Table name to the table into which work object is to be saved.

To save the Work Object to external database table then change the database name to the external db and then enter the table in the Table name field to which the WO should be mapped. 7. How can we handle Exception handling in activities?

8. Define WorkList A WorkList is a list of open, outstanding (not complete) assignments ready and waiting for a user to perform them. Thus, a WorkList display shows selected instances of the Assign-WorkList class. Usually assignments appear on WorkList because an Assignment shape in a flow created the assignment. Assignment appears in order or assignment urgency. The assignment with highest urgency will appear first those with pxAssignUrgency. 8. Define Workbasket A workbasket is a named queue of open assignments that are not associated with an operator. A workbasket is defined by an instance of the Data-Admin-WorkBasket class. As the work item progress through a flow execution, the system creates assignments. Assignments may be associated with human users (appear on their WorkList) or with a workbasket. The contents of workbasket is set of assignments awaiting processing, ordered in decreasing urgency, similar to the contents of the WorkList. Flow uses Router Shape to route the assignment to the workbasket. Assignments leave a workbasket in three ways: Users who are qualified can remove an assignment from the workbasket to process the assignment.

An application can automatically route assignments in a workbasket to users based on work schedules, due dates, skills, workloads, and other factors.

Managers can transfer assignments from a workbasket to user worklists

Class Inheritances Inheritance is the capability of a class to use the properties and methods of another class while adding its own functionality. An example of where this could be useful is with an employee records system. You could create a generic employee class with states and actions that are common to all employees. Then more specific classes could be defined for salaried, commissioned and hourly employees. The generic class is known as the parent (or superclass or base class) and the specific classes as children (or subclasses or derived classes). The concept of inheritance greatly enhances the ability to reuse code as well as making design a much simpler and cleaner process. Two types of inheritances applied to during the rule resolution. 1. Pattern Inheritance 2. Directed Inheritance. Pattern Inheritance; When the system searches the any particular rule that was define on class, it will use the name-pattern inheritance to search all the classes linked in the hierarchy. During rule resolution the classes are always checked through pattern inheritance first. Direct Inheritance: Direct inheritance allows to specify or direct from what classes that current classes inherit. This inheritance does not have to follow name which includes pattern parent prefix. Chaining Forward Chaining Forward chaining is an automatic propagation of changes in one property value to changes on another property values or to indexes. In a Declare Expression rule, constraints rule, or Declare Index rule, you can establish required relationships among properties. When an activity step changes the value or a property that is defined in such rules, the system automatically consults an internal dependency network to see if other values are affected, and performs property value computations, indexing, and other processing as determined by the network. This is known as forward chaining. Backward chaining and forward chaining are phrases that describe the ways that declare expression rules perform their computations. Consider a spreadsheet with a column of figures and a total value. If the total is updated each time you change any of the inputs in the column, thats similar to forward chaining. In its simplest state, backward chaining would be if the total doesnt change until you click on the total or on a button that causes the calculation. But backward chaining is a

little more complicated than that. What if the values of one or more of the rows included in the total are also calculated values? Backward chaining would cause each of those values to be calculated, as well. Furthermore, if some calculated values were dependent on others, backward chaining would determine the correct order and perform the calculations in that order. When you configure a declare expression rule, specifying that it should calculate its value whenever inputs change implements forward chaining. Backward chaining occurs when you specify that it should calculate its value when the target property is used. For an example, consider three declare expression rules that calculate values for properties X, B, and D as follows:

Assume that X and B should be calculated whenever inputs change and the value of C changes. In this case, the chain of calculations begins with calculating B and ends with calculating X. That is a forward chain. Now assume that the value of X is to be calculated only when it is used. When the value of X is requested, Process Commander first determines the dependency network of calculations by traversing backward through the chain so it can determine the correct starting point for the calculation. Then it runs the declare expression rule for D, the declare expression for B, and finally the one for X. This is backward chaining. Model A model rule defines initial values of properties of a specific class. Models are instances of Rule-Obj-Model. Using Model we can set the values of the properties to required values. By convention a model name pyDefault is available for the most standard classes. However it is not reserved and has no special significance. Process Commander identifies the parent of the current class using the Parent field in the class definition, not by following full class hierarchy searches. (Thus, it uses directed inheritance first to find the parent, then pattern inheritance.) - After identifying a parent class, the system uses rule resolution to find the model of the same name as the current model. - The model in the highest class is applied first. The current model is applied last. Class group is an instance of the Data-Admin-DB-ClassGroup class. A class group instance causes the system to store the instances corresponding to two or more concrete classes that share a common key format in a single database table. The name of the class group is a prefix of the names of the member classes. Class groups are commonly used to cause the system to store instances of similar or related work object concrete classes together in one relational database table. This is known as a work pool. Work pools are referenced in access group instances.

Class groups correspond to tables in the PegaRULES database, not tables for external classes. Each external class has a corresponding unique database table instance (DataAdmin-DB-Table class) and so cannot be part of a class group. Work Group A Work Pool associated with an operator is a Work Group. User may have more than one work pool defined set to one by default (can be changed). These work groups are defined for the operator on Work Settings Tab of Operator form. Flows A flow rule describes the business process. Representation of flow is a network of shapes and connectors, each with associated parameter values. Flow govern, 1. How work items are created 2. How they progress through one or more flow executions. 3. And how they become resolved. Types of Flows: There are three types of flows that can define the business process. 1. Straight-Through process 2. Screen Flow 3. Starter Flow Straight-Through Process A flow rule that contains no assignments, and can execute from start to end with out human input. Screen Flow A flow that contains only assignments or decisions and meets other criteria. Starter Flow A flow that creates new work item is starter flow. Split-Join This shape in a flow supports asynchronous execution of flows by allowing two or more sub process to run in parallel.
Split Join parallel processing occurs only when considered at the business process level. Although two assignments exist, they both belong to a single work item. During the minutes or seconds that either user performs the assignment (thus updating the work item), the system locks the work item and so the work item is not available to the other user

Spilt-For-Each The shape causes multiple subprocesses to start, one for each page of a Page List property. Processing can resume after any one, or all, of the subprocesses end. Spin-Off A Spinoff shape starts asynchronous execution of a different flow, on the same work item or a different work item. Processing of the current flow does not pause or wait for results from the other flow.

A work item is the primary unit of work completion in an application, and the primary collection of data that a flow operates on. Workers using an application create, update, and eventually resolve and close work items. Every work item has a unique ID (property pyID), an urgency value, and a status (property pyStatusWork). In some organizations, a work item is known as a work item.

Agents Agent is an internal background process operating on the server that runs agent activities on periodic basis. Agent route work according to the rules defined in the application. They perform system tasks such as; 1. Sending email notifications about assignments 2. Outgoing correspondence. 3. Generating updated indexes for full text searching. 4. Synchronizing caches across nodes in a multiple node system. Agents are autonomous and asynchronous, the activities they call run individually on their own schedules, and one activity does not have to finish before another one runs. Agents are classified as 1. Master Agents 2. Standard Agents Master Agents The PegaRULES engine runs two master agents. Agent Manager: This master agent gathers and caches the agent configuration information that is set on the system PRPC starts up. Then at regular scheduled intervals it checks whether any new agents are queued. If they have the agent manager adds to the list of agents and generates schedules for them for each node. Requestor Manager: This master agent at a regularly scheduled interval checks the state of all the requestors in the system to see if any have timed out. If requestor has timed out, the requestor manager terminates it. The master agent behaviors are determined by settings in prconfig.xml file. Standard Agents By default, Process Commander relies on two standard agents: Pega-ProCom and Pega-RULES. If your system is using the PegaDISTRIBUTION Manager application, Process Commander also uses the Pega-IntSvcs agent.

The Pega-ProCom agent queue rule is configured to run two activities by default and two additional activities if you enable them: ProcessServiceLevelEvents compares the current time to the times specified as the goals, deadlines, and late times of the current assignments. This activity is enabled by default and it runs every 30 seconds SendCorr sends notify messages to users about assignments and outgoing correspondence to work parties. This activity is enabled by default and runs every 30 seconds. Email_CheckIncoming checks the inboxes of any incoming e-mail accounts that have been configured and if it finds messages, routes them according to the settings in the e-mail account. When enabled, it runs once every 30 seconds. GetConvertedPDFsFromPDM checks the PDM Requests table to see if any Word documents have been converted to PDF files. You enable this activity only if you are using PegaDISTRIBUTION Manager and you want to use it to convert Word files attached to work objects into PDF files. For information about this product, see the PegaDISTRIBUTION Manager for Process Commander Installation and Configuration, which is available on the Pega Developer Network (PDN) Agent Processing When Process Commander is started, the agents begin running and processing their tasks, as follows: Agent Startup 1. When Process Commander starts, the Agent Manager (master agent) gathers and caches all the agent configuration information for your system. 2. The Agent Manager launches the initial startup of all the agents by checking each of the Agents rules and reading all the agent settings for those rules. 3. For each Agents rule, the Agent Manager determines whether there is a corresponding Agent Schedule data instance for each node to use to start the agents. 4. If no Agent Schedule data instance exists for this node, the Agent Manager creates one by copying the relevant information from the Agents rule. Agent Queue Processing For each agent which is marked Enabled in the Agent Schedule, the Agent Manager checks its Queue Mode. Legacy or Advanced Mode 1. Agent Manager runs the agent activity. 2. The agent sleeps for the specified interval. 3. When the sleep interval has passed, the agent wakes up and begins processing from Step 1 of this section. Standard Mode

1. Agent Manager checks the agents queue for entries.

If there are no entries in the queue, this agent will go back to sleep for the specified interval - without running the agent activity - and then check again.

2. If one or more entries are found in the queue, the system opens the first queue entry. 3. The system runs the agent activity for each item in the queue. For each entry:

If agent processing succeeds, then the Agent Manager commits all deferred operations (saves or deletes) to the database. If agent processing throws an exception on any operations, then the Agent Manager does a rollback of all entries associated with that task.

NOTE: Unless other time settings are configured, the entries are processed in the order in which they were loaded into the agent queue. 4. When all entries are processed, the agent goes to sleep for an interval.

If the Pattern for this agent is set to Periodic, then the agent sleeps for the amount of time specified in the Interval column. If the Pattern for this agent is set to Recurring, then the agent sleeps until the next scheduled wake-up time, as specified in the Advanced dialog boxes. (For details, see Agent Scheduling Intervals.)

5. When the interval has passed, the agent wakes up and begins processing from Step 1 of this section Agent Queuing Before the processing tasks of the Agents by the Agent Manager, the tasks must be entered into the queue by the application processing. This entry of tasks can be configured during the execution of flow by the Assignment activity or configuring the activity in utility shape. When the task that gent can be accomplished. Method Queue-For-Agent is called to entry the tasks into the queue. We can also call the activity @baseclass.QueueForAgent which calls the same method. Add an additional step into your activity, at the point where the agent task entry should go.
1.

2. Enter a description of the task being entered, and then enter Queue-For-Agent into the Method field. 3. Expand the parameters for the Method field, and enter values for the parameters:

agent RuleSet agent Name MaxAttempts MinimumAgeForProcessing

4. Save your changes

Rule Resolution Rule resolution is the process used to identify which rules are applied to a specific business decision A cache contains data that has been copied out of one place and stored temporarily in another for easier access In the Process commander some caches are stored in JVM (Java Virtual Memory), some are stored in database and some or stored on disk. Caches stored in the memory include: 1. Rule Cache 2. Rule Assembly Cache 3. Conclusion Cache Caches stored on disk in the file system include: 1. LookUpListCache Cache 2. Static Content Cache. These caches can be tuned by the system administrators by using settings in the pegarules.xml file. System Pulse The functionality of the system pulse is to update the caches of each node on a multi node system. System Pulse is a part of standard PegaRULES agent. Any rule when updated, added or deleted to one of the rule tables in the database will fire a PegaRULES database trigger, which will then register the change in the pr_sys_updatecache table. Different rule changes are stored as events which are CACHE for any changes to the rule cache INDEX for Lucene changes DELLC when the lookup cache is deleted RFDEL when rule-file- deletes When these changes are recorded then the system pulse on each node wakes for every one minute and queries the pr_sys_updatecache table. The query retrieves the records which are not from the current node. This way all the caches across a cluster will have updated version of the rule. Rule Cache This cache hold the about the data reads that are done from the PegaRULES database for rule classes. Reading information from database is expensive process. So this should be done when ever it is absolute necessary. Methods such as below are used to retrieve data from the database, Object-Open Object-Open-By-Handle Object-Delete-By-Handle Object-Save Object-Delete

When these methods are used, the system first checks the Rule cache whether requested information is present in cache or not. If not then the system transfers call to the database, retrieves data and stores in rule cache. Next time when the PRPC requests same data then the call is set to cache and retrieves data from there which there by reducing the database calls. Any fact from the database for the first time stores it in cache. Rule cache settings can be done in pegarules.xml file as below
<node name="cache"> <map> <entry key="instancecountlimit" value="2500" /> </map> </node>

Rule Assembly Cache This cache stores the class files of compiled java code of a Rule. When the system calls a rule to be run, if that rule was never executed, the Rules Assembly process must: assemble the rule, including all the other rules required (for example, if this is an activity rule, it may call other rules) generate the Java code for the rule compile the code load and execute the resulting class file Thus, the full process for executing a rule is as follows: 1. The user calls a rule. 2. Rule Resolution occurs, to determine what rule should actually be run. 3. The rule is searched for in the Personal Cache. If found then that code is executed. 4. If not found, the source code for this Rules Java class is assembled but not compiled to generate the Java class name, which is used to check whether this code is in the Global Cache. If found then that reference is copied to the personal cache and the code is executed. 5. If the reference is not found, then the class name is used to check whether this code has been stored on disk as a .class file. If found the code is loaded by the Java more efficient to assemble and discard than it is to compile). 6. If the .class file is not found, the Rules generated source code is compiled, stored in the caches (and on disk), loaded via the Java classloader and executed. Rule Assembly cache settings can be in pegarules.xml file,
<node name="fua"> <node name="global"> <map> <entry key="instancecountlimit" value="20000" /> </map> </node> <node name="personal"> <map> <entry key="instancecountlimit" value="20000" /> </map> </node> </node>

Dictionary Cache This cache stores the information about class and property rules. Property Definition Cache This cache stores the information about all the Rule-Obj-Property instances used by the system. Static Content Cache This cache contains the files information that doesnt need to be processed constantly, like image or help files. The rules which contains static files are

Rule-File-Binary Rule-File-Bundle Rule-File-eForm Rule-File-Form Rule-File-Text

The static content data is actually cached in two places: on the client (each users PC) on the server On Client system the default time setting for caching can be set in the initializing the section of the pegarules.xml file.
<node name=Initialization> <map> <entry key=DefaultCachingTimeout value=43200/> </map> </node> Pega Guardrails 1. Adopt an iterative approach. 2. Establish a Robust Foundation. 3. Do nothing that is hard. 4. Limit Custom Java. 5. Build For Change. 6. Design Intent-Driven process. 7. Create Easy-To-Read flows. 8. Monitor Performance Regularly. 9. Calculate and Edit-Declaratively not procedurally. 10. Keep Security object oriented.