Administrative data and the PolicyCenter data model
- build/dictionary/data/index.html
gwb genDataDictionary
Public ID prefix
Each entity that you import into PolicyCenter requires a unique public ID. This is separate from the system ID that PolicyCenter assigns internally and uses for most system processing. Foreign key references between related objects use this public ID.
Adminsystem and
Salessystem), each source can have a contact entity with ID=5432.
Thus, Guidewire recommends that you use the following ID format so that the IDs do not
register as duplicates:origin:ID
By using this format,
the contact from the first system comes in as adminsystem:5432 and the contact
from the second system comes in as salessystem:5432. Thus, there is no risk of duplicate IDs. There is also the benefit
of knowing from which system the record originated.
Public IDs need to be unique only within objects of the same type. For example, all policy objects must have a different public ID. However, an account and a policy with the same public ID do not conflict with each other. Public IDs cannot exceed 20 characters in length.
Support for unique public IDs in a development environment
During development and testing of a PolicyCenter configuration, multiple developers can create administrative data in their own PolicyCenter installations. Administrative data includes users, groups, roles and so forth. You combine this data into a single production database at the end of the development cycle.
value of the following parameter in
config.xml:<param name="PublicIDPrefix" value="pc"/>
{PublicIDPrefix}:{ID}
If you have multiple developers, you must coordinate the public ID prefix so that no public ID prefixes overlap. For example, each engineer can use their initials or computer names as a public id prefix.
You can use the same prefix for multiple development and testing databases if you do not ever transfer data between them.
