Configuration Data
Overview
The Configuration Data screen allows you to upload files with data to quickly configure Fynapse. This data can include, for example, Journal Line Definition, Business Event Definition, Dimension Sets, and Node Settings. The screen also allows you to download or delete a current system configuration.
Versioning of the File Structure
The Configuration Data file format supports versioning of the Configuration Data file structure. This means that the system structure governing Fynapse at any given time will be identified by a hardcoded version number. This version number will change with new updates to the governing structure.
Please note that the versioning refers to the system structure, not your configuration of the system. If you e.g., add a new calendar or change a Dimension Set, this will not cause a new version to be created.
Do not remove the version number from the JSON file. If you remove the version number, you will not be able to reupload the file.
When you download the file, it will contain information about the governing version:
We will be supporting older formats for a period of time. If you try to upload an older file which e.g., is missing a mandatory field, Fynapse will add this field to the configuration you are uploading.
When you try to upload a file in an unsupported version with an outdated structure Fynapse will throw an error.
General Information
JSON File Format
The Configuration Data screen allows the upload of files in a JSON format.
Remember to check if the “version” parameter is referring to a version number currently supported by Fynapse. If you are not sure about the current version number, download the JSON file from your Fynapse instance to verify prior to uploading your configuration.
Sample Structure
If you want to enable support for multiple currencies you have to add attributes related to this functionality to the JSON file. For more details, refer to Multiple Currencies.
Fynapse supports the download and re-upload of Flow configurations. For more details on the structure of Flow configuration in the Configuration Data JSON file, refer to Flow in Bulk Operations.
Configuration Data Constraints
Data uploaded in a JSON file has to meet the following prerequisites:
General Configuration
Journal Line Definition
- The correct structure of a Journal Line Definition consists of mandatory Systemic Fields, Subledger Nodes, and optional additional fields.
For more details, refer to Journal Line Definition.
It is recommended to manually delete all data permission rules assigned to the Subledger Nodes via the Data Permissions screen before uploading a new configuration that will introduce changes to these Subledger Nodes. If you do not delete them prior to uploading the configuration, the system will retain the rules, but you will still be able to delete them later.
- Each defined field has to have:
- A Field Name, which has to be unique and have the maximum length of 128 characters
- A Field Label, which has to be unique and have the maximum length of 128 characters
- A Field Type with a correct corresponding data type, e.g. a date for Core Date
- For Systemic Fields the Systemic Field Type is hard-coded
For decimal type fields the decimal attribute operates with the following parameters: scale 18 digits and precision 3 digits. This format is hardcoded and cannot be changed.
The “source” attribute is part of a larger implementation which is currently limited to the Business Event Entity. For Entities other than the Business Event Entity this attribute will appear for all defined fields when you download the Configuration Data JSON file. However, for these Entities this attribute is non-mandatory and you do not need it to upload your Configuration Data JSON file. So, a downloaded definition of a field will look like this:
Business Event Definition
- The correct structure of a Business Event Definition consists of a mandatory Systemic Field, i.e. Event Type, Subledger Nodes, and optional additional fields.
For more details, refer to Business Event Definition. - Each defined field has to have:
- A Field Name, which has to be unique and have the maximum length of 128 characters
- A Field Label, which has to be unique and have the maximum length of 128 characters
- A Field Type with a correct corresponding data type, e.g. a date for Core Date
- For Systemic Fields the Systemic Field Type is hard-coded
- Primary Key - the fields which will constitute the unique ID of the record in the system
- Validations - you can define your own validations for Business Events
For more details, refer to Validations. - Source - data source for the BED field; there are two types of data sources:
- input - these are fields which draw data from input files with transaction data
- reference - these are fields which draw data from Reference Entities based on references defined for the Business Event Definition; this is the value you have to define to create an enriching field
If you define a field with a “reference“ source type, you have to define the reference:
where:
- sourceReference - the definition of the reference
- name - name of the reference to the Entity which contains the enriching field
- attribute - name of the enriching field in the referenced Reference Entity
For decimal type fields the decimal attribute operates with the following parameters: scale 18 digits and precision 3 digits. This format is hardcoded and cannot be changed.
where:
- name - name of the reference
- label - label of the reference
- description - description of the reference
- entity - Entity being referenced
- namespace - Entities are grouped into logical sets called namespaces. This ensures easy identification, as Entities within each namespace have to have unique names.
Currently, the value for this property should be defined as ‘fynapse’. - definition - definition of the reference:
- typeName - type of the reference:
- Attribute - a reference to an attribute from Business Event Definition to an attribute from the Organization Unit Entity
- Const - reference from the Business Event Definition to a determined value of an attribute in the Organization Unit Entity
- referencedAttribute - the attribute from the referenced Entity
- attributeName - the name of the attribute in the referring Entity for Attribute type references
- value - the value of the attribute in the referenced Entity for Const type references
Primary Keys
When creating a reference you have to cover Primary Keys. A Primary Key is a unique attribute or set of attributes which identify an Entity in the system. What this means is, if you define a Primary Key consisting of one attribute then you have to create a reference to this attribute when referring to this Entity. You can create references to other attributes as well, but Primary Key attributes are mandatory for a reference. Let’s look at the example above. We are creating a reference to the Organization Unit Entity which has one Primary Key attribute - Organization Unit Identifier. Additionally, we are also creating a reference to the Organization Unit Identifier Type attribute, which is not part of the Primary Key, but we still want to reference it.
Linked References in Business Event Definition
You can create a more complex enrichment, by creating a reference based on a field from a different reference.
In order to set this up correctly, it is best if you do it in stages:
Stage 1
Define the first reference, e.g., instrumentEnrichment:
Stage 2
Define an enriching field using a field from the referenced Entity, in this example, this is the “instrumentSubTypeCode” field:
Stage 3
Now, when creating a “hook” for another reference, you can use the “instrumentSubTypeCode“ field. This will simplify validations, as the system will not be required to call the referenced Entity because the field is already part of the Business Event Definition:
If you create linked references, you have to ensure they are listed in the Configuration Data JSON file in the correct order. The references are validated in the order they are listed, so if you are using a field from a reference in another reference, the latter have to be listed first. This will ensure the field is populated in the Business Event and the call from the second reference does not return empty.
An alternative version would be to create a link between the two references, without creating a new field on the Business Event Definition:
where in the definition of the reference in the attributeName property you have to create a “hook“ for another reference:
referenceName.attributeName - for example, intrumentEnrichment.instrumentSubTypeCode
here:
- intrumentEnrichment is the name of another reference
- instrumentSubType Code is the name of a field in another Entity called by the instrumentEnrichment reference
Business Event Types
The definition of types of Business Events.
Node Values
When you define Subledger Nodes in Journal Line Definition, you need to define the values for these Nodes.
Node Configuration
Each Node Configuration has to have:
- A unique name
- Configured Nodes defined in the Journal Line Definition
- Selected Time Zone
- Assigned Accounting Base
- Configured Grace Period:
- Grace Days: between 0 and 31
- Grace Hours: between 0 and 23
For more details, refer to Node Configurations.
Accounting Base
Each Accounting Base has to have:
- A unique name
- Configured:
- Business Calendar
- Fiscal Calendar
- Dimension Set
- Assigned Node Configuration
- Configured Grace Period:
- Grace Days: between 0 and 31
- Grace Hours: between 0 and 23
For more details, refer to Accounting Bases.
Dimension Sets
- A unique name that is a maximum 255 characters long
- A unique set of Dimensions that correspond to fields on Journal Line Definition
For more details, refer to Dimension Sets.
Business Calendar
Each Business Calendar has to have:
- A unique name
- Status
- Effective From date
- Effective To date
- Rules (optional)
For more details, refer to Business Calendars.
Fiscal Calendar
Each Gregorian Fiscal Calendar has to have:
- A unique name
- Type
- End of Fiscal Year
- Year
Each Custom Fiscal Calendar has to have:
- A unique name
- Type
- effectiveFrom date
- Definition of periods
For more details, refer to Fiscal Calendars.
Business Date Override
Currently, Business Date can be overridden only in the screen, by going to the System settings screen.
However, if you do configure the override the following will appear at the very end of the Configuration Data JSON file downloaded from Fynapse:
This is read only information. If you change this setting in the JSON file and reupload it, it will not change the configuration.
Unposted Journals Feature Flag
The Unposted Journals feature flag allows you to change the logic behind managing Unposted Journals.
For more details, refer to Journals.
Note that any changes to this setting significantly affect how the data is processed.
By default, the Unposted Journals setting is enabled:
You can choose to disable it by changing the value to “false”.
If you do not include the Unposted Journals settings section when you reupload the Configuration Data JSON file, the system will automatically restore the default setting where the Unposted Journals setting in enabled.
Feature Flags
If there are no feature flags currently available in Fynapse, this section will not appear in the JSON file.
This section lists all feature flags currently available in Fynapse together with their statuses:
- true - for enabled feature flags
- false - for disabled feature flags
For example:
Yearend Cleardown
Yearend Cleardown, also known as Retained Earnings Process, is part of closing a fiscal year and a preparation for starting a new financial year.
To configure Yearend Cleardown you need to insert the following sections, which cover Yearend Cleardown configurations and assignments:
Note that if you have enabled Multiple Currencies, this section will also include FX Revaluation configurations and assignments. For more details, refer to Multiple Currencies Configuration.
Accounting Engine
Posting Components and Account Lookups
Each Posting Component has to have the following properties defined:
- Posting Code
- Journal Type
- Accounting Base
- Posting Pattern (a minimum of 2 have to be defined, one for Debit and one for Credit Record):
- Posting Code
- Debit or Credit Record
- Amount Sign
- Currency
- Amount Type
- Posting Date
- Matching Definition between Business Event Types and Posting Components:
- Business Event Type
- Posting Component Code
- Name
- Type
- Value
To configure Account Lookups you have to define:
- Posting Code
- Lookup Attributes Definition:
- Name
- Matching Order
- Lookup Patterns:
- Account
- Lookup Attributes:
- Type
- Name
For more details, refer to Working with the Accounting Rules.
Chart of Accounts
Chart of Accounts is an optional item you can use to ingest your company’s Chart of Accounts into Fynapse.
Each defined Account requires the following data:
- number - unique number of the Account
- name - unique name of the Account
- financialStatement - information about the financial statement
- type - type of the Account
Note that if you add this section, then you need to include in it all Accounts defined in the accountLookups section of the Accounting Rules Navigator Configuration. If you fail to add any Accounts from the Account Lookup section, the Configuration Data JSON file will not be ingested and an error will be thrown.
All Accounts ingested in the Configuration Data JSON file are by default set to ACTIVE.
Journal Mapping
To configure Journal Mapping you have to define:
- Journal Field
- Mapping Type
- Based on the mapping type:
- Field - for field type mapping
- Value - for value type mapping
- Conditions - for condition type mapping
For more details, refer to Journal Mapping.
Journal Types
To configure Journal Types you have to define:
- Journal Code
- Behavior
- Reversing Date - if the Journal Type is defined as reversing
For more details, refer to Journal Types.
Deferral Calculator
To configure the Deferral Calculator you have to enable the functionality and define:
- Start Date
- End Date
- Initial Deferral Amount
- Logical Operator
- Filters
- Posting Date
- Optional: Initial Posting Date
- Optional: Overrides
For more details, refer to Deferred Payments.
Data Structure
Data Structure Definition
For detailed information about Entities and Data Structure, refer to Data Structure and Data Structure Definition.
An upload file can contain many Entities, but all of them must be unique for the upload to be successful.
For detailed information about Entities and Data Structure, refer to Data Structure and Data Structure Definition.
The “source” attribute is part of a larger implementation which is currently limited to the Business Event Entity.
For Entities other than the Business Event Entity this attribute will appear for all defined fields when you download the Configuration Data JSON file. However, for these Entities this attribute is non-mandatory and you do not need it to upload your Configuration Data JSON file.
So, a downloaded definition of a field will look like this:
Definition Constraints
The definitions uploaded in a JSON file have to meet the following prerequisites:
Entity
- name:
- Has to be unique.
- Has to be composed using the following rules: start with a letter, which can be followed by alphanumeric characters and an underscore.
- Has a maximum length of 128 characters.
- temporalityType - what kind of data is contained in this Entity:
- Reference - determines that the entity has a reference data type
- Transaction - determines that the entity has a transactional data type; these are accounting data that cannot be changed
- description - you can add an optional description
- type - determines what type of an Entity this is:
- ProtectedEntity - this is an entity which is created by the system when you define configurations that are necessary for the functioning of the system.
- DefinedEntity - this is an entity defined by the user, you can create as many or as little defined entities as required by your data architecture.
- primaryKeyAttributeNames - this is the definition of Attributes which will constitute the Primary Key and allow to identify the record in the system
The Primary Key has to:- Be unique
- Consist of a minimum of 1 Attribute
- Consist of a maximum of 5 Attributes
- Consist only of primitive attributes
When defining an Entity to be used as target for an extract, remember to add extractId to the Primary Key for Transaction type transient Entities to ensure correct deduplication of data. For more details, refer to Flow.
Attribute
An Entity has to have at least one Attribute.
- name - unique name
- Has to be unique
- Has to be composed using the following rules: start with a letter, which can be followed by alphanumeric characters and an underscore
- Has a maximum length of 128 characters
- label - Has a maximum length of 128 characters, no constraints on syntax
- mandatory - determines if an attribute is mandatory:
- true
- false
- type - determines whether this is a Primitive or a Complex Attribute
- 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.
- HIGH-PRECISION DECIMAL
- 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 a 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.
- Primitive attributes:
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
- Validations - you can define your own validations for Business Events
For more details, refer to Validations.
Transient Entities are Entities created by an extract. These can be both Transaction and Reference type Entities, depending on the temporalityType of the source Entity. They are visible in the grid on the Finance Data Service screen, if they inherit the Reference, but the data contained in them cannot be browsed when you open the Entity details screen, because it is not stored in Finance Data Service until it has been transformed into an FDS Entity by a Flow. Transient Entities are used as input for Flows. They will be downloaded in the Configuration Data JSON file with the following tag appended to their definition:
They can be edited in the downloaded JSON file, e.g., you can add enrichment or validations, and reupload. Please remember that the added validations and enrichment have to be compatible with the existing data model.
Sample Entity structure:
Examples of Primitive and Complex Attributes
Primitive Attributes
Text
Int
Timestamp
Complex Attributes
Inline Entity
List Type
Subeldger
Balance Queries
Balance Queries section comprises of queries for balances and balance movements saved on the Balances screen.
- type - the type of query, the available values are “balance” and “balanceMovement”
- query - definition of the query
- limit
- balanceDate - the definition of the date for which the balance is calculated
- type - type of date:
- currentDate - the actual date on which you create the query, i.e. the current Business Date
- previousDay - the date on the day before the Current date, determined based on the Business Date
- previousPeriodEnd - determined based on the selected Fiscal Calendar
- previousYearEnd - determined based on the selected Fiscal Calendar
- specificPeriodEnd - determined based on the selected Fiscal Calendar
- specificDate - any specific date you define
- date - for types which requires a specific date
- type - type of date:
- fields - name of the field or fields used in the query
- openingDate - for balance movement queries
- type
- dailyBalanceMovement - you need to select the Balance date based off of the Opening Balance date will be calculated. The Balance dates available in this selection are listed above in the How to instruction for creating a Balance query.
- periodToDate - you need to select the Fiscal Calendar which will be used to calculate the Balance date and Opening balance date.
- periodFromTo - you need to select the Fiscal Calendar which will be used to calculate the Balance date and Opening balance date.
- yearToDate - you need to select the Fiscal Calendar which will be used to calculate the Balance date and Opening balance date.
- previousPeriod - you need to select the Fiscal Calendar which will be used to calculate the Balance date and Opening balance date.
- previousYear - you need to select the Fiscal Calendar which will be used to calculate the Balance date and Opening balance date.
- specificPeriod - you need to select the Fiscal Calendar which will be used to calculate the Balance date and Opening balance date.
- specificDates - For Specific dates, you need to select the Dates from/to for which the query will be run.
- date - for types which requires a specific date
- filters - section with filter definition
- fieldName - name of the attribute used to filter the results
- operator - type of operator used in the filter
- rules - rule defined for the filter
- constraint - constraint set for the rule
- values - value set for the rule
- openingDate - definition of the Opening date for balance movement
- balanceFilters - section with definition of filter using balance as attribute
- operator - type of operator used in the filter
- rules - rule defined for the filter
- constraint - constraint set for the rule
- values - value set for the rule
- currency - currency used in the selected balance
- openingBalanceFilter - section with definition of filter using opening balance as attribute
- operator - type of operator used in the filter
- rules - rule defined for the filter
- constraint - constraint set for the rule
- values - value set for the rule
- currency - currency used in the selected opening balance
- balanceMovementFilters - section with definition of filter using balance movement as attribute
- operator - type of operator used in the filter
- rules - rule defined for the filter
- constraint - constraint set for the rule
- values - value set for the rule
- currency - currency used in the selected balance movement
- type
- name - name of the query
Extracts
Extract Configurations
Operating under Feature Flag If you want to use this feature, contact your System Administrator.
- Only extract configurations that are submitted and have the Active and Inactive (they will be active in the future because the current date is earlier than the start date) statuses can be downloaded to a JSON file and then uploaded using the Configuration Data screen.
- The functionality allows to download all extract configurations from one environment and upload them to new environments without extract configurations as well as to environments already having extract configurations, or download all extract configurations, edit some or all of them, and upload them again to the same environment. In the case of editing existing extract configurations, the only parameters allowed to be modified are:
- Description
- Start date and time (only if the set start date is in the future, that is, the extract configuration has not been run yet)
- End date and time
If you change any of not editable parameters in the already existing extract configuration, then while uploading the JSON file validation errors will be thrown and uploading will be impossible.
- If extract configurations uploaded from the JSON file contain start dates from the past, then these dates will be automatically updated to the date when the file is being uploaded. However, if the end dates of these extract configurations are in the past at the time of uploading, then an error will be thrown informing you that you cannot upload extract configurations with end dates from the past and uploading will be impossible. In such a case, you need to modify the JSON file and set the end date to a future date and time or remove the endDate parameter (then the extract configuration will be run indefinitely).
Extract Configuration Parameters
The following parameters can be found in extract configurations in the JSON file:
- extractConfigurationName - the name of the extract configuration that should be unique and can contain upper-case and lower-case letters, digits, spaces, periods, exclamation marks, parentheses, hyphens, and underscore characters. This parameter is mandatory.
- description - additional information about the extract configuration. This parameter is optional.
- extractType - the type of an exported file. The only available values are “CSV”, “JSON”, and “KAFKA” (for the integration with Microsoft Dynamics 365 and if FDS is set as uploadSpace). This parameter is mandatory.
- d365ConfigName - the configuration name available and mandatory only if the integration with Microsoft Dynamics 365 is enabled
- balanceQueryName - for extracts using balances as source, name of the saved balance or balance movement query
- startDate - the date and time when the configuration starts to be active in UTC. The date should be set to a future one because when this date is already in the past during bulk upload, then it is automatically overwritten to the current date and time. This parameter is mandatory.
- endDate - the date and time when the configuration ends to be active in UTC. When the date is set, it must be in the future (if not, an error will be thrown). This parameter is optional.
- uploadSpace - the cloud storage to which the extract file will be uploaded. This parameter is mandatory. The only possible values are:
- “CLOUD_STORAGE”
- “REST_API”
- “FDS” (set it if you want to perform data extraction into Entity for further processing using Flows)
- “D365“ (only if the integration with Microsoft Dynamics 365 is enabled)
- incremental - if it is set to “true”, then only data that was not previously extracted using the same extract configuration will be extracted. This parameter is optional.
- query - request data:
- namespace - the name of a namespace to which the selected Entity belongs. The only possible value is “fynapse“. This parameter is mandatory.
- entity - the name of the Entity that will be extracted. The possible values are “Journal”, “JournalUnposted“, “Error”, “Balances”, and names of user-defined Entities. This parameter is mandatory.
- fields - defines which Entity attributes will be returned and included in the extract file. When this parameter is empty, then all attributes will be returned.
Do not type any Entity attributes in the fields parameter because this parameter is not supported via the Extraction screen, and its setting cannot be changed via GUI.
- queryFilter - lists the sets of attributes with their settings to filter data for extraction:
- nodes - the technical parameter to structure both all and individual nodes containing particular query attributes:
- fieldName - the attribute name used to create a query
- constraint - the operator used to build the query, for example, between, equal, and not equal. If the constraint is set to “dynamic”, then the following parameters should be defined for the dynamicValue parameter:
- valueType - it should be set to “dateRange”
- timeUnit - a period type for which the extraction will be run. The only available values are “years”, “days”, and “months”.
- numberOfPastUnits - the number of months, years, or days for which the extraction will be performed, for example, 1.
A maximum number for years and months is 12, and for days is 30.
- closingDateType - specifies the point in time that sets the end date for data extraction. Data available for this end date is included in the extraction. The only available values are “currentDate”, “previousDay”, “previousPeriodEnd”, and “previousYearEnd”.
- fiscalCalendarName - a name of a Fiscal Calendar that should be used to calculate the previous year or period end. This parameter is available when you set the closingDateType parameter to “previousPeriodEnd” or “previousYearEnd”. The Fiscal Calendar must have the periods defined.
- values - the value for the selected operator, depending on the selected attribute and operator it can be a text or a date or it does not have to be defined
- operator - if more than one constraint is defined for one attribute, then it informs if all or any of defined constraints must be taken into consideration. It can be set to “AND” and “OR”.
- operator - informs if all or any of the defined query attributes must be taken into consideration. It can be set to “AND” and “OR”.
- nodes - the technical parameter to structure both all and individual nodes containing particular query attributes:
- sourceAggregation - a list of attributes, on which the query performs aggregation. The only allowed data type is decimal. When the extract is created using the Fynapse UI, the list will contain all amount fields defined on the Journal. Each source aggregation contains the following properties:
- field - a name of an attribute in a source Entity
- expression - the aggregating function applied on the field. For the aggregation defined using the Fynapse UI always the “sum” is applied.
- alias - a name of an attribute in a target Entity. For queries defined using the Fynapse UI, the alias is always the same as the source attribute.
- resultClustering - defines how the result data will be split into separate messages (or which returned rows will be clustered into a single output data object)
- clusteringCriteria - a list of source attributes used to split the output data into separate messages. Source attributes must be included in the fieldExtressions parameter.
- keyAlias - not relevant for the custom aggregations, used only by the internal Fynapse processing. By default, it is set to “aggregationLineId” by the Fynapse UI.
- valueAlias - the name of the attribute in the target Entity containing the child elements. By default, it is set to “aggregationLines” by the Fynapse UI.
- valueElementAlias - not relevant for the custom aggregations, used only by the internal Fynapse processing. By default, it is set to “aggregationLine” by the Fynapse UI.
- fieldExpressions - a list of attributes used for grouping data for aggregations. Each fieldExpression contains the following parameters:
- fields - a single field from the source Entity, or a list of fields (if the expression is using multiple inputs, such as concatenation). For the queries defined using the Fynapse UI, it is always a single field, as they do not support custom expressions.
- expression - optionally, a function applied to the source fields. For the extracts defined using the Fynapse UI, it is always set to “none”, which uses the unmodified source attributes.
- alias - the name of the attribute in the target Entity. For the queries defined using the Fynapse UI, the alias is always the same as the source attribute.
- partitionByEntityKey - informs that data will be grouped (partitioned) according to the defined Primary Key to return the newest record from each group on the basis of the creation time attribute. This parameter is available only for the extract configuration created for user-defined Entities.
- primaryKeys - lists attributes defined as the Primary Key of a particular user-defined Entity. This parameter is available only for the extract configuration created for user-defined Entities.
- kafkaTargetConfig - defines settings necessary to configure data extraction into a dedicated Entity for further processing in configured Flows when the uploadSpace is set to FDS.
- entityName - a name of a user-defined Entity to which data will be extracted for further processing in Flows
- entityNamespace - the name of a namespace to which the selected Entity belongs. The only possible value is “fynapse”.
- topicType - Kafka topic type. The only possible value is:
- “input” - this means that data will go through all processing stages, that is, deduplication, validation, enrichment, and finally processing using Flow. This topic type is the default and recommended option.
- balanceQueryName - for extracts where data source is defined as Balances, this parameter is the name of the defined balance or balance movement query used in the extract
- scheduler - defines settings for the scheduler which will run extract configurations according to the defined schedule:
- type - a type of the scheduler. It can be set to:
- FREQUENCY - the extract configuration will be run according to the set frequency, for example, yearly, daily, etc.
- SPECIFIC_DATES - the extract configuration will be run on defined dates and time
- DISABLED - the extract configuration will not be run automatically, it must be triggered manually via the Extraction screen
- frequencies - specific settings for a selected frequency:
- interval - how often the extract configuration will be triggered. Possible values are “ONCE” (for SPECIFIC_DATES), “HOURLY”, “DAILY”, “WEEKLY”, “MONTHLY”, and “YEARLY” (for FREQUENCY)
- entries - lists all repetitions of the extract configuration execution:
- cron - specifies time settings of a particular interval:
- seconds
- minutes
- hours
- dayOfMonth
- month
- dayOfWeek
The following special values can be displayed in the above settings:- “*“ - means every, for example, “*” in the minutes parameter means for every minute.
The “*“ should not be used particularly in the seconds parameter because it means that the extract configuration will be triggered every second.
- “?” - means any and is used in the dayOfMonth and dayOfWeek parameters to denote the arbitrary value and thus ignore the parameter value. For example, if the extract configuration should be triggered on 5th of every month irrespective of what day of the week falls on that date, the “?” should be typed in dayOfWeek.
- “*“ - means every, for example, “*” in the minutes parameter means for every minute.
- cron - specifies time settings of a particular interval:
- type - a type of the scheduler. It can be set to:
- splitBy - defines if extracted data is split per Core Date attribute to separate extract files:
- isSplitByAttributeEnabled - defines if splitting is enabled. The possible values are “true” and “false”.
- attributeDescriptors - defines the list of attributes by which data can be split. The attribute used here has the “coreDate” role assigned and the name of this attribute is defined in the “name” parameter for Journal Line Definition (it can be different for various Fynapse installations). Look at a sample Journal Line Definition configuration structure with the defined “coreDate“ role:
- chunkSize - an optional technical parameter only if the integration with Microsoft Dynamics 365 is enabled
Do not change the value for the chunkSize parameter.
- dimensionSetName - the name of a Dimension Set used for the aggregation of Journals and Unposted Journals
- excludedDimensions - a list of user-defined Dimensions that should be excluded from the aggregation of Journals and Unposted Journals
Sample extract configuration structure:
Errors
Sample Errors Section
Fynapse ensures the integrity of the system by validating the JSON file upon download. If you make changes in the screen, which cause the configuration to break and then try to download this configuration, Fynapse will inform you that you are trying to download a broken configuration. The list of errors will be added at the end of the downloaded JSON file.
Modifying Defined Entities and Protected Entities
It is possible to edit the Entities, including Journal Line Definition Protected Entity, via the Configuration Data JSON file without loss of transactional data already in the system.
In order to change an Entity, upload a JSON file with the changes via the Configuration Data screen. If the changes are not supported by the system, a dialog will appear informing you of possible data loss and asking you for confirmation. If you choose to upload unsupported changes, all transactional data relating to the Entity with unsupported changes will be lost.
The supported changes are:
- Adding an attribute that is not mandatory
- Dropping an attribute that is not part of a Primary Key
- Reordering attributes
The unsupported changes are:
- Changing Entity temporality type
- Changing attribute types
- Changing the mandatory setting of an attribute
- Changing an attribute’s Primary Key
In the event you need to perform any of the unsupported changes without any loss of data, please raise an ASD support ticket with Aptitude Software Support. Make sure that the ticket details what unsupported changes you want to make and what result you want to achieve, to allow our team to analyze all potential ramifications and propose the best solution. Please note that not all changes may be achievable without loss of data.
Configuration Data Screen
The Configuration Data screen comprises the following elements:
- The Download button - click it to download a file containing a current Fynapse configuration
- The Select files button - click it to select which file you want to upload
- The Upload button - click it to upload a JSON file with a new configuration
- The Delete button - click it to delete the entire system configuration to reconfigure the system
Note that deleting the configuration cannot be reverted.
Audit Log Screen
The Audit log screen allows you to review the activity of users on the Configuration Data screen. The information on the Audit log screen allows you to check which user uploaded or downloaded the Configuration Data JSON file, or performed a wipe of the system. You can also download the Configuration Data JSON file uploaded by another user.
The Audit log screen comprises a grid with the following information:
- Activity - what type of activity did the given user perform
- Result - informs whether the activity was Successful or Failed
- Performed by - identifies the user who performed the activity
- Started at - timestamp when the activity was started
- Completed at - timestamp when the activity was ended
- Actions - a list of actions available to the user. Currently, you can download the Configuration Data JSON file uploaded by another user
Tutorials
How to Upload a Data Configuration?
Prerequisites:
- The file that you want to upload needs to be in the JSON format. Files in different formats will not be uploaded to Fynapse.
- Read the Configuration Data Constraints section.
We recommend downloading a current working data configuration before uploading a new one.
- Go to Configuration > Bulk Operations > Configuration Data.
- Drag a file or click the Select files button.
- Click the Upload button. The system will validate the file and if:
- There are no conflicts in the configuration, then it will be uploaded and the current Fynapse configuration will be overwritten.
- There are any problems with Entities included in the configuration file, the notification about it listing all Entities in conflict or missing will be displayed. In this case, uploading such a configuration will result in data loss of all Entities and data associated with them. You will need to decide if you still want to upload the configuration or cancel uploading. If you decide to proceed with the configuration uploading, then all Entities and data associated with them will be deleted from Fynapse.
How to Download a Currently Used Data Configuration File?
- Go to Configuration > Bulk Operations > Configuration Data.
- Click the Download button. The current data configuration will be saved to a JSON file.
Fynapse ensures the integrity of the system by validating the JSON file upon download. If you make changes in the screen, which cause the configuration to break, and then try to download this configuration, Fynapse will inform you that you are trying to download a broken configuration. The list of errors will be added at the end of the downloaded JSON file.
How to Delete a Currently Used Data Configuration?
We recommend downloading a current working data configuration before deleting it.
- Go to Configuration > Bulk Operations > Configuration Data.
- Click the Delete button.
- Confirm your action by clicking the Delete button. The current data configuration will be deleted.
