Application

• Bulkload Order
  (Root entity types only): Defines the order of entities for the import. This settings is mostly used in the import scenario where the user is able to import entity items of different types in one import. E.g. StructureGroups before Articles.
  Although the name suggest something else, this setting is not deprecated.

• Max System Id
  (Root entity types only): Defines the maximum id which is reserved for internal purposes; e.g. standard structure systems have a range from 1-8999, user systems start with id 9000.

Constraints

• Lower Bound and Upper Bound
  The lower bound property specifies the cardinality of this entity type, regarding it’s parent. Possible values are 0 or 1 for lower-bound, where 0 means the entity is completely optional, and 1 or -1 for the upper-bound, where -1 means an unlimited amount of objects, and 1 exactly one child object. A fixed definition of 1..5 for example is not supported yet.

General

• Entity Id Field Type

• Identifier
  Unique alphanumeric identifier of the entity type. The convention for entity type identifiers is: <Name>Type (e.g. ArticleType, ArticleLangType, StructureType, etc.).

• Identifying Field Type
  Defines the field type which identifies the entity type uniquely. Currently this property is used in the export to be able to use the entity type in a sub-module. You could say this field type identifies the primary key of the corresponding database table (combined primary keys are not supported).

• Object Name
  The object name of an entity type makes it accessible by property accessors. For example, to access the list of surcharges of an article, you would use: article.get("surcharges"). The returning value would be a list of ArticleSurchargeType objects.

• Report Type (mandatory for top-level entity types)
  The report type is a unique integer which identifies a root entity within the reporting framework uniquely. The report type property applies only to root entities.

• Status Proxy Field Type

Misc

• Container Entity Type
  (Root entity types only): Some entity types are unique only within a container. Like ArticleType which is unique only within a CatalogType, or StructureGroupType within a StructureType. This attribute defines the container entity type.

• Documentation
  This attribute can be used to document the repository content, it is not being used by any logic in Product 360 currently. Providing meaningful explanations about the entity type is recommended since the attribute might be used in the repository editor someday.

• Referenced-entities

• Searchable

Persistence

• AuditLog Entity Type
  (Root entity types only): Defines the sub-entity type which stores the audit log data for the entity type. See the documentation for audit log support on details. If no entity type is defined, no audit log is supported for this entity type.

• Deletion Date Field Type

• Deletion Mode

• Persistence Class Name
  Defines the class name of the corresponding class in the persistence layer. This attribute is used to create generic HQL statements, especially in the generic search functionality. Therefore it's a mandatory attribute for all searchable entity items as well as all entity types which support object rights

• Persistence xPath (mandatory for sub-level entity types)
  The XPath to the corresponding persistence objects.

• Revision Persistence Class

• Revision Property

• Supports Versioning
  (Root entity types only): Defines if this root entity supports the versioning functionality. This setting must never be changed, since in case it's false, the persistence layer of this entity is not capable of versioning.

Deprecated

• Class Name
  Deprecated setting which must, for compatibility reasons, be set to the same value as identifier.

• Help Context
  Deprecated: Has never been used

• Supports Bulkload
  Deprecated: Bulkload is not longer used.

Proxy Type

Each top-level entity type has a proxy type element which defines the construction details for the corresponding entity proxy classes. See the "Model" section of the programmer's guide for detailed information about entity proxies.

• internal-constructor-field-type-refs
  List of identifiers of field types which are needed for the "internal" constructor of the entity proxy.The order of field types must correspond to the internal constructor of the entity proxy. The internal constructor is absolutely mandatory for an entity proxy.

• external-constructor-field-type-refs List of identifiers of field types which are needed for the "external" constructor of the entity proxy. The order of field types must correspond to the external constructor of the entity proxy. If the entity proxy has no external constructor this field can be empty.

• mixed-constructor-field-type-refs
  List of identifiers of field types which are needed for the "mixed" constructor of the entity proxy. The order of field types must correspond to the mixed constructor of the entity proxy. If the entity proxy has no external constructor this field can be empty.

• proxy-class-name
  Fully qualified class name of the entity proxy implementation of this entity type.

Entity Type Param

Generic list of key/value parameters which can be defined for every entity type. These parameters
can also be used by customizings as the values can be interpreted at runtime. The following list of
parameters are supported currently:

Logical Key Type

