A new object in Product 360 always requires a unique identifier. In a multi server environment it should be guaranteed that a created identifier is always unique.
With Version 8 a new IdentifierGenerator service is available which provides the identifiers for root entities (sub entities are currently not supported).

Default Implementation

The default implementation to generate identifiers can be configured per entity.

By adding an entityParam child element on an entity in the repository you can specify an identifierPattern with two possible placeholders.

images/download/attachments/341017672/image2016-2-9_11_17_4.png

{entityIdentifier} = the identifier of the repository entity

{numericId} = the cluster wide unique numeric id with up to 16 digits.

Those placeholders can be combined as you like, for example: {entityIdentifier}: {numericId} would result in something like: Article: 1538732512590398

Without any entity specific configuration the default pattern which consists of the prefix(entity identifier) and an incremented number separated by an underscore. E.G. Article_1538732512590398

numericId

Starting with 8.1.1.04 the generic logic to generate the numeric id part of the identifier uses a database sequence.

With the first start of the servers the sequence "SEQ_IdentifierGenerator" will be initialized in the MAIN database schema.

The length, start and max value of the numeric id can be configured in the server.properties file:

# The database sequence 'SEQ_IdentifierGenerator' in the MAIN schema is responsible for providing unique identifiers.
# If the sequence does not exist yet it will be created and initialized with the following values.
identifierGenerator.length = 16
identifierGenerator.startWith =
identifierGenerator.maxValue =

If no startWith is given, the current system time in milliseconds is used as start value (this is due to backwards compatibility reasons with the old id generator logic).
If no maxValue is defined, the maximum of the sequence is used.

Since querying a sequence for the next number is always a database roundtrip, we request a batch of ids from it. By default we request 1000 ids.
In the plugin_customization.ini file you can adjust this setting by adding the preference (we do not recommend to adjust it without good reason thou):

# Specifies the increment size for the identifier generator i.e. the amount of numbers the generator may hold in
# memory before it needs to execute a query to the database to get the next number. If the number is set too small,
# the generator will have to query the database too often, but if the number is set too high it may result in
# bigger gaps in the generated numbers (the numbers hold by the generator will be lost after server shutdown).
# Default: 1000
com.heiler.ppm.std.server/identifierGenerator.incrementBy = 1000

As every server is requesting his own ids and those ids are shared across root entities and also the ids are requested in packages there are some things to know about those ids.
The only guarantee the system will give is that the id is unique across the whole cluster. There will be gaps in the ids especially if you just look for a single entity.
There will be ids not used at all since a shutdown of the server will not release already loaded ids.

Custom Implementation

A custom identifier generator can be contributed to the extension point: com.heiler.ppm.std.core.identifierGenerator

identifier: The identifier for the contributed generator. To overwrite a root entity generator, use the root entity identifier e.g. 'Article'

class: The class implementing the com.heiler.ppm.std.core.identifier.IdentifierGenerator interface.
You might want to use IdentifierGeneratorBaseImpl as base class which already provides a method to retrieve a cluster unique number (unique for all servers in the cluster)