Question
Aegon Uk
GB
Last activity: 6 Aug 2025 9:00 EDT
CAD-C20603: AEGON - User Defined Functions (UDF) Road map - Questions
1. I believe we have two ways within Pega to extract data from the blob, a Java function, or the UDF (pr_read_from_stream). Is this correct?
2. My understanding is the UDF was introduced as this was more performant than the Java function. Is this correct?
3. I assume the CAD below means the UDF will be deprecated but the Java function will still exist?
4. The CAD below states that UDFs will no longer be operable from 26.x onwards, does this mean they will no longer work and need to be converted or replaced before upgrading to 26.x?
5. Are the UDFs only invoked from report definitions. If not, where else are they invoked? Is there anywhere else we need to look if we need to remove their use?
6. Is there a DSS (or equivalent) where we can force any rules which do use the UDFs to use the internal java function instead?
7. Ultimately is Pega’s direction of travel to get rid of the blob completely?
Accepted Solution
Updated: 6 Aug 2025 9:00 EDT
Aegon Uk
GB
@PEGAISAPDJA Answer from Pega support
1.I believe we have two ways within Pega to extract data from the blob, a Java function, or the UDF (pr_read_from_stream). Is this correct?
Yes,there are two methods to extract data from the blob: the Java function and the UDF (pr_read_from_stream).
2. My understanding is the UDF was introduced as this was more performant than the Java function. Is this correct?
The UDF was introduced to provide functionality to retrieve scalar property values directly from Blob in the database, but it is not necessarily superior in performance compared to the Java function.
3. I assume the CAD below means the UDF will be deprecated but the Java function will still exist?
The UDF functionality is being deprecated/removed. Java Functions (through RUF) will continue to work as before. As a best practice however, you should understand that customized functionality, such as code written through Java Functions, may introduce further challenges around debugging, maintainability, upgrades, peformance, etc.
4.The CAD below states that UDFs will no longer be operable from 26.x onwards, does this mean they will no longer work and need to be converted or replaced before upgrading to 26.x?
@PEGAISAPDJA Answer from Pega support
1.I believe we have two ways within Pega to extract data from the blob, a Java function, or the UDF (pr_read_from_stream). Is this correct?
Yes,there are two methods to extract data from the blob: the Java function and the UDF (pr_read_from_stream).
2. My understanding is the UDF was introduced as this was more performant than the Java function. Is this correct?
The UDF was introduced to provide functionality to retrieve scalar property values directly from Blob in the database, but it is not necessarily superior in performance compared to the Java function.
3. I assume the CAD below means the UDF will be deprecated but the Java function will still exist?
The UDF functionality is being deprecated/removed. Java Functions (through RUF) will continue to work as before. As a best practice however, you should understand that customized functionality, such as code written through Java Functions, may introduce further challenges around debugging, maintainability, upgrades, peformance, etc.
4.The CAD below states that UDFs will no longer be operable from 26.x onwards, does this mean they will no longer work and need to be converted or replaced before upgrading to 26.x?
Clients using UDFs in their production and staging envs (Production Level 5 and 4) must must either update or change their rules to no longer rely on UDFs before upgrading to Pega 26. UDFs will not be executable (for example) through Report Definitions and Connect-SQL rules. Clients can remove UDF usage by optimizing/exposing embedded properties.
5.Are the UDFs only invoked from report definitions. If not, where else are they invoked? Is there anywhere else we need to look if we need to remove their use?
UDFs are most often used through Report Definitions (to read unoptimized properties) or may be used in Connect-SQL rules. The best way a client can ensure that all UDF usages are identified and addressed is by reviewing the PEGA0167 alerts. For more information, please see this link: Identifying Properties That Rely on UDFs
6. Is there a DSS (or equivalent) where we can force any rules which do use the UDFs to use the internal java function instead?
The Platform already operates without UDFs by default. UDF installation in unnecessary for OOTB feature usage. In a system where UDFs are installed and actively used, clients must optimize their properties before removing the dependency. There is no DSS to prevent the execution of UDFs.
7. Ultimately is Pega’s direction of travel to get rid of the blob completely?
Pega's strategic direction is indeed aimed at reducing reliance on BLOBs and UDFs due to performance concerns, with a focus on optimizing properties instead.
Reference Link: Understanding Pega Blob and UDF | Support Center
HCA Healthcare
US
in Pega there are two main ways to pull data from the BLOB using Java functions or UDFs like pr_read_from_stream. UDFs were introduced to make reports faster by letting the database pull values directly without loading the whole object. Now, Pega plans to drop UDF support entirely starting with version 26.x, so anything using UDFs will break unless you fix it before upgrading. UDFs aren't just used in reports they can show up in custom SQL queries, external tools, and maybe in some old indexing rules, so you'll need to do a full check. There's no single setting to force everything to use the Java method instead. The bigger trend is that Pega wants you to expose properties upfront (optimize them) and move away from reading from the BLOB where possible.
Accepted Solution
Updated: 6 Aug 2025 9:00 EDT
Aegon Uk
GB
@PEGAISAPDJA Answer from Pega support
1.I believe we have two ways within Pega to extract data from the blob, a Java function, or the UDF (pr_read_from_stream). Is this correct?
Yes,there are two methods to extract data from the blob: the Java function and the UDF (pr_read_from_stream).
2. My understanding is the UDF was introduced as this was more performant than the Java function. Is this correct?
The UDF was introduced to provide functionality to retrieve scalar property values directly from Blob in the database, but it is not necessarily superior in performance compared to the Java function.
3. I assume the CAD below means the UDF will be deprecated but the Java function will still exist?
The UDF functionality is being deprecated/removed. Java Functions (through RUF) will continue to work as before. As a best practice however, you should understand that customized functionality, such as code written through Java Functions, may introduce further challenges around debugging, maintainability, upgrades, peformance, etc.
4.The CAD below states that UDFs will no longer be operable from 26.x onwards, does this mean they will no longer work and need to be converted or replaced before upgrading to 26.x?
@PEGAISAPDJA Answer from Pega support
1.I believe we have two ways within Pega to extract data from the blob, a Java function, or the UDF (pr_read_from_stream). Is this correct?
Yes,there are two methods to extract data from the blob: the Java function and the UDF (pr_read_from_stream).
2. My understanding is the UDF was introduced as this was more performant than the Java function. Is this correct?
The UDF was introduced to provide functionality to retrieve scalar property values directly from Blob in the database, but it is not necessarily superior in performance compared to the Java function.
3. I assume the CAD below means the UDF will be deprecated but the Java function will still exist?
The UDF functionality is being deprecated/removed. Java Functions (through RUF) will continue to work as before. As a best practice however, you should understand that customized functionality, such as code written through Java Functions, may introduce further challenges around debugging, maintainability, upgrades, peformance, etc.
4.The CAD below states that UDFs will no longer be operable from 26.x onwards, does this mean they will no longer work and need to be converted or replaced before upgrading to 26.x?
Clients using UDFs in their production and staging envs (Production Level 5 and 4) must must either update or change their rules to no longer rely on UDFs before upgrading to Pega 26. UDFs will not be executable (for example) through Report Definitions and Connect-SQL rules. Clients can remove UDF usage by optimizing/exposing embedded properties.
5.Are the UDFs only invoked from report definitions. If not, where else are they invoked? Is there anywhere else we need to look if we need to remove their use?
UDFs are most often used through Report Definitions (to read unoptimized properties) or may be used in Connect-SQL rules. The best way a client can ensure that all UDF usages are identified and addressed is by reviewing the PEGA0167 alerts. For more information, please see this link: Identifying Properties That Rely on UDFs
6. Is there a DSS (or equivalent) where we can force any rules which do use the UDFs to use the internal java function instead?
The Platform already operates without UDFs by default. UDF installation in unnecessary for OOTB feature usage. In a system where UDFs are installed and actively used, clients must optimize their properties before removing the dependency. There is no DSS to prevent the execution of UDFs.
7. Ultimately is Pega’s direction of travel to get rid of the blob completely?
Pega's strategic direction is indeed aimed at reducing reliance on BLOBs and UDFs due to performance concerns, with a focus on optimizing properties instead.
Reference Link: Understanding Pega Blob and UDF | Support Center