As described before, entity types are distinguished by the dimensions they have. So, with the logical keys, one can define these dimensions for an entity type. Every logical key type adds one dimension to the corresponding entity type. For example, the ArticleLangType has only one logical key for "language" which means that this entity type has one dimension, ArticlePriceType has several more. Any changes of the logical keys would make the complete business logic of this entity type useless and would lead to damages to the system. The logical key types correspond for example also to the unique indexes in our database. A change of the logical key type needs also a change in the unique index.
The properties of logical key types

• class-name
  If the logical key has no direct 1:1 relationship to a field type, a class name must be set which defines the business data type of the logical key.

• documentation
  This attribute can be used to document the repository content, it is not being used by any logic in Product 360 currently. Providing meaningful explanations about the logical key type is recommended since the attribute might be used in the repository editor someday

• field-type (either the field type or the class name are mandatory!)
  Most logical keys directly refer to a field in the same entity type. So all needed information regarding data types etc. will come from this field type then. This property is optional, if not set, a class name is needed.

• fragment-expression
  Can hold additional information which is needed in certain specific fragment implementations, usually its empty. The usage is up to the fragment implementation.

• identifier
  The unique identifier of the logical key type. All identifiers in the repository must be unique over the whole repository. The naming convention for logical key type identifiers is: <EntityTypeName>_LK_<Name of Logical Key> (ArticleLangType_LK_Language, ArticlePriceType_LK_Buyer, etc.)

• persistence-class-name
  Defines the persistence class of the logical key, if no field type is set. Defaults to the class name if omitted.

• persistence-filter-name
  Defines the name of the Hibernate filter definition which should be used for the logical key. If omitted no hibernate filter will be used. This attribute has two parts which are separated by a colon (":"). The first value is the name of the filter definition and the second value is the name of the filter parameter. The filter definition must correspond to the persistence model filter annotations.

• xpath-expression
  Deprecated and no longer used since Heiler Product Manager 4.6.

Field Type

Field types represent concrete data fields in the persistence storage. The attributes of field types:

• class-name
  Defines the business data type of the field with the fully qualified java class name. Fields can have different persistence and business data types.For example, the field ArticleType.Catalog is a "Catalog" from the business point of view, from the persistence storage it’s a simple CatalogID which is just an integer. The generic data access facilities use the ConvertUtils of Product 360 (and it’s extension point) to manage the conversion from business to persistence data types and vice versa. More complex conversions (multi-column to one object etc.) must be done in the corresponding mediator implementation.

• documentation This attribute can be used to document the repository content. Providing meaningful explanations about the field type is recommended since the attribute might be used in the repository editor someday. Besides this, if this attribute contains "ESCAPE_VALUES", then semicolons are escaped for this field type (therefor the class-name must be "java.lang.String" and upperBound != 1).

• fragment-column-access
  The physical access path defines the table and the column in the database, and can additionally define a parameter name for the mass-data access. The syntax is: <Table>.<Column>#<ParameterName><Table>= he table in the database, case sensitive, no escape characters like ‘[ ]’ or ‘ " " ‘ <Column> = The column of the field in the table, case sensitive, no escape characters like ‘[ ]’ or ‘ " " ‘ <ParameterName>=The optional parameter name for generic data access, if omitted, the column name is used for parameter name.

• help-context
  The help context holds the path to the help page which is responsible for the field. Currently the help context is not used.

• identifier
  The unique identifier of the field type. All identifiers in the repository must be unique over the whole document. The naming convention for field type identifiers is: <EntityTypeName>.<Fieldname> (ArticleType.Ean, ArticleLangType.DescriptionShort)

• inactive
  The property defines if the field type is inactive for this repository. This flag has been added to provide a single point of enabling or disabling reserve fields of the repository. If set to true, anyone who tries to access the field will get an exception, since the field has not been added to the business model at all. This attribute is an exception of the general "do not edit the types area" rule, since in customizing you need to change this to false in case you want to use a reserved field.

• internal
  Is just a hint to those who want to edit the types area, that if they change this field, nothing is gonna work any more. However, you should never change the types area unless prior consultation with Informatica.

