Business Data Limitations
The Business Data store is not designed for storing huge binary objects like PDFs.
Business Case Data can only be applied if the case is persistent (i.e. has at least one task).
The ivy scripting types
Treeare not serializable.
Collection types like an
ArrayListcan be stored in a field, but not as root object. Always use a simple DataClass or plain old Java objects as root object to store and load in the repository.
Public API objects like
ITaskor similar should not be stored into the Business Data repository. As workaround it’s better to store the id of a Task or User and reload it via this identifier.
The type of a stored field should never be changed (E.g. from
String). The already stored data deserialization could fail and more likely Business Data with the new type can no longer be found via the search API as the search index is strongly typed.
- Project Dependencies
When using the same Business Data value type in multiple projects ‘a’ and ‘b’ it is best to define the data classes for the business data in an own project ‘base’. Then define a dependency from projects ‘a’ and ‘b’ to project ‘base’.
If you use an object of a type that is defined in project ‘a’ inside the business data value (e.g. add it to a list) then the business data value cannot be loaded in project ‘b’. This is because project ‘b’ is not dependent to project ‘a’ and therefore cannot load objects of classes that are defined in project ‘a’.
The business data will be duplicated to Elasticsearch. This offers us powerfull search capabilities but we also have to deal with their limitations.
Do not use
Maps with random or generated keys in your data structure. This will lead in a explosion of Elasticsaerch mappings.
Prevent cyclic references and back references from lists to the parent object. This can lead to huge json while expanding these data structures.