Work Objects in Pega

In Pega, a work object (also known as a work item) represents a unit of work that needs to be processed within a business process management (BPM) system. Work objects in Pega are central to Pega applications, encapsulating all the data, rules, and processes required to complete a specific task or transaction.

Why do we choose the “PYCaseManagementDefault” option under work parties?

Without selecting this option, the flow displays a default screen provided by Pega when executed. To avoid displaying that screen, we have chosen the above option.

Draft Flow:

When we create a new flow, every flow, by default, will be in Draft mode. Draft flows are dummy flows.

“Draft On” means it is in draft mode and serves as a dummy flow for demonstration purposes. These are non-executable in production.  After completing all configurations for creating a flow, make sure to turn off draft mode.
To turn off the draft mode, go to the diagram tab and click on the icon “Draft ON.” . When we click on it, it will be displayed like “Draft Off.”

Understanding “creates a new work object” Check the box available under the process tab of Flow:

• When we select the checkbox ‘Flow will be executable,” that means we see the run option available under the action dropdown.
• Else Flow will be non-executable, which means that the run option in the action drop-down will not be available.
• Before you test it, make sure you turn off draft mode.

Technical Explanation:

• Selecting the option “Creates a new object” makes the flow to generate or create a work object when a transaction is initiated.
• This work object is a virtual entity created in the background and travels through the flow from start shapes to end shapes on its way to resolution.

Work Object in Pega:

A work object in pega  is a unique identification for each transaction. Work Object, also called “Case”.

Each work object has a unique identifier called Work Object ID or Case ID.

EX: Here, Work Object C-80 is created.

• C is called a prefix.
• 80 is a sequential numeric number.

Enter the data and submit.

• The work object holds the complete transaction data.
• After we submit the UI, work object data gets stored in the Backed Rule base table.
• Once a case is submitted, WO and data get stored in one of the tables called “Work Table ->” Pc _ Work.”

To see the Work Table and Work Object Created, go to Rule base< Open pg Admin4Environment.

• Each work object that we have created is a record of this table.
• Work Object ID gets stored in a column pyID.
• Look at the last column of the table.

pz PV Stream: In this column, WO data gets stored.

• All the entries—first name, last name, age, gender, etc.—get stored in this column.
• Here, the format of the data is BLOB (Binary Large Objects).
• BLOB: Binary Large Object.
• Just create a test flow in the impl class group.
• Open FW Class Group Flow and Save as to implementation class group.

Sava AS

Create and open

Now, run this flow.

C-104 is the work object created.

Go to DB and see the work table.

In the previous work table, the new work object C-104 is not available.

Now, check in at a different table.

Now, we have stored C-104 in a different table.
When developers create a flow in an implementation class group, the system stores the created cases in the Table pcPRIMVehicle_Work.

When developers create a flow in a Framework class group, the system stores the created case in that table.pc _PRIM _fw _Primerica _work

• When a work object is created by an implementation class group flow, it is an instance of the implementation class group.
• When a work object is created by the Frame Work Class Group Flow, it is called an instance of the Frame Work class group.

1. Work Object: It is an instance of a class group.
2. Class Group: It is an instance class of Work Object (S).

Additionally, to see the instance the instance of a class group. Single-clicking on the class group name displays a list of instances.

Similarly, click on the FW class group.

How does the process commander identify the exact work table to store work objects for a class group?

C-104 is an instance of the implementation class group PRIM (Vehicle-WWork

Whereas C-103 is an instance of frame work, Class Group PRIM-FW-Primerica-Work

Each instance has its own instance class.

Each instance class maps to one physical table in the rule base. Consequently, this ensures a direct correlation between the instance class and its corresponding table.

To see the mapping

Right-click on each class, as shown below.

View > SysAdmin > Database Table

Instructions for Mapping Rules and Work Objects in Pega

• The rule above is named the “Database Table Mapping Rule.” This rule maps a class to a physical table in the rule base.
• The system creates this rule however, a physical table in the backend named “pc_PRIM_FW_primerica_Work” automatically when it creates a new application.
• The system maps the table “pc_PRIM_FW_primerica_Work” to the Framework Class Group “PRIM_FW_primerica_Work.”

• The system stores an insurance case in its mapped table when it creates the case for the framework class group.
• The system maps every concrete class to a physical table in the backend.
• TThe system stores the instance of a concrete class in its mapped table.

Mapping Implementation Class Group:

• Similarly, open the mapping rule of the implementation class group.

• The system stores the instance or work object of the implementation class group in the table “pc_PRIM_Vehicle_Work.”
• The system stores a work object in the mapped table of its class group when it creates the work object.

Retrieving Mapping Table Name:

You can retrieve the mapping table name of a class group by following these steps:

Then Open the class group definition.
Next Then Scroll down after clicking on the definition under the work class.
Then Click the “Test Connection” button at the bottom.

Instance Class and Work Objects:

• Initially, all class groups are of type “Concrete.” However, they can transition into other types through various operations.
• Developers typically prefill keys with the out-of-the-box (OOTB) property “pyID.” However, they can modify or override this as needed.
• The “pyID” is the key for work objects and holds the work object ID value.
• Moreover In the Rule base work table, “pyID” is the column that stores the work object ID.
• Furthermore, once added and saved, users can never modify keys.

Conclusion

In summary, We choose the “PYCaseManagementDefault” option under work parties in Pega for its predefined configuration, adherence to best practices, simplified management, out-of-the-box functionality, flexibility for customization, and integration with other Pega features. This selection ensures efficient handling of work object in pega, allowing for streamlined case management and enhanced coordination within the system. By leveraging the PYCaseManagementDefault, we can maintain consistency, reduce configuration time, and ensure seamless integration with Pega’s robust features, ultimately improving the overall workflow and user experience.

More topics on Technology Click here