• lower-bound and upper-bound
  Defines the cardinality of a field. Normally fields are 0 to 1 or 1 to 1, seldom 1 to many (ArticleLangType.Keywords for example). A lower-bound of 0 means the field is optional for the entity, 1 means it is mandatory. An upper-bound of 1 means the field is a single value, where as -1 means, the field is a list of values. (The business model returns a List interface in this case!) It is also possible to define lower-bound = 0 and upper-bound = 5 which means that this is an optional multi-value field which is not allowed to have more then 5 values.

• max-length and min-length (mandatory for Strings)
  Only used for strings. Defines the minimum and maximum length of the String. In the types area the database limitations must be used. Settings can be overwritten in the custom area. (For unlimited use -1 (and only -1!)). Default is 0, so be sure to enter here the correct values from the database.

• object-name
  To access a field in the generic business model, you need an accessor, or property name. The object-name is exactly that. For example, to get the EAN number of an article you would say: article.get("ean"). The string "ean" comes from the object-name of the ArticleType.Ean field type.

• persistence-class-name
  Optional property, if not set, the value from class name is used. Can be used to define the persistence data type of a field. See class-name (above) for details.

• persistence-model-class
  The class name of the persistence model. If the persistence model is not set for the field, the persistence model class name of the parent entity type is used. Currently this information is needed to find the corresponding hibernate mapping for the field.

• persistence-xpath
  Needed to find the field in the persistence hibernate object model in a generic way, used mainly for the generic search.

• physical-column-is-big
  Set this attribute to true, if the column needs to be treated as BigStrings. This is needed for the unified data access, where for example normal strings are treated differently then ntext (or nclob) strings. Thus, if you have such an ntext (or nclob) field in the database, define here true. Default is false.

• proxy-transition-entity-type
  If the field type defines an entity proxy, set here which entity type this proxy represents. Currently used only by the export.

• qualified-serialization
  True if the value of this field should be serialized in EMF with it's class name. Used for very generic fields which have only an interface defined in the repository and therefore can't be really serialized with the standard mechanisms. Do not set fields to true without a proper reason since this slows the EMF serialization down.

• range-min and range-max
  Only relevant for numeric data types, not for strings. Optional except for BigDecimals because those have no min and max ranges by themselves. If omitted, the minimum and maximum range of the corresponding data type should be taken by the client of the repository. (The repository isn’t doing any "default-logic" here, because it has no idea of the data type which is used (which can also be a self-made class!)).

• scale
  The precision of decimal data types. Defines the number of digits after the comma.

• searchable
  True if the generic search functionalities can be used to search for this fields content, false if not. Default is false. Attention: Do not change this setting, unless you know what to do. Otherwise unexpected exceptions in the search could occur (usually we enable all fields which are searchable, if they are disabled for the search this has a reason!).

Multiple Entities for the same Entity Type

Top-level entities, and sub-entities can be defined multiple times for the same entity type. This helps to remove some of the complexity of the system from the user. (See logical-keys for details). Creating additional top level or sub level entities is a task which should not be done by untrained people as you can seriously damage the system if done wrong. Please contact Informatica Professional Services or Support for assistance.

The attributes of entities:

• active
  Defines if this entity is active at all. In case this is set to false, the entity will not be available at runtime at all. This setting is useful for entities which are not available by standard, but need to be accessible during automated testing etc. Default is true. Attention: Do not set entities to inactive if they are active in the standard repository, this might lead to exceptions since available functionality might rely on the entity being available.

• calc-source-field
  Deprecated and currently not used.

• cloneable
  Defines if this entity supports the "clone" functionality of the dataset creation feature. This setting is not intended to be changed by anyone except the core development since the clone functionality might need additional business logic which must be provided before the feature can work. Default it's false.

• default-view-id
  Only applicable for top-level entities. Defines the view id of the view which should be opened in case entity items of this entity should be visualized in a generic way. E.g. when the user opens a task for a specific item list, this view id is being used to visualize the items. (Usually a table view)

• description
  Language specific description of the entity. See section for multi-language support of the repository.

• documentation
  This attribute can be used to document the repository content, it is not being used by any logic in Product 360 currently. Providing meaningful explanations about the entity is recommended since the attribute might be used in the repository editor someday.

• entity id
  Each repository entity needs a unique entity id.

• entity-type
  Defines the corresponding entity type to which this entity is mapped.

• export-purpose
  Defines if the entity is available for the export. Specialized bit flags apply here, see export documentation for this.

• help-context
  Overwrites the help-context setting of the corresponding entity type. See entity type section for details. Currently not used.

