Welcome to our latest blog post! Today, we're diving deep into the world of case ID generation mechanisms and exploring how they can be customized to fit your specific requirements. Join us as we unravel the complexities behind case IDs and discover the various options available for tailoring them to your organization's needs. Whether you're a seasoned Pega user or just starting out, this post is packed with valuable insights to help you optimize your case management processes. So let's get started!
To begin with, let's understand that a case ID is comprised of three components: [prefix]-[integer]-[suffix], as detailed below.
S. No | Example | Prefix | Sequence # | Suffix |
1 | C-100 | C- | 100 |
|
2 | 15378-DR |
| 15378 | -DR |
3 | MORT-763-K4 | MORT- | 763 | -K4 |
Customers typically have the flexibility to utilize either a prefix, a suffix, or both in conjunction with the sequence number. By default, the suffix is left blank, and in my experience, most customers tend not to utilize it. However, it's available as an option if desired. Additionally, the prefix is automatically included in your application rule, typically taking the form of the initial letter of the case type, when defining a case type.
Customization Method -
Customizing the case ID generation mechanism can be achieved through three distinct approaches. It's recommended to attempt customization in the following order: 1, 2, 3. If your desired customization cannot be achieved through one approach, proceed to the next one. Keep in mind that if modifications are made using all three approaches, precedence is given to Approach 3 over Approach 1, and then Approach 2. This systematic approach ensures that you can tailor the case ID generation according to your specific requirements effectively.
S. No | Approach | Comments |
1 | Application rule | You can update prefix in the application rule. Only prefix is changeable, and suffix can't be configured. You can only enter static string value (expression is not allowed). |
2 | pyDefault data transform | You can set. pyWorkIDPrefix (prefix), and .pyWorkIDSuffix (suffix) in the pyDefault data transform. You can use expression to set dynamic value. |
3 | Work-.GenerateID activity | You can override Work-.GenerateID for greater flexibility. Prefix, suffix, or sequence # (*) can be customized. |
In general, only a minority of customers express interest in customizing the generation logic for sequence numbers. While it is indeed feasible from a technical standpoint, I advise against it due to the associated risks and potential for unforeseen complications. Should you find it necessary to proceed with this customization, exercise caution to ensure that the generated IDs remain consistently unique and that performance issues do not arise in environments with multiple nodes.
Understanding Sequence Number Generation - Changes and Implications
With the advent of version 8.3, significant modifications have been introduced to the sequence number generation mechanism in Pega applications. In this segment, we'll delve into the differences between the old and new mechanisms, shedding light on the reasons behind these changes.
It's important to note that the new sequence number generation mechanism, as of now, has only been implemented in PostgreSQL databases. However, plans are underway to extend this functionality to Oracle and Microsoft SQL Server databases starting from version 8.7.
(1) Old mechanism (~ Pega 8.2)
In the previous system architecture, the latest ID for each case type was stored in the database table named PC_DATA_UNIQUEID. Whenever a new case was created, the system triggered the Work-.GenerateID process. This process involved querying and updating the value in the PC_DATA_UNIQUEID table. Subsequently, the ID was incremented by one and returned to the application node for further processing.
(2) New mechanism (Pega 8.3 ~)
In the updated system architecture, the latest ID is now managed within the application node itself. While the database table PC_DATA_UNIQUEID is still utilized, its role has evolved to solely storing a chunk of scope, known as the "batch size."
Here's how it works: When the initial case is created, the application node queries the batch size from the database. If no entry exists in the table, the system defaults to a batch size of 1000. Consequently, the application node is assigned a scope ranging from 1 to 1000. Therefore, the sequence ID of the first case is set to 1.
Subsequent case creations on the same application node no longer necessitate database queries. Instead, the next sequential ID is immediately assigned by the application node. This process continues until either the assigned scope is exhausted (1-1000) or the application node is restarted.
It's essential to note that this process occurs independently for each application node. For instance, if application node #2 is initiated, it will be assigned the subsequent chunk of IDs (1001-2000). Therefore, even if application node #1 has already utilized a portion of its assigned scope, application node #2 will commence with ID 1001.
Reasons for the Change: Enhancing Performance and Efficiency
The decision to overhaul the previous mechanism stemmed from several key factors. Firstly, the old method heavily relied on database operations, resulting in suboptimal performance. Communication between the application node and the database incurred significant costs, with ID generation accounting for roughly half of the case creation process time. This bottleneck issue became particularly pronounced in high-load environments.
Moreover, in multi-node environments, simultaneous case generation across nodes could lead to contention as the database row was shared among all nodes. Recognizing these challenges, the new mechanism was devised to streamline operations and bolster performance.
By shifting the responsibility of ID generation to the application node itself, the frequency of communications between the node and the database was drastically reduced. As a result, performance was significantly enhanced, with ID generation now consuming less than 5% of the overall case creation process time. This optimization has led to smoother operations and improved efficiency across the board.
Business Implications: Balancing Sequence Integrity and Performance
The introduction of the new mechanism has brought about a notable shift in the sequencing of case IDs, presenting both advantages and considerations for businesses. Previously, case IDs followed a sequential pattern, such as 1, 2, 3, 4, 5, etc. However, with the implementation of the new mechanism, the sequence ID now exhibits jumps between nodes or each time the system is restarted. For instance, IDs may appear as 1, 1001, 2, 2001, 3001, 3, 4, 3002, and so forth. While this divergence from sequential numbering is primarily driven by technical reasons, it can have implications for certain customers or business types where sequence integrity is paramount.
It is essential for businesses to carefully weigh the trade-offs between sequence consistency and performance optimization. If maintaining a strict sequential order of case IDs is critical for your operations or regulatory compliance, adjustments to the batch size may be necessary. Conversely, if the deviation from sequential numbering is acceptable and the priority lies in maximizing system performance, retaining the default settings may be preferable. Ultimately, striking the right balance between sequence integrity and performance enhancement is key to ensuring optimal outcomes for your business.
Updating Batch Size: Fine-Tuning Performance
The default batch size for ID generation is set at 1000, providing a balance between performance and sequence consistency. However, businesses have the flexibility to adjust this setting through Dynamic System Settings to better align with their specific requirements. For instance, reducing the batch size to 1 would replicate the behavior of the old version, resulting in sequential case ID generation. It's important to note that while this may address concerns related to sequence consistency, it can lead to performance degradation due to increased database communication overhead.
To modify the batch size, navigate to Dynamic System Settings and locate the setting named "idGenerator/defaultBatchSize" within the Pega-RULES ruleset. From there, you can adjust the value to suit your organization's needs. Careful consideration should be given to balancing the trade-offs between sequence consistency and system performance when making these adjustments.
Fine-Tuning Batch Size for Specific Case Types
For greater customization, organizations have the option to set batch sizes differently for each case type by creating additional Dynamic System Settings. For example, you can create settings like "idGenerator/P-/batchSize" to tailor batch sizes per case type. It's crucial to note that these settings are case-sensitive, so ensure accuracy in naming conventions for them to take effect.
If you're considering updating the batch size, it's advisable to do so before creating the first case. This preemptive approach ensures seamless integration with the system. Updating the settings after case creation may result in a discrepancy where the system defaults to a batch size of 1000, causing the creation of the next case to be one step behind. While this adjustment usually occurs during the Rapid Application Development (RAD) process before deployment to the production environment, it's particularly important to ensure sequence ID consistency even in development environments by setting batch sizes prior to defining case types, thus avoiding unnecessary confusion.
-Team Enigma Metaverse
Comments