Question
Scotia Bank
CA
Last activity: 4 Oct 2018 11:08 EDT
PEGA generated work-objet ID skipping sequence number. Any idea?
Hi,
Whenever creating a new case, sometimes the generated work object ID, skipping the sequence number. For example, a case is created with case id as "C-11055". The next case we create, generated with caseid "C-11337". Just FYI...we didn't customize anything to generate work object ID. Please suggest the possible reason for this behavior.
Thanks,
Chandra Das
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
Pegasystems Inc.
JP
"C-" is the default work id prefix for any work type which has no prefix defined on the application's cases&data tab.
And the sequence number will be shared by all work types with the same work id prefix.
Branch Banking and Trust Company
US
Similar issue: Found the mismatch b/w the pylastreservedid and actual highest id generated in custom app table
We had updated the latest 'pylastreservedid' in pc_data_uniqueid based on the actual value of highlest # generated in custom data table then It started generating correct ID values in sequence. Thank You for sharing!
Accepted Solution
Pegasystems Inc.
JP
"C-" is the default work id prefix for any work type which has no prefix defined on the application's cases&data tab.
And the sequence number will be shared by all work types with the same work id prefix.
'Work ID prefix' setting in Application rule supersedes everything, if configured. Your application case types might have this blank and hence as Chunzhi mentioned, prpc will set the case id prefix of 'C-' for cases of all types initiated from you application. Assuming case numbers ('C-11055' & 'C-11337')you referred are of same type and the difference is because the other sequential numbers after 11055 were taken by cases of other types.
This 'C-' value for pyWorkIDPrefix is initialized OOTB in pyDefault Data Transform of Work-Cover-. Since your work type (or work class) inherits from Work-Cover-, and the pyDefault Data Transform at your work type have 'Call superclass data transform' option enabled, prpc will thus initialize pyWorkIDPrefix to 'C-'. All this theory holds good for PRPC versions starting 6.2. Prior to this, meaning v4.2, v5.x and v6.1 have the work classes inherited from Work-Object- (and occasionally work classes that are designed to create covers are inherited from Work-Cover- and still had 'C-' as default cover id prefix) and pyDefault data transform (aka model rule) of Work-Object- have pyWorkIDPrefix set to 'W-' and was considered as the default work object prefix of those times.
Pegasystems Inc.
IN
- is the behavior noticed post deleting the work objects?
- and as Govardhan said please check pylastreservedid value...
copied below the sample script to delete work objects re-setting pylastreservedid value
delete from pc_data_uniqueid@
update pc_data_uniqueid set pylastreservedid=0@
delete from pc_work@
delete from pc_assign_worklist@
delete from pc_assign_workbasket@
delete from pc_history_work@
delete from pc_data_workattach@
delete from pc_index_workparty@
delete from pc_link_attachment@
delete from pc_link_folder@
commit@
Scotia Bank
CA
There are lot of other PEGA applications running on same instance. Hence 'C' WorkID prefix is not safe to have for my applcation. So I changed the Prefix now, don't see issue anymore.
Thank you for help.