Key persistence

Each entity in the Zellis Intelligence Platform database has a related GET API as documented in our ZIP read APIs pages on this site. You will note that each entity is clearly named and aligned to the name of that entity, each has a primary key of the same name as the entity with Id appended to the name. For example the Workers end point has a primary key of WorkerId and the WorkerPost end point has a primary key of WorkerPostId etc.

An important note about these key values is that we don't guarantee persistence of the values. In the event of a full rebuild of the database it may well be the case that the key values for particular records will change. As such you need to ensure you cater for these potential events in your development and integration.

Production to Test copies

There is no concept of one Zellis Intelligence Platform database being copied from one environment to another. This is something that commonly happens in ResourceLink but we don't perform the same process with ZIP. We actually build/rebuild the database once the copy is done. This ensures all our integrity rules are complied with through our transformations and stored procedure executions. This also underpins the previous statement in relation to key persistence. In this instance, the database is built from scratch so will undoubtedly result in new key values.

Bulk events and the Notification Hub

Consideration must be given for any bulk events and what effect these may have on downstream integrations. Appropriate levels of validation and cross referencing should be applied to any given integration to ensure multiple events are handled. Loading of bulk data at source will result in bulk events being triggered.