I optimized a few embedded properties onto the main work class. By default, the optimized column was created as 32 characters (bytes). I needed 64, so I used Schema Tools to alter the column to 64 characters, then did a Revalidate & Save on the property rule.
After this change:
New cases created after the schema update correctly show the full 64-character value in the optimized column.
Older/existing cases (created before the schema change) still show only 32 characters in that column, the value appears truncated, even though I’d expect the full data to still exist in the BLOB (pzInsKey/storage stream).
Please suggest the solution for inflight scenarios.
One approach would be to trigger an update/re-save of the affected existing cases so that Pega re-evaluates the optimized property and populates the column with the full value. However, I would recommend confirming the supported Pega approach for bulk backfilling before updating production data directly. @SwatiS90
If the issue has been resolved, could you please share the resolution or any troubleshooting steps that worked for you? This will help other Pega Community members facing a similar issue.
@SwatiS90 I believe the issue is that the existing rows have not been repopulated into the exposed database column. In the past, I used an out-of-the-box Column Populator utility for this purpose, but I can’t find the documentation at the moment. Revalidate and Save only updates the property rule metadata; it does not backfill existing data from the BLOB (pzPVStream) into the database column.
As a quick validation, try opening and saving an existing record (for example, using Obj-Open followed by Obj-Save). When the record is saved, Pega should persist the current property value from the BLOB into the exposed column. If the column length has been increased from 64 characters, this test should help confirm whether the full value is being repopulated correctly. If I locate the Column Populator documentation, I’ll share it here for reference.
@SwatiS90@Bhumireddy here it is. In our client project, our team runs this activity regularly to repopulate existing property into its corresponding table column. This should launch and run the column population job.
@Bhumireddy hi, thanks for the info. I’m trying to use the same Expose API but getting 401 Unauthorized error. I’m using OAuth 2.0 and the same cilent credential works fine with /api/application/v2/cases but not with /api/SystemManagement/v2/Expose.
Did you need to set any other additional setting like access role, etc.?
In the client environment, I did not configure Authentication, but I was provided with the user ID and password. I tested it successfully using Postman.
Note : If you want test,Then Temporarily remove Requires authentication in Service Package.
@Bhumireddy Thanks for the additional information.
It worked fine. In my example, I had to change the auth type to OAuth 2.0 in the service package. I also used POST and HTTPs using Bruno (instead of Postman). This seems an easier approach once all the API connection and auth are set up correctly.
Both approaches should be valid. However, from a security perspective, I have seen client environments where inbound requests from tools such as Postman are blocked by network or firewall policies. In those situations, using an alternative approach such as a Pega Utility can be a viable option.
,
