Storage
Zynk uses a number of files within the the Data directory; from caches of data, application variables, to logs and truth records.
Log Database
Filename: Log.sdf
Format: Microsoft SQL Server Compact
The log file is created when Zynk is installed, and can be re-created by Zynk by closing Zynk, moving the Log.sdf from the Data folder and re-opening Zynk. Any previous workflow or application logs will no longer be available to be viewed within Zynk.
For more detailed information ont the log database and the data available visit the Log Database article.
Workflow Logs
Zynk uses this file to record the history of each run of every workflow; the tasks that were executed when the workflow ran, and any Info, Debug, Warning and Error logs outputted from the run. You can view workflow logs from within Zynk by opening the required workflow and choosing the History tab. From here you choose a specific run of the workflow, and view either all log entries, or choose an individual task to limit the entries. You can control how long log entries are kept by using the History House Keeping setting in the Properties of each workflow file.
Application Logs
The Log.sdf also stores any errors that occur in Zynk but not within a run of a workflow e.g. errors creating schedules. These can be viewed by choosing Tools -> Application Log from the main toolbar.
For more detailed information on the log storage please visit Log Database.
Truth Database
Filename: Zynk.sdf
Format: Microsoft SQL Server Compact
This file is created when Zynk is installed, and can be re-created by Zynk by closing Zynk, moving the Zynk.sdf from from the Data folder and re-opening Zynk. As this files holds information about what information has been processed it is recommend not to remove. If you are moving Zynk to a new machine this should be copied over as part of the migration to ensure there are no issues with data duplication.
The Truth storage is used by Zynk to keep a record of data that has been imported and exported, which is used by a number of tasks. For example, when importing an Order into Sage 50 and the Prevent Duplicates setting is enabled Zynk will look for an existing record with the same Id from the XML file. If there is an existing entry, the order will be skipped and outputted to the fail file, if there is no entry, the order will be processed, and if it is successfully imported, a new record will be created in the truth. Data in the truth can be maintained by opening the required workflow and clicking the Data tab, from here you can remove individual entries, a selection or the entire data set.
There are helper tasks within the Zynk library if granular control of this data is required:-
- Delete Truth Record
- Export Truth Records
- If Truth Record Exists
- Insert Truth Record
- Update Truth Record
- Upsert Truth Records
For more detailed information ont the truth database and the data available visit the Truth Database article.
Variables
Filename: variables.xml
Format: XML
Zynk stores global variables in this file, these are variables that can be accessed from any workflow. You can find more information in our Global Variables articles.
Task Caching
Filename: tasklist.xml
Format: XML
This file is created the first time Zynk is ran and the installed connectors are read. The file can be removed and will be re-created the next time Zynk is ran.
Zynk uses this to cache the tasks available for the current install to speed up opening time. You can manually refresh the task list if you have installed a new connector by choosing Refresh from the context menu of the Task Library or choosing Tools -> Refresh -> Task Library from the main toolbar.
Log Database
This article will outline detailed information regarding the log database that Zynk uses. Typically, this is stored in the default data directory (C:\ProgramData\Zynk Software\Zynk\2.0\Data), although if you have specified a bespoke data directory in Tools -> Options the database file will be located in that directory.
You can configure the archive of historical data in this database via your workflow. By default, this is set to retain the previous 90 days of workflow and application history.
Please note, if you lower this to save disk space and our support team cannot locate error logs it's highly unlikely we will be able to support you.
You can interrogate your database using the free-to-use Zynk extension Zynk Log Manager.
Tables
Log
The log table will store both application and workflow level log messages.
Columns
Please see below a list of available columns on the log table: -
- WorkflowId This field is the GUID related to the workflow that caused the error. This field is blank when the log message does not originate from a workflow.
- TaskId This field is the GUId related to the task that caused the error. This field is blank when the log message does not originate from a task.
- LogType This field indicates the type log that has been registered. For example, error messages have the LogType 'Error' or debug message have the LogType 'Debug'.
- Date This field will give the date and time that the log message was registered.
- JobNumber This field will give you the job that the log message is related to. This field is blank when the log message does not originate from a job.
- Id This field is populated with a uniquely generated identifier.
- Message This field will tell you the message that was logged by Zynk Workflow.
Relationships
Please see below a list of relationships between the log table and the other tables in the log database: -
- Log.WorkflowId -> Job.WorkflowId
- Log.JobNumber -> Job.Id
- Log.JobNumber -> JobItem.JobNumber
- Log.TaskId -> JobItem.TaskId
Job
The job table will store workflow level errors as the each message will relate to a single run of the workflow and the log messages associated with it.
The job table is linked to the job item table which stores each individual task result and the log messages associated with it.
These two tables are linked by the Id column from the job table and the JobNumber column from the job item table.
Columns
Please see below a list of available columns on the job table: -
- WorkflowId This field is the unique identifier that is used to match a job to a workflow.
- StartDate This field indicates the date and time that a workflow run began.
- EndDate This field indicates the date and time that a workflow run ended.
- Result This field will give you the final outcome of a workflow event. For example, a successfully completed workflow would return the result 'Success'.
- Id This field is the unique identifier that is used to match a job item table entry to a job table entry.
- RunType This field will indicate the way in which the workflow was run. For example, a scheduled workflow will be have the RunType set to '2'.
- ArchivePath This field will detail where the archive for the workflow run is stored - if an Archive Workflow Data task was completed within that workflow.
Relationships
Please see below a list of relationships between the job table and the other tables in the log database: -
- Job.WorkflowId -> Log.WorkflowId
- Job.Id -> Log.JobNumber
- Job.Id -> JobItem.JobNumber
Job Item
The job item table will store task level log messages.
The job item table is linked to the job table which stores each workflow result.
These two tables are linked by the Id column from the job table and the JobNumber column from the job item table.
Columns
Please see below a list of available columns on the job item table: -
- JobNumber This field is the unique identifier of the job table entry that the job item table entry is related to.
- TaskName This field will indicate the full name of the task associated with this job item.
- StartDate This field indicates the date and time that a task run began.
- EndDate This field indicates the date and time that a task run ended.
- Result The result field will give you the final outcome of the task. For example, a task that has encountered an error and cannot continue will be marked as 'Fail' or a task that completes successfully will be marked as 'Success'.
- InCount The InCount will give you an exact total of the amount of records passed into the task. For example, if you have a file containing 10 sales orders you are importing into Sage 50, the InCount for your Import Sales Orders task will be 10.
- OutCount The OutCount will give you an exact total of the amount of records passed out of the task. For example, if you run an Export Stock Records task and 10 products are exported, the OutCount will be set to 10. The OutCount can also indicate how many records have been imported successfully.
- ErrorCount The ErrorCount will indicate how many records have failed to be processed. For example, if you try to import 5 sales orders into Sage and 1 fails. Your Import Sales Orders task will have an InCount of 5, an OutCount of 4 and an ErrorCount of 1.
Relationships
Please see below a list of relationships between the job item table and the other tables in the log database: -
- JobItem.TaskId -> Log.TaskId
- JobItem.JobNumber -> Log.JobNumber
- JobItem.JobNumber -> Job.Id
Truth Database
This article will outline detailed information regarding the truth database that Zynk uses. Typically, this is stored in the default data directory (C:\ProgramData\Zynk Software\Zynk\2.0\Data), although if you have specified a bespoke data directory in Tools -> Options the database file will be located in that directory.
You can interrogate your database using the free-to-use Zynk extension Zynk Log Manager.
Tables
Connection
The connection table will store all of the connections you have set up within Zynk. For more information on creating an managing connections from Zynk please see Managing Connections
The following fields are exposed in the connections table:
- Id The unique identifier for the connection table entry.
- Data Serialized XML data of the connection. This can be used to view specific properties on the connection.
- Title The name you have given to identify the connection.
- Type The external system you have connected to, e.g Magento, Sage 50.
- IsDefault This field identifies whether or not you have made the connection default or not. Default connections will automatically be selected as the connection for new tasks added to your workflows.
Truth
The truth table will maintain the integrity of data transitioned through Zynk. It is used mainly for duplicate prevention, although it can also be used for traceability purposes. It's important to note that Truth Records aren't created by all tasks and can also be used in different ways. For example, the Sage 200 Sales Order Import Task uses Truth Records to differentiate between orders and proformas.
Each record with an identifier you pass through Zynk will be logged to this table.
The following fields are exposed in the truth table:
- Id The unique identifier of the truth record.
- Profile This field defines the unique identifier of the workflow the record passed through.
- Type The object name of the record you have processed. For example, if you import a sales order into Sage 50 the type will be 'Zynk.Connect.Sage50.Objects.SalesOrder'
- InternalId The unique identifier given by the parent system
- ExternalId The unique identifier given by the external system.
- Hash - The hash of the truth table entry.
- Created - This field will indicate the date and time that the truth table entry was created.
- Modified - This field will indicate the date and time the truth table entry was created.
Migrating From SqlCe To SQLite
With the release of Zynk 2022.1.1 we introduced support for SQLite databases.
This provides a number of benefits, such as increased reliability and less restriction on file sizes.
Below is a guide on migrating from SqlCe to SQLite:
Migration
1. Stopping the Schedules
If Zynk runs automatically, it's important to make sure this is paused while the migration takes place.
Information on doing this can be found here: Stopping a Workflow
2. Updating Zynk
The next step in migration is to update Zynk to a compatible version.
If you aren't already on 2022.1.1 or above, we recommend installing the latest version of Zynk, available from http://downloads.zynk.com/files/setup.exe
3. Migrating
To begin the migration process, log into Zynk and access the Database menu by going to Tools -> Options -> Database
From here, you should be able to see that both your current Zynk and Log Databases are in SqlCe.
Select the drop down menu for Zynk Database and choose SQLite from the drop down menu.
Select the "Create Database" option.
Once the database has been successfully created, choose the "Migrate Data" option.
In the Database Migration window that appears, ensure that Source is set to Zynk.sdf and Destination is set to Zynk.db
From the final drop down menu you can choose to migrate All Data or Records Since and specify a timestamp.
Once all the settings are in place, choose Start to begin the migration.
Notes
- Although the migration steps above describe migrating the Zynk.sdf database, the steps for migrating Log.sdf are exactly the same.
- The time taken for the migration is completely dependent on the amount of data present in the databases and how much you are keeping.
- We recommend migrating All Data wherever possible to avoid issues with duplication