• identifier
  The unique identifier of the entity. All identifiers in the repository must be unique over the whole repository. Naming convention: EntityTypeName (without the Type suffix). Like: Article for an entity which is mapped to ArticleType, etc.

• import-pupose
  Defines if the entity is available for the import.
  0 = not available
  1 = available

• label-pattern-short, label-pattern-long, label-pattern-description
  Optional and only applicable for top-level entities. These patterns define how entity items should be identified in different contexts (short, long, description). It is used by the GenericEntityItemLabelProvider and can be modified byconsultants in order to provide a different visualization for certain entity items. Implementers are encouraged to use the EntityItemLabelProvider mechanisms to obtain labels for entity items in a generic way. The pattern consists of field identifiers in curly brackets combined with any other sign. Note that only fields with no, or a single language logical key are supported currently. If you need a more intelligent logic of label creation feel free to contribute a specialized EntityItemLabelProvider implementation to the corresponding extension point.

• lowerBound
  It's overwriting the corresponding setting of the entity type if it's more specific. It is possible to make a entity "mandatory" which is "optional" in the types area. You can also define how many elements of an sub-entity is necessary. It’s not possible to define a field as "optional" whereas the entity type defines it as mandatory (optional is 0, mandatory is 1).

• mergeable
  Defines if the (sub-)entity is available for the merge process. This setting must not be changed outside the core development and is only relevant for the supported top-level entities. Currently supported is only the Article entity (the only one for which a merge is available).

• name
  Language specific name of the entity. See section for multi-language support of the repository.

• purpose (deprecated)
  Defines if the entity is available for the direct import.
  0 = not available
  1 = available

• supports-acl
  Only applicable for top-level entities. Flag which indicates if items of this entity are securable through the object right feature. This attribute must not be changed outside the core development.

• supports-tasks
  Only applicable for top-level entities. Flag which indicates if this entity should be used for the task management in Product 360. Usually all entities which make sense for tasks are activated by default.

• upperBound
  It's overwriting the corresponding setting of the entity type if it's more specific. It is possible to limit the maximum number of objects by setting a number here ( -1 =unlimited amount of objects). It’s not possible to define an entity as "not multiple" whereas the entity type defines it as multiple (multiple is anything else then 0 or 1).

• whiteboard-enabled
  Currently deprecated and should be ignored.

