Skip to main content

Generation of case ID mechanism in Pega

In this post, I am sharing case ID generation mechanism and how it can be customized.

First of all, case ID consists of three parts - [prefix]-[integer]-[suffix] as shown below.




When creating case IDs, you have options. You can add a prefix (usually the first letter of the case type), a suffix (optional), or both. The sequence number is also included automatically. Most people don't use a suffix, but it's available if needed. The prefix is set to the initial letter of the case type by default.


1. How to customize it

There are three approaches to change it. Try it in the order of 1, 2, 3. If what you're trying is not possible in the approach, try next one. FYI, if you update all of them, precedence is 3 > 1 > 2.


2. Sequence # generation mechanism

There has been a change in 8.3.1. Let me explain old / new mechanism and why it was changed. Be noted, this new mechanism was introduced only in PostgreSQL and it is not available for other database for now.

1) Old mechanism (~ Pega 8.2)


The latest ID is maintained in the database table (PC_DATA_UNIQUEID) per case type. Every time case gets created, system calls Work-.GenerateID and it queries and updates the value in the table. The ID is incremented by one and returned to app node.

(2) New mechanism (Pega 8.3.1 ~)


The latest ID is maintained in the app node. Database table (PC_DATA_UNIQUEID) is still used, but it only holds the chunk of scope (called "batch size"). For example, when the very first case is created, app node queries the batch size in the database. Since there is no entry in the table, system updates it to 1000 (by default). App node is assigned with 1-1000 scope. Hence the 1st case's sequence ID becomes 1. When next case is created on the same app node, it won't hit the database anymore and 2 is assigned immediately since the latest ID is maintained at app node (not database). This continues until either the app node exhausts the assigned scope (1-1000), or restarts. Be noted, this process happens per app node. For example, if app node #2 comes up, it is assigned with the next chunk (1001-2000). Hence, even if the latest ID in the app node #1 is in the middle of scope, app node #2 will start with 1001 regardless.


Why it was changed?

The old mechanism largely relied on database and performance was bad. Communication between app node and database is costly. Actually, the half of case creation process time was this ID generation. So, bottleneck issues were sometimes reported in a high load environment. More importantly, in a multi-node environment, the case generation can happen at the same time between nodes, and it could cause contention as the row is shared for all nodes. New mechanism reduced the number of communication between app node and database and increased the performance. Now ID generation takes only less than 5% of its case creation process time.


Business impact:-

As a side effect of this new mechanism, now the sequence ID jumps around between nodes or every time you restart the system. Prior to 8.3, the case was pretty much sequential - 1, 2, 3, 4, 5...etc. Now, it goes like 1, 1001, 2, 2001, 3001, 3, 4, 3002... etc. This is all caused by technical reasons. However, for some customers or business type, sequence # is important. So I would recommend you to consider with business people the balance - if, the sequence # is more important than performance, you can change the batch size. Or if you don't get bothered by sequence #, you can keep the default.


Batch size update:-

The default value is 1000, but you can change it by Dynamic System Settings. For example, if you update it to 1, system will behave like old version. Be noted performance gets slower in that case.

  • Dynamic System Settings: idGenerator/defaultBatchSize
  • Owning ruleset: Pega-RULES


  1. If you want the batch size to differ per case type, you can create another Dynamic System Settings (ex. idGenerator/P-/batchSize). Be noted, this is case sensitive and if you type "BatchSize" instead of "batchSize", it won't take effect.

  2. If you plan to update batch size, I would advise you to do so before you create the first case. This is because, if you update Dynamic System Settings after case creation, pyLastReservedID is updated to 1000 anyways, and when the app node is restarted or user connects to other node, system will create 1001 regardless of the value in Dynamic System Settings. This is one step behind, and customer may feel the change is not reflected immediately. Usually this should be okay because the Dynamic System Settings is included in the R-A-P and imported to production environment before the very first case is created. But if you care sequence ID even in Dev, I would suggest to do so before defining a case type to avoid unnecessary confusion.

Happy Learning :) :)

Comments

Post a Comment

Popular posts from this blog

Understanding the Lock Mechanism in Pega

Now, let's delve into the Pega lock mechanism. To begin, Pega employs both database-level locks, which are of shorter durations (usually in milliseconds), and Pega-level locks, which extend over more extended periods (determined by user operations, often a few minutes). While you have the option to disable Pega-level locks using the Optimistic locking strategy (discussed later), database-level locks cannot be turned off; they are an integral part of the infrastructure layer. Moving forward, I'll elaborate on Pega-level locks. 1. Fundamentals of Pega-Level Locks When an individual initiates an assignment, the system transitions the state to "Perform" mode and acquires a lock. This lock data is then added to the "PR_SYS_LOCKS" table in the database, where it is systematically managed. Throughout this phase, no other user can access the same assignment. Upon the user's submission or cancellation of the assignment, the state shifts to "Review" mode...
Post a Comment
Read more

How to set up JFrog Artifactory as a Repository in Pega.

Before delving into the topic, let's gain some understanding of what a repository is........... What is a repository? A repository is a centralized storage location where data, files, documents, or other digital assets are stored and managed. It serves as a single source of truth for organizing, versioning, and accessing these assets.  In the context of software development, a repository typically refers to a version control system, where developers store and manage source code, configuration files, documentation, and other project-related files. Version control systems like Git, Subversion (SVN), and Mercurial are commonly used repositories in software development. In addition to version control systems, repositories can also refer to databases, file systems, content management systems (CMS), or any other structured storage system used to manage digital assets. Overall, a repository provides a structured and organized way to store and manage digital assets, facilitating collaborat...
Post a Comment
Read more

Building a CSV File Download Function from a Page List

Consider a scenario where we want to download recently added table data from the screen into a CSV format for analysis. Today, we will explore how to accomplish this in Pega. An existing out-of-the-box activity named "pxConvertResultsToCSV" is available in the @baseclass, and you can utilize it without the need to create it from the ground up. The following example illustrates a sample screen: when the button is clicked, the Page List data on the screen is downloaded as a CSV file to the end user's local machine. 1.To begin, establish a Page List property. In this instance, I defined a Data class, "MyCo-Data-Item," and subsequently generated a Page List named "ItemList" in the Work class, referencing the Item class. 2.Position a table that references the Page List, and configure it to be inline-editable, allowing the addition of records directly from the screen. Additionally, position a button in close proximity to the table. 3.Configure the button by ...
Post a Comment
Read more