What are the main reasons for creating a case type into a dedicated ruleset?
The primary reason is for reuse. The ruleset can also be use as a separate component in the future where it can be added to other application stacks. Other reasons include:
- Achieving continuous integration (CI) branch-based development
- Encouraging case-oriented user stories using Agile Studio’s scrum methodology to manage project software releases
- Managing branches that contain rules that originate from different rulesets. When this occurs, a branch ruleset is generated, and the generated ruleset prepends the original ruleset’s name to the branch name
- Accommodating multiple user stories in a branch
- Simplifying the ability to populate the Agile Workbench Work item to associate field when checking a rule into a branch
You can refer to the following link for more details:
https://academy.pega.com/topic/modular-deployment-strategies/v1
By creating a dedicated ruleset for a case type, you can encapsulate all the related rules (such as flows, processes, data models, UIs, and integrations) within a single container. This promotes modularity and reusability, allowing you to easily package and transport the entire case type to different environments or applications.
Having case type-specific rules in a dedicated ruleset can improve performance by reducing the search space for rule resolution. When Pega looks for a rule, it only needs to search within the dedicated ruleset, which can be faster than searching across all rulesets in an application.
@VictorS65 i believe it’s a general best practice to create each case type into its dedicated ruleset (from the latest readings i did from Pega Academy). In our project, we have about 25 case types and continuously growing, and currently have not adopted this practice. We have modularized the application but not at every case type level. I’d be definitely consider adopting the best practice, while also being curious to see if there would be any growing overheads as well such as managing more number of rulesets and probably additional deployment pipelines. I’d assess both ends and consult client to find a right balance.