Data Structure Overview
Overview
Data structure is the way your data is organized in the system. Fynapse allows you to create a fully customized data structure that will be tailored to your needs. This approach minimizes the total cost of ownership, as no redundant data units have to be maintained, and maximizes business agility.
The purpose of the data structure is to act as a mechanism capable of:
- Receiving data provided by external systems
- Transforming data received into it to the extent that the transformed data is able to be used by Fynapse modules
- Serving data to and storing data provided by Fynapse core modules, such as Accounting Engine and Subledger
What Are the Elements of the Data Structure?
Entities
The data structure is built from entities, the basic unit of organizing data in Fynapse. An entity is an abstract concept which represents the physical implementation of underlying database tables. The entity encapsulates a business idea into a format that streamlines development and integration, simplifying the process considerably.
The maximum numbers of user defined Entities stored in Fynapse in Finance Data Service is 50.
Types of entities:
- Protected entity - this is an entity which is created by the system when you define configurations that are necessary for the functioning of the system. They cannot be deleted.
Currently, there are four protected entities:- Journal with nested Journal Line
- Unposted Journal
- Business Event with linked Business Event Rollback, which are created when you configure Journal Line Definition
- Business Event Definition
You can configure Journal Line Definition and Business Event Definition on the relevant screens. It is also possible to upload Journal Line Definition and Business Event Definition as part of the Configuration Data JSON.
The Business Event Rollback Entity is automatically created based on the Business Event Entity. It is used to perform rollback.
- Defined entity - this is an entity defined by the user. You can create as many or as little defined entities as required by your data architecture.
It is possible to delete defined entities, however any such change will have significant effect on the working of the system.
Primary Key
Entities have to have a Primary Key defined, this is a unique attribute or set of attributes which identify an entity in the system, e.g., when referring to other entities. Attributes that constitute the Primary Key must be mandatory.
The Primary Key used for Defined Entities can have up to 5 attributes (used attributes must be set as mandatory).
Namespaces
Entities are grouped into logical sets called namespaces. These allow you to more easily identify an Entity, as all Entities within a namespace are unique.
Attributes
Each entity comprises of an ordered list of attributes. The attributes define the name, structure and constraints of an entity. As mentioned above you have to select the mandatory attributes which will constitute the unique Primary Key, i.e., the means of identifying the entity in the system.
The Primary Key used for Defined Entities can have up to 5 attributes (used attributes must be set as mandatory).
Defined Entities can have up to 100 attributes (including Inline Entities).
Attribute types are divided into two categories, primitive and complex:
- Primitive attributes:
- UUID
Please note that the UUID inputs are not generated automatically. You need to generate them either via a third party generator or in your upstream system and include them in the ingest file with the rest of the input data.
- Boolean
- Timestamp - the format used in Fynapse is: yyyy-mm-dd HH:mm:ss. This format is hardcoded and cannot be changed.
- Date - the date format Fynapse is: yyyy-mm-dd. This format is hardcoded and cannot be changed.
- Text
- Int
- Decimal - the decimal attribute operates with the following parameters: scale 18 digits and precision 3 digits. This format is hardcoded and cannot be changed.
- UUID
- Complex attributes:
- Inline Entity - this is an entity attribute type, i.e., a child entity nested within another entity.
- List - this is an attribute type which can store an ordered collection of data, primitive or complex, e.g., Inline Entities. The data contained within the List will be ordered in accordance with the order they were supplied to Fynapse. An example of this is a ‘person’ Entity with list of ‘children’, ordered from youngest to oldest.
A special example of this are Protected entities Journal and Journal Line, with Journal Entity containing a list of Journal Line Entities. Their order is determined by Fynapse.
Technical properties
- namespace - Entities are grouped into logical sets called namespaces. Currently, the value for this property should be defined as “fynapse”
- “namespace”: “fynapse”
- databaseConfiguration - if an Entity is to be persisted then it needs to be stored in “FDS”, and this can be done by defining the following database configuration:
Validations
You can define your own validations for Entities in the Data Structure.
For more details, refer to Validations.
Examples
If you want to upload these examples to Fynapse, please ensure you upload the simple Entity first and then the complex Entity, otherwise references in the complex Entity will not work.
Sample simple entity structure
Sample complex entity structure
How Is the Data Structure Built?
The full Data Structure is defined in the JSON file which is later uploaded via the Configuration Data screen in Bulk Operations.
Business Event and Journal entities can be defined via the UI on Business Event Definition and Journal Line Definition screens, respectively.
You can also upload only entities using a dedicated JSON file uploaded via the Data Structure Definition screen in Bulk Operations. We suggest you only use this option for uploading new Defined entities and try to upload full configuration using the Configuration Data JSON file.