• shortIdentifier
  The short identifier is used in canonical forms of an entity item like for EntityItemChangeDocuments or EntityItemDocuments which are both json structures used in AuditTrail or the ObjectAPI. The short identifier must be unique within it's parent entity in a case insensitive way. ("Name" and "name" are equal regarding the short identifier!).

  An entity without a short identifier will not be saved in audit trail or returned in the Object API.For custom entities we recommend to adjust the shortIdentifier accordingly, a meaningful but literally short one is the best. Keep in mind that it's always relative to the parent! Don't: articleLogisticExtension, Do: logisticExtension and the parent of that one is already article!

  The short identifier is mandatory for entities.

  Allowed Characters:

  • a-z

  • A-Z

  • 0-9

  • - (minus)

  • _ (underscore, but not as first letter!

  The "shortIdentifier" must not start with _(underscore). Although we support upper/lower case characters they are basically for readability.

Entity Param

Generic list of key/value parameters which can be defined for every entity. These parameters can also be used by customizing as the values can be interpreted at runtime. The following list of parameters are supported currently:

Logical Key

As described in the types area, logical keys define the dimensions of an entity. Some of our entities are very complicated regarding dimensions (for example the prices). So, we found a way to remove this complexity from the user. We can do this by predefining some or even all of the dimensions right in the repository custom part. With predefined logical keys, there is no need for the user to define a dimension every time he wants to use a field from this entity. This predefinition can either be done in a "default value" way, or in a "fixed value" way, depending on the editable flag of the logical key. Attention: An entity must have all the logical keys which are defined in its corresponding entity type. It is not allowed to just "skip" some of them to remove a dimension. Dimensions can only be "removed" by predefining them!

The attributes of logical keys:.

• description
  language specific description of the logical key. See section for multi-language support of the repository.

• documentation
  This attribute can be used to document the repository content, it is not being used by any logic in Product 360 currently. Providing meaningful explanations about the entity is recommended since the attribute might be used in the repository editor someday.

• editable
  Defines if the value of the logical key can be edited by the user or not. If a logical-key has a predefined value, and is not editable, this logical key will be removed from any visible list in the application – thus this dimension is effectively "removed" (or hidden ) from the user. It is not allowed to set a logical key to editable=false without having a valid value defined!

• enumeration
  The enumeration identifier from which this logical key should take the possible values

• logical-key-type
  Defines to which logical key type this logical key is mapped. You should never change this attribute.

• name
  Language specific name of the logical key. See section for multi-language support of the repository.

• proposal-enum
  Defines if the value of the logical key can come from an enumeration. This means that the enumeration is available to make it easy for the user, but its not necessary to choose a value from this enumeration, it’s just a proposal.

• purpose
  This flag indicates if the logical key is available for the import. Some logical keys can't be used in the import – a specialized import logic is contributed for those cases. 0 disables the logical key for the import, any other value enables it. Modification of this attribute is not recommended.

• qualification-permission-identifiers
  Some sub-entities have logical keys which reflect the same thing; e.g. the language dimension is used in the ArticleLangType and the ArticleAttributeLangType sub-entities – in both cases it is a list of possible languages. The qualification permission identifier groups those different logical keys for the qualified field permissions. See the Product 360 User manual for details on the qualified field permissions functionality. Modification of this attribute is not recommended.

• value
  If the logical key should be predefined (either as default or as fixed value), the value needs to be entered here in ISO String coding. (dates as YYYY-MM-DD, numbers with dot for comma separation, true/false for booleans). For dates also the code "now" is allowed, which leads to always be "the current date".

• valuePath
  There is no need to define any value for this attribute in the repository editor. It is an attribute which is used in runtime to define paths to logical keys which apply to the corresponding context. For example an XPath in case of the XML Import, or some global variable for the export etc. Evaluation of this valuePath is done by the context in which it is used.

• shortIdentifier
  The short identifier is used in canonical forms of an entity item like for EntityItemChangeDocuments or EntityItemDocuments which are both json structures used in AuditTrail or the ObjectAPI. The short identifier must be unique within it's parent entity in a case insensitive way. ("Name" and "name" are equal regarding the short identifier!).
  An editable logical key without a short identifier is an invalid configuration. For custom entities we recommend to adjust the shortIdentifier accordingly, a meaningful but literally short one is the best. Keep in mind that it's always relative to the parent! Don't: articleLangLanguage, Do: language

  The short identifier is mandatory for logical keys. It is supposed to have the same short identifier as the corresponding field.

  Allowed Characters:

  • a-z

  • A-Z

  • 0-9

  • - (minus)

  • _ (underscore, but not as first letter!

  The "shortIdentifier" must not start with _(underscore). Although we support upper/lower case characters they are basically for readability.

Field

Fields hold the most properties in the whole repository. The fields in the custom part define the visualization aspects of fields. And also provide properties to overwrite settings from the types part. Attention: It is not allowed to have two fields which are mapped to the same field type inside the same entity!
The attributes of fields:

• active
  Defines if this field is active at all. In case this is set to false, the field will not be available at runtime. This setting is useful for fields which are not available by standard, but need to be accessible during automated testing etc. Default is true. Attention: Do not set fields to inactive if they are active in the standard repository, this might lead to exceptions since available functionality might rely on the field being available.

• average-length
  The average length of this field in "number of characters". This is needed for the standard table layout when adding a field to it.

• category
  The category this field belongs to.

• cloneable
  Defines if this field supports the "clone" functionality of the dataset creation feature. This setting is not intended to be changed by anyone except the core development since the clone functionality might need additional business logic which must be provided before the feature can work. Default it's false.

• default-column-order
  Defines the column order of fields when the application is started the first time in detail views. After this the order defined by the user is persisted. In case multiple fields have the same default column order, the order is not defined.

• default-column-order-from-top
  Defines the column order of fields when the application is started the first time in top-level views. After this the order defined by the user is persisted. In case multiple fields have the same default column order, the order is not defined.

• description
  Language specific description of the field. See section for multi-language support of the repository.

• display-by-default
  Defines if this field should be shown when the application is started the first time in detail views.

• display-by-default-from-top
  Defines if this field should be shown when the application is started the first time in top-level views.

• documentation
  This attribute can be used to document the repository content, it is not being used by any logic in Product 360 currently. Providing meaningful explanations about the entity is recommended since the attribute might be used in the repository editor someday.

• editable
  Defines if this field can be edited or not. This setting will only be evaluated by the GUI, it is still possible to change the field programatically.

• enumeration
  The enumeration identifier from which this field should take the possible values.

• export-purpose
  Defines if the field is available for the export. Specialized bit flags apply here, see Export purpose flag. Modification of this attribute is not recommended.

• field-type
  The corresponding field type of the field. It is not allowed to change this attribute.

• help-context
  Overwrites the help context setting of the corresponding field type. See field type section for details.

• identifier
  The unique identifier of the field. All identifiers in the repository must be unique over the whole repository. Naming convention: <EntityName>.<Identifier> (for example. Article.Ean, or ArticleLang.DescriptionShort) It is not allowed to modify the identifier at all! Field identifiers are persisted in workspaces and also in the database, changing of a field identifier breaks the backward compatibility of the repository. Valid characters for a field identifier are letters, numbers, ".", "_" and "-".

• import-purpose
  Defines if the field is available for the import.
  0 = field is not available in import
  1 = field is available in import

• lower-bound
  Overwrites the corresponding setting of the field type. Optional of course. It’s not possible to define a field as "optional" whereas the field type defines it as mandatory (optional is 0, mandatory is 1). But you can make a field mandatory which is optional in the types area. For 1:n fields like the article keywords, you can also say for example "at least 3 keywords needed".

• min-length and max-length
  Overwrites the min-length and max-length settings from the field type. It is not possible to exceed the limitations of the field type. See field type section for details.

• mergeable
  Defines if this field can be merged from the supplier to the master catalog, if false, the field does not appear in the merge profile. (Only applies for entites which will be merged in general)

• multiline
  Defines if carriage return line feeds are allowed in the string, also adjusts the visualization of the field. (Making it a multi line edit control for example)

• name
  Language specific name of the field. The name should be somewhat unique corresponding to its entity, its used for detail views for example. (See section for multi-language support of the repository. Names can reference logical key values, see appropriate section below for details.)

• name-from-top
  Language specific name of the field for top-level based views. Like an article view for example. Since these views show fields "flattened", a more or less "unique name" is required. (Doesn’t make much sense to have 5 times "Amount" in an Article Table). (See section for multi-language support of the repository. Names can reference logical key values, see appropriate section below for details.)

• password
  Defines if this field is a password field, which should not be visualized in clear-form, but with stars (*) for example.

• picture-clause
  An optional picture clause which overwrites the default picture clauses which come from the corresponding datatype. See the picture clause section for details.

• priority
  Deprecated and is currently not used.

• proposal-enum
  Defines if the value of the field can come from an enumeration. This means that the enumeration is available to make it easy for the user, but its not necessary to choose a value from this enumeration, it’s just a proposal.

• proxy-transition-entity
  Defines the entity for which the field represents a proxy for. Some similar setting is also defined in the types area, for the custom area we need this especially for "field selection dialogs etc".

• purpose
  Deprecated, make sure that the purpose has the same value as the import-purpose for compatibility reasons.

• qualification-permission-identifier
  Identifier of the qualified field permission which defines user specific security guidelines for the fields content.

• range-min and range-max
  Overwrites the range-min and range-max settings from the corresponding field type. See it’s description for details. Attention: It is not allowed to exceed the ranges which are defined in the types area!

• richtext
  Defines if this field can hold formatting markers. It’s needed to adjust the visualization of the field (by adding formatting functionality).

• scale
  Overwrites the setting of the field type. See field type section for details.

• searchable
  Defines if this field can be used for the search functionalities. Overwrites the field type setting. You cannot set a field to be searchable, when the types part defines it as not searchable. Just the other way round.

• upper-bound
  Overwrites the corresponding setting of the field type. Optional of course. It’s not possible to define a field as "not multiple" whereas the field type defines it as multiple (multiple is anything else then 0 or 1). But you can limit the maximum number of entries by setting this number here. You can also say for example "at least 3 keywords needed (lower-bound), but not more then 10 (upper-bound)".

• validation-severity-enum
  Defines how a validation problem should be treated. In general, validation always returns an error if the field type’s settings are violated. If the field’s settings are violated (custom part), The validation returns the severity which is defined here. Choose from INFO, WARNING or ERROR.

• validation-severity-lower-bound
  This setting applies if the field is a multiple value field (like keywords), and the minimum number of entries is not reached.

• validation-severity-range
  This setting applies if the value of strings violate the min/max-length, and the value of numbers violates the range-min/range-max.

• validation-severity-upper-bound
  This setting applies if the field is a multiple value field (like keywords), and the maximum number of entries is exceeded.

• value
  With the value property, one can define a default value for the field. Depending on the editable property, the value is to be treated as a "fixed" value, or as a "default" value. The value needs to be entered here in ISO String coding. (dates as YYYY-MM-DD, numbers with dot for comma separation, true/false for booleans).

• visible
  Defines if the field is visible in general. If this is set to false, the field won’t be seen in any view.

• visible-from-top
  Defines if this field is visible in the top-level view (like the Article Table). The visible property takes precedence, so when visible is false, visible-from-top is also false.

• shortIdentifier
  The short identifier is used in canonical forms of an entity item like for EntityItemChangeDocuments or EntityItemDocuments which are both json structures used in AuditTrail or the ObjectAPI. The short identifier must be unique within it's parent entity in a case insensitive way. ("Name" and "name" are equal regarding the short identifier!).
  A field without a short identifier will not be saved in audit trail or returned in the Object API.
  For custom entities we recommend to adjust the shortIdentifier accordingly, a meaningful but literally short one is the best. Keep in mind that it's alway relative to the parent! Don't: articleLogisticExtensionMyCustomField , Do: myCustomField as the parent entity is already called logisticExtension and the parent of that one is already article!

  The short identifier is mandatory for fields.

  Allowed Characters:

  • a-z

  • A-Z

  • 0-9

  • - (minus)

  • _ (underscore, but not as first letter!

  The "shortIdentifier" must not start with _(underscore). Although we support upper/lower case characters they are basically for readability.

Permissions

Element which defines a set of commonly available action rights for the entity. Note: All attributes of the element permissions are deprecated and will be replaced by the sub-element "permission".

The attributes of the permissions element are:

• category
  The permission category for the defined permissions

• create
  The identifier of the "user can create objects of this entity" action right

• delete
  The identifier of the "user can delete objects of this entity" action right

• edit
  The identifier of the "user can edit objects of this entity" action right

• read
  The identifier of the "user can read objects of this entity" action right

• security-edit
  The identifier of the "user can edit the object rights of objects of this entity" action right

• security-read
  The identifier of the "user can read the object rights of objects of this entity" action right

• version-release
  The identifier of the "user can add objects of this entity to a version" action right

• version-remove
  The identifier of the "user can remove objects of this entity from a version" action right

Enum Entry

Depending on the class which implements the EnumProvider interface, enum entries can be used either to be the "content" of the enumeration (this is the case for the StdEnumProvider), or, for example, the implementing class can use these enum entries for filtering.

Attributes of enum entries:

• documentation
  This attribute can be used to document the repository content, it is not being used by any logic in Product 360 currently. Providing meaningful explanations about the enum entry is recommended since the attribute might be used in the repository editor someday.

• external-code
  Optional but unique alphanumeric code which identifies the enumeration entry for 3rd party systems. Usually the official ISO code will be returned here. With a corresponding export function this external code can be used in export templates.

• key
  Defines the unique key of the enum entry. The string representation of the key will be converted to the key class using the ConvertUtils.

• key-synonym
  Defines one or more unique synonyms for the enum entry. It is not allowed to defined the same synonym for two different enum entries. The enum synonym will be treated as string.

• label
  The unique language dependent label of the enum entry. The label must be unique for the enummeration since it is automatically used as a synonym for the entry.

Enum Entry Param

Enumeration entries can be parameterized using enum entry params. How these parameters will be interpreted is up to the enum provider implementation and should be documented by the implementation itself.

• name
  The parameter name

• value
  The value of the parameter

Enum Param

Enumerations can be parameterized using enum params. How these parameters will be interpreted is up to the enum provider implementation and should be documented by the implementation itself.

• documentation
  This attribute can be used to document the repository content, it is not being used by any logic in Product 360 currently. Providing meaningful explanations about the enum param is recommended since the attribute might be used in the repository editor someday.

• name
  The parameter name

• value
  The value of the parameter