Understanding work object IDs

By default, the system assigns a permanent work object ID automatically as a work object is created. The standard utility activity named Work-.GenerateID uses the standard properties pyWorkIDPrefix and pyWorkIDSuffix in its computation.

For every work object, the work object ID is required to contain either a prefix or suffix. For example, the prefix of work object Q-1432 is Q. The prefix of the work object MORT-763-K4 is MORT. The suffix of work object 15378-DR is DR.

If you don't specify a prefix (on the Details tab of the application rule), the Work-.GenerateID activity uses W- as the prefix and no suffix. The Work-Cover-.GenerateID activity uses C- as the default prefix. Conventionally, the F- prefix is used to identify folder work objects.

The internal class Data-UniqueID supports work object numbering, and ensures that work object IDs are unique system-wide, not just within an application or organization. (Accordingly, when two applications that both use W- as a prefix on one system are accessed by separate users, users of each application may notice gaps in numbering. Similar gaps are be visible if one application is used by two organizations with separate staff members. This is expected.)

Typically, the prefix and suffix are determined by a model rule — conventionally named pyDefault — for the work type or the class corresponding to the class group. The model is referenced on the Process tab of the flow rule that creates the work object.

For applications created with the Application Accelerator, the work object ID has a prefix of one to five alphanumeric characters, and no suffix. The worklist display and many standard reports assume that a work object ID is no more than 18 characters long, counting the prefix, the number, the suffix, and one or two dash characters. Your application can use longer object IDs but this requires you to customize all the reports and displays you use in the application.

For the work object IDs of your application, you can use prefixes only or both prefixes and suffixes. The standard function compareWorkIDs (in the Pega-RULES:Sort library) expects work object IDs in the form ZZZ-NNNN-ZZZ. That is, the IDs start with a prefix that ends in a dash character and (if there are also suffixes) end with a suffix that begins with a dash character.

Although every work object has a unique ID, your application may include "gaps" in work ID sequencing, arising from many causes. For example, if a Commit method fails and a Rollback occurs after work object W-6666 is assigned, the work object is not created and the number is never reused. This results in a gap between W-6665 and W-6667.

Accordingly, you cannot rely on work object numbers as an exact count of new work objects created during an interval.

When one system hosts two or more independent organizations using a common application, it is important that each organization have its own dedicated work pools and work types.

When required, you can relax this constraint by overriding the standard GenerateID activity, being careful to ensure uniqueness of work object IDs in the appropriate realm. For example, the Application Accelerator uses an activity PegaAccel-.GenerateID that allows users from multiple organizations to use this accelerator without collisions on work object IDs. However, consider carefully the long-term design implications of such an override.

In releases before Version 4.2SP5, work object numbering was unique only within organization; two separate organizations on one system could each have a work object numbered W-1234. This approach is not recommended for new applications.

Instances of the concrete class Data-UniqueID (stored in the PegaRULES database table pc_data_uniqueid) store the most recently assigned work object ID for a specific prefix.

The property Data-UniqueID.pyPrefix holds the prefix and is the key to instances of this class. The integer property Data-UniqueID.pyLastReservedID holds the highest assigned number. The property Data-UniqueID.pyOrganization, a key part, is not filled in by standard rules as was done in earlier Process Commander versions. This property value is left blank so that work object IDs are unique system-wide.