Overview

The pages under this section can be used to help guide you through an upgrade of your Cinchy instance on IIS.

Overview

The pages under this section can be used to help guide you through an upgrade of your Cinchy instance.

You are currently browsing the Cinchy v5.7 platform documentation. For documentation about other versions of the platform, please navigate to the relevant space(s) via the drop-down menu in the upper left of the page.

What’s the purpose of Data Collaboration?

Data collaboration aims to facilitate the sharing, management, and utilization of data across various departments, teams, and systems within an organization. This approach aims to eliminate data silos and reduce the inefficiencies associated with traditional data integration methods like ETL processes or APIs. Data collaboration enables multiple stakeholders to co-produce and maintain data in a controlled, federated manner. Doing so enhances data quality, speeds decision-making, and allows more agile and scalable business operations. Data collaboration aims to maximize the business value derived from data while minimizing the costs and complexities traditionally associated with data management.

The root causes of IT delay and frustration.

When a new IT project is green-lit, you often pay a hefty fine called the integration tax, where you're continuously building new integrations between applications just to reuse data that's already available in your systems.

Over time, this never-ending cycle of copying data between fragmented apps gets more complex, resulting in delayed launches, budget overruns, and “shadow IT” projects.

Facing the rising costs and complexities of traditional data integration? You're not alone. At Cinchy, we understand that the 'Integration Tax' is a growing burden for modern organizations. As your enterprise expands its technology stack, the maze of required integrations becomes exponentially more intricate and expensive to manage. It's not just about initial setup; maintenance, updates, and reconfigurations add up, consuming a large portion of your IT budget and holding back your agility.

“Every year, as the level of new technologies and digital transformation grows, the amount spent on integration increases. So much so that companies collectively spend $700B globally.”

Source: Large Integration Company

That's where Cinchy's Data Collaboration Platform comes in. By introducing a platform designed for co-production, we radically reduce the need for complex integrations. Our platform enables various departments, teams, and systems to collaborate directly on data, effectively eliminating the need for redundant, copy-based integrations. This federated approach to data management means that you maintain control while empowering co-producers to contribute to a shared, dynamic data landscape. The result? A significant reduction in the 'Integration Tax,' liberating your IT resources to focus on delivering real business value. Say goodbye to old-school integration's crippling costs and complexities, and welcome a new era of scalable, efficient data collaboration.

How can this be fixed?

Using Data "Co-Production" to Accelerate IT Delivery

With data collaboration, you shift your approach from copy-based integration for sharing back and forth between collaborators to using an access-based real-time approach.

For every co-production use case built using cinchy, you're avoiding what otherwise would have been a bespoke integration-heavy solution. Also, individual solutions now "pay it forward" by liberating relevant data to participate in future collaboration use cases without any integration effort.

The Cinchy data collaboration platform does for data what the power grid does for electricity. In the same way that buildings no longer need to generate their power thanks to the power grid, with a data collaboration platform, new solutions no longer need to manage, integrate, and protect their own data (Image 4).

Not just connected, but autonomous.

​Simply putting pipes between data silos and centralizing a few housekeeping tasks isn't data collaboration. What that's doing is leading you down a path of managing endless copies. True data collaboration connects and upgrades your data as part of an interconnected autonomous data network.

Autonomous data exists independently of any application. It's self-controlled, self-protected, and self-describing. This creates several benefits compared to traditional app-dependent data, including simplifying cross-application usage and reporting. When you use autonomous data in an interconnected network, wherein individual contributors maintain their roles and priorities as they apply their unique skills and leadership autonomy in a problem-solving process, you get Collaborative Autonomy.

Collaborative Autonomy is the principle underpinning Collaborative Intelligence, the basis of data collaboration and Cinchy.

Individuals aren't homogenized, as in consensus-driven processes, nor equalized through quantitative data processing, as in collective intelligence. Consensus isn't required. Problem resolution is achieved through systematic convergence toward coherent results. Collaborative intelligence relies on Collaborative Autonomy to overcome “the consensus barrier” and succeed where other methods have failed.

Universal access controls and automated data governance

One of the most significant advantages of data collaboration is the ease with which data owners can set universal data access controls at the cellular level and automate data governance.

In effect, it removes the need to maintain access controls within individual apps and centralizes these functions incredibly efficiently.

Compare this with designing and maintaining controls within thousands of apps and systems.

Game Changer: Network Effects for IT Delivery

Data collaboration is a game changer for IT delivery: it produces network effects, where each new solution actually speeds up delivery times and reduces costs.

Network-based designs scale beautifully and become more efficient as they expand. Consider the human brain; its neuroplasticity helps it learn more as it grows. The more interconnected it gets, the better. The neural pathways are reorganizing themselves such that the fewer connections, the higher the intelligence, because information is easier to put to use.

It's the same with data collaboration. The more you connect your data, the simpler your world becomes. And it's also your time machine - you can have applications based on different points in time of your data, and it's all done through network-based design.

There is no going back.

Let's build the connected future, together.

Upgrading on Kubernetes

When it comes time to upgrade your various components, you can do so by updating the version number in your configuration files and applying the changes in ArgoCD.

Configure to the newest version

1. Navigate to your cinchy devops.automation repository

   1. Navigate to your deployment.json (You may have renamed this during your original Kubernetes deployment)

   2. In the cinchy_instance_configs section, navigate to the image tags. Replace the version number with the instance that you wish to deploy (Ex: v5.2.0 > 5.3.0).

1. Rerun the deployment script by using the following command in the root directory of your devops.automations repository:

3. Commit and push your changes.

Apply the configurations

If your environment isn't set-up to automatically apply upon configuration, complete the following the apply the newest version:

1. Navigate to the ArgoCD portal.

2. Refresh your component(s). If that doesn't work, re-sync.

Upgrading on IIS

The following process can be run when upgrading from v5.0 to v5.1 on IIS.

Prerequisites

1. Take a backup of your database.

2. Extract thefor the version you wish to upgrade to.

Upgrade process

1. Merge the following configs with your current instance configs:

   • Cinchy/web.config

   • Cinchy/appsettings.json

   • CinchySSO/appsettings.json

   • CinchySSO/web.config

2. Execute the following command:

1. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.

2. Execute the following command:

1. Open your Cinchy URL in your browser.

2. Ensure you can log in.

The pages under this section deal with upgrading your Cinchy platform.

Additional notes

• If you are currently running Cinchy v4+ or v5+ and wish to upgrade your components, please review the documentation here:

• If you are currently running Cinchy v4+ and wish to upgrade to v5+, please review the documentation here:

Introduction

Cinchy v5 on Kubernetes offers and recommends a robust set of open-source tools and applications for monitoring, logging, and visualizing the data on your Cinchy instances.

Click on the respective tool below to learn more about it:

Upgrading on IIS

The following process can be run when upgrading any v5.x instance to Cinchy v5.3 on IIS.

Prerequisites

1. Take a backup of your database.

2. Extract the new build for the version you wish to upgrade to.

Upgrade Process

1. Merge the following configs with your current instance configs:

   • Cinchy/web.config

   • Cinchy/appsettings.json

   • CinchySSO/appsettings.json

   • CinchySSO/web.config

2. Execute the following command:

iisreset -stop 

1. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.

2. Execute the following command:

iisreset -start 

1. Open your Cinchy URL in your browser.

2. Ensure you can log in.

Upgrading on Kubernetes

When it comes time to upgrade your various components, you can do so by updating the version number in your configuration files and applying the changes in ArgoCD.

Configure to the newest version

1. Navigate to your Cinchy devops.automation repository

   1. Navigate to your deployment.json (You may have renamed this during your original Kubernetes deployment)

   2. In the cinchy_instance_configs section, navigate to the image tags. Replace the version number with the instance that you wish to deploy (Ex: v5.0.0 > 5.1.0).

  // The component image tags are specified below to define which versions to deploy
  "connections_image_tag": "v5.1.0",
  "event_listener_image_tag": "v5.1.0",
  "idp_image_tag": "v5.1.0",
  "maintenance_cli_image_tag": "v5.1.0",
  "meta_forms_image_tag": "v5.1.0",
  "web_image_tag": "v5.1.0",
  "worker_image_tag": "v5.1.0"

2. Rerun the deployment script by using the following command in the root directory of your devops.automations repository:

dotnet Cinchy.DevOps.Automations.dll "deployment.json"

3. Commit and push your changes.

Apply your Configurations

If your environment isn't set-up to automatically apply upon configuration, complete the following the apply the newest version:

1. Navigate to the ArgoCD portal.

2. Refresh your component(s). If that doesn't work, re-sync.

Overview

This page details some best practices for version history in Cinchy. These recommendations are important because they can help:

• Minimize your database bloat/size.

• Make it easier to parse through version history when there aren't hundreds of redundant records.

Best practices

• When doing any type of update statement, it's best to include an opposite “where” clause to avoid creating unnecessary history for unchanged values.

  • For example, if your update was set name to Marc, you would include a where name doesn't already equal Marc. Doing so prevents a redundant update in your version history.

UPDATE
	[Contacts].[Employees] 
SET [Name] = Marc
WHERE [Name] != Marc

• When writing an update statement, run it more than once. If it results in an update each time, return to your query and troubleshoot.

  • This is relevant anywhere the statement can be run repeatedly, such as in APIs or Post Sync Scripts.

• In data syncs, ensure that your data types are matched properly.

  • For example, if the source is text and the target is data, even if the values are the same, it will update and create unnecessary version history.

• When performing a data sync, run it more than once. If it creates an update each time, return to your configuration and troubleshoot.

Your Cinchy Profile has three (3) components that can be changed from user preferences:

• ​My Photo​

• ​My Profile​

• ​My Password​

My Photo

To add a photo to your profile, complete the following (Image 1):

1. From My Network, click the avatar icon

2. Select My Profile

3. From the settings page click on the my photo image

4. Locate and upload your photo

My Profile

From the settings page in the My Profile section you are able to update the language, region, and time zone (Image 2).

My Password

If you don't see the password option in My Profile, you must be logging on to Cinchy using Single Sign-On and won't need to update your password within Cinchy.​

To change your password, complete the following:

1. In the Old Password field, enter in your existing password

2. In the New Password field, enter a new password

3. In the Confirm New Password field, re-enter in your new password

Disable your applications

There might be times when you want to temporarily disable your Kubernetes pods to perform maintenance or upgrades. You can do so through the following steps:

1. Access your ArgoCD.

2. Navigate to the application directory for the namespace you wish to disable, in this case development-cinchy (Image 1). You should see your cluster component applications.

1. Select the main application (development-cinchy) (Image 2).

1. Navigate to Summary > Sync Policy > Automated, then select Disable Auto-Sync > OK (Image 3).

1. For each of the cluster applications that you wish to disable, select the "..." > Delete (Image 5).

1. Your apps should all appear as "out of sync" (Image 6).

Re-enable your applications

1. To re-enable your applications, return to the application directory for your disabled namespace (Image 7).

1. Select the main application (i.e. development-cinchy) (Image 8).

1. Navigate to Summary > Sync Policy, then select Enable Auto-Sync > OK (Image 9).

If you need to manage space within your database, you can set a data compression policy. Currently we allow you to permanently delete versions in the collaboration log. Be aware that the current version of compression is a LOSSY process (data will be permanently deleted). Take that into consideration when configuring a policy.

The actual compression of data happens during the maintenance window. Please check with your system administrators to confirm when maintenance is scheduled.

Change approval enabled tables

The number of versions is based on the major version and not the minor version. This means for a record on version 35.63 with a keep most recent 10 versions, it will keep all versions 26.0 +, rather than all versions 35.44+.

Overview

Data erasure allows you to permanently delete data in Cinchy. As the data owner, you can set an erasure policy on your table if you need to delete data for compliance reasons (Image 1).

The actual erasing of data happens during the maintenance window. Please check with your system administrators to confirm when maintenance is scheduled.

Once data is erased, any links pointing to erased data will look like this (Image 2):

Change approval enabled tables

The time is counted based on the record's modified time stamp, not the deleted time stamp. This means for change approval records it's the time when the pending delete request was approved and moved to the Recycle Bin, not when the delete request was made.

Overview

You now have the option to use personal access tokens (PATs) in Cinchy, which are alternatives to using passwords for authentication. Like , you can use a Cinchy PAT to call the Cinchy API as your current user, meaning your associated access controls will be honoured as well. Cinchy PATs, however, have an expiration date of up to 1 year. A single user can have up to 5 PATs active at one time. See for details on using a PAT in lieu of a Bearer token.

Create a PAT

1. From the Cinchy homepage, navigate to your User Settings > Tokens. Any tokens that you make will appear here. You will also be able to see any expired tokens.

1. Click Generate New Token.

1. Input the following information about your PAT and click Generate:

2. Token Name

3. Description

4. Expiration

1. Once generated, make sure to copy down the PAT somewhere secure. You won't be able to view the PAT again once you navigate away from this screen.

Deletes a PAT

1. From the Cinchy homepage, navigate to your User Settings > Tokens. Any tokens that you make will appear here.

2. Click the “Delete” button next to the applicable PAT.

Use a PAT in an API

Cinchy PATs can be used in much the same way that Bearer tokens are used for in . For example, in the Authorization header with the value: Bearer <token>.

You may also wish to review the information on

Data version management

Cinchy natively and automatically manages data versioning in the platform through the ‘always-on’ version tracking, collaboration logging, and recycle bin features (data restore).

Cinchy maintains a version history of all changes to every data element stored in Cinchy. You can query the version history in Cinchy to speed up analysis, and can also be viewed through the , which tracks changes made by users, systems, or external applications (Image 1). When required, you can easily revert data to previous states using the or the Revert button.

Schema version management

Your schema/data model version can also be managed when you are using multiple environments. For example, if you have a DEV environment and make a change to a table design (ex: changing a column name), you can export and deploy your data model to a PROD environment and Cinchy will intelligently consolidate and merge the schema changes to adhere to the latest version.

To export a table (like your data model), navigate to the Design Table > Export button (Image 2). You can then import your data model into any other environment using the (Image 3).

This functionality is achieved through the use and synchronization of GUIDs. Each data element in Cinchy (table, column, etc.) will have a matching GUID, which stays consistent even across multiple environments. That means that changes made in your source environment will automatically and accurately be applied once promoted to your higher environment.

You can find the GUID for your object by navigating to the applicable System Table. Ex: Column GUIDs can be found in the Columns table (Image 4).

Create data packages

While you are able to manually export/import data models across environments, you may want to package up multiple objects (tables, queries, reference data, etc.) and push that all together between environments. This method still adheres to schema version control and management.

This can be accomplished using the Cinchy DXD Utility, which you can learn more about by .

Overview

The Kubernetes project runs a community-owned image registry called registry.k8s.io in which to host its container images. On April 3rd, 2023, the registry k8s.gcr.io was deprecated and no further images for Kubernetes and related subprojects are being pushed to this location.

**Instead, there is a new registry: **registry.k8s.io.

New Cinchy Deployments: this change will be automatically reflected in your installation.

For Current Cinchy Deployments: please follow the instructions outlined in this upgrade guide to ensure your components are pointed to the correct image repo.

You can review the full details on this change here: https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/

Update Instructions

1. In a shell/terminal, run the below command to get a list of all the pods that are pointing to the old registry: k8s.gcr.io. These will need to be updated to point to the new image registry.

1. Once you find which pods are using old image registry, you need to update its deployment/daemonset/stateful set with new registry.k8s.io registry. Find the right resource type for your pods with below command:

1. Once you have your pod name and resource type, run the below command to open the manifest file in an editor:

1. In the editor, find any instances of k8s.gcr.io and replace it with registry.k8s.io.

2. Save and close the file.

3. Repeat steps 3-5 for the rest of your pods until they're all pointing to the correct registry.

System tables are included out-of-the-box with your Cinchy platform, and can be used to track and manage a variety of data.

You can easily query for a list of your system tables using the below:

The system tables included are:

• Applets: This system table manages a list of all your integrated applications

• Data Experience Definitions: This is a system table for managing data experience definitions

• Data Experience References: This is a system table for managing reference data for data experiences

• Data Experience Release Artifacts: This is a system table for maintaining data experience release artifacts

• Data Experience Releases: This is a system table for maintaining data experience releases

• Data Security Classifications: This is a system table for maintaining data security classifications

• Data Sync Configurations: This system table manages a list of all your data sync configurations.

• Domains: This system table manages a list of all the domains in your instance.

• Execution Log: This system table tracks the execution logs of data syncs

• Formatting Rules: This system table manages your formatting rules

• Groups: System table for managing all groups

• Literal Groups: This system table maintains a list of groups

• Literal Translations: This system table maintains a list of literal translations

• Literals: This system table maintains a list of literals

• Regions: This system table maintains a list of regions

• Saved Queries: This system table manages a list of all user saved queries that can be exposed via the REST API

• System Colours: System table for maintaining colours

• Table Access Control: This system table maintains a list of all table access controls in your instance

• Table Columns: This system table manages a list of all the system column definitions

• Tables: This system table manages a list of all the tables in your instance.

• User Defined Functions: This system table manages a list of all your user defined functions

• Users: System table for managing all user information including enabling/disabling the ability to create tables, queries, etc.

• Views: This system table manages a list of all the views in your instance.

Upgrading on IIS

The following process can be run when upgrading any v5.x instance to v5.4 on IIS.

Prerequisites

1. Take a backup of your database.

2. Extract thefor the version you wish to upgrade to.

Upgrade Process

1. Merge the following configs with your current instance configs:

   • Cinchy/web.config

   • Cinchy/appsettings.json

   • CinchySSO/appsettings.json

   • CinchySSO/web.config

2. If you are upgrading to 5.4+ on an SQL Server Database, you will need to make a change to your connectionString in both your SSO and Cinchy appsettings.json. Adding will allow you to bypass the certificate chain during validation.

   Ex:

3. Execute the following command:

1. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.

2. Execute the following command:

1. Open your Cinchy URL in your browser.

7. Ensure you can log in.

Overview

This page documents the method of restoring deleted tables, columns, and rows in your Cinchy table.

Restore a deleted row

To restore a row that has been deleted:

1. In the table where you want to restore the row, navigate to the Recycle Bin.

2. Locate the deleted row.

3. Right click anywhere in the row > Restore Row (Image 1).

4. You should see a "Restore Successful" pop-up.

Restore a deleted or changed column

To restore a column that has been deleted or changed:

1. Navigate to the [Cinchy].[Tables] table.

2. Find the row with the table that has the column you want to restore > right click anywhere in the row > Collaboration Log > Revert to a previous version (Image 2).

3. You should see a "Revert Successful" pop-up.

Restore a deleted table

To restore a table that has been deleted:

1. Navigate to the [Cinchy].[Tables] table.

2. Navigate to the Recycle Bin.

3. Find the row with the table that you want to restore > right click > "Restore Row" (Image 3)

4. You should see a "Restore Successful" pop-up.

Administrators

The “Admins” of the Cinchy platform are users who belong to the "Cinchy Administrators" User Group.

Admin types

Cinchy Admins fall into two categories:

• .

Builder Admins

A Builder Admin can:

• Modify all table data (including system tables), all schema, and all data controls.

  • This includes setting up and configuring users, assigning them to groups, and assigning which users have builder access.

• View all tables (including system tables) and queries in the platform.

End-User Admins

An End-User Admin can:

• View all tables (including system tables) and queries in the platform.

• Modify data controls for tables.

Manage Admins

To view and manage who has administrator access, you will use the Groups.

Builder Admin management

A builder is able to view which users are part of the "Administrators" group via the "Groups" system table; either in the data browser or by using a saved/ad-hoc query.

If you are an admin, you can also use the "Groups" table to add or remove users from the "Administrators" Group.

End-User Admin management

An End-User Admin is able to view which users are part of the "Administrators" group via the "Groups" system table; either in the data browser or by using a saved query.

Columns

This section has formatting rules available for columns.

Row Condition

This follows the same syntax as a view filter query.

Ordinal

Order in which the formatting rules will apply on the same table. Ordinal 1 will show up above ordinal 2.

Highlight Color

Color to highlight the cell. If you want to add your own colors you can do so within System Colours and check off highlight under usage.

Table

Table in which to apply the conditional formatting.

Highlight Columns

Columns to apply the conditional formatting rules to. You don't need to include any row condition columns within the highlight columns.

Example

You can view the admin panel of your Cinchy instance by This is only reachable if you are logged in as a user with admin access. The admin panel includes the following sections:

Cinchy Healthcheck

The Cinchy Healthcheck shows information about your system such as current version, IP Address, the system time, and your database status (Image 1).

Cinchy log files

This section shows a list of viewable log files from your system, as well as their size, creation time, and last modified time (Image 2).

Upload a logo

Review the for information on uploading a logo.

Overview

You are able to attach files and images to any row in a Cinchy table by creating a linked column that also links to the 'Files' system table of your platform.

If you have access to view the 'Files' table, you can also view every attachment on your system.

Attach a file

1. Navigate to the table where you want to attach your file.

2. Click Design Table > Columns

3. Add a new column with the following parameters (Image 1):

   1. Column Name: Cinchy recommends using a straightforward name like "Images and Files"

   2. Data Type: Link

   3. Linked Table: You will link this to the "Cinchy\Files" table

   4. Linked Column: File Name

   5. Advanced Settings: Make sure to select the "Multi-select" checkbox if you want the capability to add more than one file to a row.

1. Click Save

2. Navigate back to your table and locate your newly created files column.

1. To attach a file, click on the upload button (located in the top right hand corner of any cell in the column) (Image 2).

1. From the pop-up window, select Choose Files to pick your file from your machine, then click Submit (Image 3).

1. Once uploaded, your cell should look like this (Image 4):

Delete an attached file

To fully delete your attachment from the platform, you will need to navigate to the Files system table and delete the row associated with your attachment.

Your file will appear crossed out in your original table and can't be opened or downloaded (Image 5).

Overview

AKS (Azure Kubernetes Service) is a managed K8 service used when deploying Cinchy v5 over Azure. Once you have deployed your v5 instance of Cinchy, you may want to upgrade your AKS to a newer version. You can do so with the below guide.

Prerequisites

Before proceeding for the AKS version upgrade, ensure that you have enough IP address space, as this process will need to start new nodes and pods.

You will need more than 1024 IP addresses in total when you have single Cinchy instance/environment.

If you have limited IP address space, you can upgrade the master node and then the worker node pools one by one.

Upgrading AKS

1. Navigate to your ArgoCD Dashboard.

2. Find and click on your Istio app > disable auto-sync.

3. Find and click on your Istio-ingress app > disable auto-sync.

4. Open a terminal and run the following command to get the currently available Kubernetes versions for AKS, inputting your AKS cluster name and resource group where specified:

az aks get-upgrades --resource-group <myresourcegroup> --name <myaksclustername> --output table

1. Within your cinchy.devops.automations folder/repo, navigate to the deployment-azure.json file and change the values for kubernetes_version and orchestrator_version to the currently available Kubernetes version found in step 4.

2. Within the cinchy.devops.automations folder/repo, run the following command to push your new values:

dotnet Cinchy.DevOps.Automations.dll deployment-azure.json

1. Within your cinchy.terraform/azure/aks_cluster/ directory, run bash create.sh and accept the change.

2. AKS has three node pools, one node pool per availability zone. Terraform will now start the upgrade of the master node and the zone1 node pool.

3. Verify which nodes that the istio-ingressgateway and istiod pods are running on with below command.

kubectl get pods -n istio-system -o wide

1. In the output you will see aks-zone1/2/3-xxxxx under the Nodes column.

If one or both pods are running on aks-zone1-xxxxx then you need to scale up replicas 2 by following steps 12-14. If not, skip to step 15.

1. Use the following command to start replica on zone2 or zone3 nodes; once you scale down it will terminate from zone1 upgrading nodes.

kubectl scale --replicas=2 deployment.apps/istio-ingressgateway -n istio-system
kubectl scale --replicas=2 deployment.apps/istiod -n istio-system

1. Verify that new pods are running on other node pool by running the following command:

kubectl get pods -n istio-system -o wide

1. Run the following command to scale it back. This will remove the pod from cordoned node:

kubectl scale --replicas=1 deployment.apps/istio-ingressgateway -n istio-system
kubectl scale --replicas=1 deployment.apps/istiod -n istio-system
kubectl get pods -n istio-system -o wide

1. Once Maser node and zone1 upgrade is done, you will see a message such as:

module.aks.azurerm_kubernetes_cluster.main: Modifications complete after 9m23s [id=/subscriptions/e5d6912-eeaa-461c-8f6-30e7c6d945a/resourceGroups/<vnet>/providers/Microsoft.ContainerService/managedClusters/<myaksclustername>]

1. The Terraform script will continue with the zone2 and zone3 node pool upgrade. You will see messages like the below when thee zone2 and zone3 node pool upgrade is in process:

module.aks-node-pool.azurerm_kubernetes_cluster_node_pool.node_pool["zone2"]: Modifying... [id=/subscriptions/ed16912-eeaa-461c-8f36-30e76de945a/resourceGroups/<vnet>/providers/Microsoft.ContainerService/managedClusters/<myaksclustername>/agentPools/zone2]`

`module.aks-node-pool.azurerm_kubernetes_cluster_node_pool.node_pool["zone3"]: Modifying... [id=/subscriptions/e5d1612-eeaa-461c-8f36-30e7c6e945a/resourceGroups/<vnet>/providers/Microsoft.ContainerService/managedClusters/<myaksclustername>/agentPools/zone3]

1. Repeat steps 11-13. This will make sure that istio-ingressgateway and istiod are running on zone1 nodes.

2. Return to your ArgoCD dashboard and re-enable the auto sync for Istio and Istio-ingress apps auto sync on ArgoCD dashboard.

Create queries

Cinchy Builders and Users have the capability to create ad-hoc queries, however only Cinchy Users can create saved queries. For more information on how to create queries, see creating a saved query.

Execute queries

Cinchy Users can execute pre-built queries based on their access.

You can find a list of saved queries on your network by navigating to the Saved Queries table (Image 1). You can then search the Cinchy homepage for the saved query to execute it.

Generate pivot tables

Once you have executed the query, click the Grid drop down list and select Pivot. Here is where you can take your standard table view and slice and dice your data (Image 2).

Generate charts

From within your pivot view, open the drop down list with the value “table” and select the type of chart you want to use to display the data (Image 3).

Build shared visualizations

Once you have a desired visualization, that visualization can be made available for others as an applet in Cinchy. Grab the Pivot URL and send it to your Cinchy builder to create your mini applet that can be shared and leveraged!

To copy the Pivot URL to build have a visualization created, complete the following:

1. From within the Pivot, locate the blue Pivot URL

2. Click Pivot URL button

3. Click the Copy button

4. Send the copied URL to your Cinchy builder to create your applet that can be shared and leveraged!

Overview

Linking is done by the Cinchy ID, which is unique. When you create a link column, you select a column to link to. This is simply a decision on which field to show from the linked record. You should pick a unique field to link on to avoid confusion if possible.

Once a record is created, its Cinchy ID never changes. This means that modifying the row of data in the linked table won't change the relationship in your table to that row. This also means that if you didn't use a unique column, even though the UI looks the same, you are actually linking to different rows.‌

Choose a linked column

‌In general, you should only use unique columns as the linked column. This needs to be balanced with readability in other tables.

For example, Full Name might not be unique to every employee, but it's more readable and understandable than Employee ID. In other cases, it makes sense to link via an ID and add a display column to show relevant information.‌

Allow Linking

‌To help other builders follow best practices of only linking to unique (or close to unique, such as Full Name) columns, you should un-check the Allow Linking checkbox for non-unique columns so they won't be able to use it for linking.‌

Allow Display in Linked View

‌If this option is unchecked, it prevents users from showing this column in another table.

For example, if you have an ID card # within an employees table, you may not want to display it to the rest of the company because it simply would not be relevant when they're linking to employees and want to see additional information (such as department, title, location). Arguably, a lot of these columns are also taken care of by access controls (since most people won't have access to view that column).‌

Deselecting this box should be done sparingly, as it doesn't impact the security of your data, only how convenient it's to see it.‌

Display Columns

‌When you select a record to link to on the Manage Data screen, it can be useful to see additional information about the records to ensure that it's the record you want to link to (Image 1). You can add additional display columns in the advanced options for link columns (Image 2).

When you type in the cell, all displayed columns will be searched through, not just the Linked Column (Image 3). (Green doesn't have a B in it, but #00B050 does so the Green record shows up)

‌

Link Filter

‌The link filter filters out records from the drop down list. This is useful for reducing the options to only the typical use case. Commonly used for filtering the drop down to a list of active users or other resources, while not preventing someone from entering missing records with inactive resources.‌

This is only a display filter; it doesn't prevent other values from being entered as long as they're valid records in the linked table.‌

Relationships

‌You can define 1 to 1, 1 to many, and many to many relationships.‌

1:1 Relationship

‌Generally it's rare to link 1:1 relationships since they should usually be in the same table. For example, you would not have a separate table for Employee Phone Number and Employee Address, they would simply be two columns within the Employees table. However there are cases nonetheless where it makes sense, for example, a Keycard tracking table where each keycard has 1 assigned employee.‌

To enforce a 1:1 relationship within Cinchy, you set the unique constraint and leave it as single-select when creating a link column.‌

1:Many Relationship

‌A common relationship to have is a one to many relationship. For example, one customer can have multiple invoices.‌

To enforce a 1:many relationship within Cinchy, you want to create a link column in the table on the “many” side of the relationship (in the above example, in the invoices table) and leave the link column as single select.‌

Many:Many Relationship

‌You can also have a many to many relationship. For example, you can have multiple customers, and multiple products. Each customer can order multiple products, and each product can be ordered by multiple customers. Another example is books and authors. An author can write multiple books, but a book can also have multiple authors. You can express many to many relationships in two ways.‌

For the use case of multiple customers and multiple products, you can use orders as an intermediary table to create indirect relationships between customers and products. Each order has one customer, and each order has multiple products in it. You can derive the relationship between customers and products through the orders table.‌

To create a many:many relationship through a different entity, you want to create a table for orders. Within orders, you want to create a single-select link to customers and a multi-select link to products.‌

For the use case of books and authors, it makes sense to create a multi-select link column in the Books table where multiple authors can be selected.‌

To create a multi-select link column in Cinchy, you select the Multi-Select option when you create a new link column.

Introduction

The Data Experience has required updates you must create in your source environment. You don't want to have to repeat the updates in both the source and target environments. The upcoming section will show how to update the data experience in the source environment so that you can then re-package and reinstall in the target environment.

Table updates

1. Log back into your source environment using the following: URL: <Cinchy source url> User ID: <source user id> Password: <source password>

2. Make the following changes to the Currency Exchange Rate table:

3. Save your changes before leaving the table.

Query updates

1. Update the Currency Converter query to reflect column name changes that were made in the Table Updates section above (Image 1).

1. Test the query to validate that it's still functioning (Image 2 and 3).

1. Save your query.

New capabilities

• Cinchy on : You can now deploy Cinchy v5 on the Kubernetes system. Kubernetes is an open-source system that manages and automates the full lifecycle of container-based applications. You now have the ability to deploy Cinchy v5 on Kubernetes, and with it comes a myriad of features that help to simplify your deployment and enhance your scaling. Kubernetes can maximize your container capacity and easily scale up/down with your current operations.

  • : Available to those who deploy on Kubernetes, Fluent Bit collects logs which are then displayed through the OpenSearch visual dashboard, for all pods that write to stdout. This streamlines your search for information by putting the control into your hands and compiling your logs in one easy to access place—you can now easily write a query against all of your logs, in all of your environments. You will have access to a default configuration out of the box, but you can also customize your dashboards as well.

  • and : With the Kubernetes addition, you now have access to Prometheus to collect your metrics. Prometheus records real-time metrics in a time series database used for event monitoring and alerting. You can then create custom dashboards through Grafana to display your data in an easy to use visual that makes reporting on your metrics easy, and even set up push alerts based on your custom needs.

  • : You now have the option to deploy Cinchy on PostgreSQL, an open source alternative to the Microsoft SQL Server that can save you the cost of licensing fees. It's standards-compliant, reliable, highly programmable, and allows for concurrency. Utilizing this deployment makes Cinchy more affordable and scalable. We recommend for AWS users.

  • : Kafka is an open-source event streaming platform. This is designed to act as the middleware that allows for messaging between components through a queuing mechanism.

  • : Redis is currently being used to facilitate a distributed lock using RedLock, which guarantees lock synchronizations across Cinchy instances. It's also a storage location for the execution output when running batch data syncs.

• All components have been transitioned from Log4Net to Serilog.

• The BuildIdentifier property from the appsettings.json will now appear in the healthcheck endpoint at the root level of the JSON payload, with a key of buildidentifier.

Enhancements

• ELMAH was removed from the platform.

• Refactored hidden passwords in initialization.

• Added the ability to ingest S3 data sources for delimited or parquet files.

• Improved performance of the Connection UI when there is a large (250+) number of columns/mappings.

• Optimization of bulk UPSERT performance.

• Added the following UI optimizations for handling large tables: default views set to collapsed, page size limited to 1k records, and added a button for getting the row count. Added the ability for Connections to read/write error files to S3 when an S3 bucket is specified.

• Added accessibility fixes.

• We've added support for PUT, PATCH, and DELETE in UDF Extensions in addition to GET/POST.

• You are able to override a Kafka topic within the appsettings.json for Connections, the Worker, and the Event Listener.

CQL Updates

• We've added support for the INSERT INTO SELECT statement, which copies data from one table and inserts it into another table. on INSERT INTO SELECT.

• When using PostGres, the SELECT @cinchy_row_id function will fail in queries. Instead, use the OUTPUT clause with INSERT, UPDATE, DELETE. on OUTPUT.

• We've added support for the TRUNCATE TABLE statement, which removes all rows from a table, without logging the individual row deletions. on TRUNCATE TABLE. (Please note that we don't support the "With Partitions" argument.)

Bug Fixes

• Fixed an issue where two users approving data could cause the row to become corrupted.

• Addressed a memory leak in query translation issue through the creation of a background task that removes expired objects from the cache.

• Fixed an issue where updating the formula of a non-cached calculated column wouldn’t reflect properly in the Table Columns table.

• Addressed an issue where changing a field in a table with multi-select links results in the removal of the field value from the version history.

• Fixed an API issue when updating UDF columns.

• Fixed an issue where numeric calculated columns that resolved off of a link column's numeric display column wouldn't work.

• Enabling of Content-Type headers to be added for REST API data syncs during GET requests.

Security Fixes

• Added frame-ancestors to the UI to prevent UI redress attacks.

• Implemented HSTS headers for when HTTPS is enabled on Cinchy.

Views

When you first create a table, a default view called All Data will be created for you under Manage Data. Cinchy builders can create different views for users to manage their data in Cinchy where Views can be filtered and/or sorted according to the requirements.

To switch between views, select the view from the left navigation toolbar under Manage Data (Image 1).

Filters

Users can filter data in a view for one or more columns. Filters persist when users navigate from one view to another. The number of filter criteria is identified against the filter icon (Image 2).

Column display

Users can add, remove or rearrange the columns in a view based on how they need the data represented in the View (Image 3).

Add a column to a view:

1. Click Display Columns in the top toolbar

2. From the ‘Add a Column’ drop down, locate and select the appropriate column.

3. Ensure you click ‘Apply’ to save.

Remove a column from a view:

1. Click Display Columns in the top toolbar

2. Click the “X” to the right of the column name to remove.

3. Ensure you click ‘Apply’ to save.

Rearrange the columns in a view:

1. Click Display Columns in the top toolbar

2. Drag the column to the appropriate location in the list of visible columns.

3. Ensure you click ‘Apply’ to save.

Sorting

Users can sort data in a view for one or more columns. Sorting can be done by clicking on a column to sort in ascending or descending order (Image 4).

Sorting can also be done by clicking on the Sorting button and selecting the column(s) to be sorted and the order in which the sorting should occur (Image 5).

Scrolling

Scrolling “Top” & “Bottom” allows you to jump from the top to the bottom of a view without scrolling (Image 6).

Row height

Row height can be either Collapsed or Expanded using the Row Height drop-down (Image 7).

You can manually resize a row (or multiple rows if you select more of them). You can also double click on the default row number on the left to auto expand the row height.

Freeze or unfreeze rows or columns

Cinchy allows you to freeze and unfreeze a row/columns.

1. Select the row/column for freezing/unfreezing

2. Right-click on the row and select Freeze/Unfreeze Row/Column from the menu (Image 8).

Upgrading on Kubernetes

When it comes time to upgrade your various components, you can do so by following the below instructions.

Prerequisites

• Download the latest Cinchy Artifacts from the Cinchy Releases Table > Kubernetes Artifacts column (Image 1). For this upgrade, please download the Cinchy v5.4 k8s-template.zip file.

Take your platform offline

1. Turn off your Cinchy platform. In a Kubernetes deployment,

Configure to the newest version

1. Navigate to your cinchy.argocd repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

2. Navigate to your cinchy.kubernetes repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

1. Navigate to your cinchy.terraform repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

2. Navigate to your cinchy.devops.automation repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

3. Open the new Cinchy v5.4 k8s-template.zip file you downloaded from the Cinchy Releases table.

4. Navigate to the new aws.json/azure.json files and compare them with your current deployment.json file. Any additional fields in the new aws.json/azure.json files should be added to your current deployment.json.

1. Open a shell/terminal from the cinchy.devops.automations directory and execute the following command:

1. Commit all your changes (if there were any) in each repository.

2. If there were any changes in your cinchy.argocd repository you may need to redeploy ArgoCD.

   1. Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.

   2. Execute the following command to deploy ArgoCD:

1. If there were any change to the cluster components, execute the following command from the cinchy.argocd repository:

1. If there were any change to the Cinchy instance, execute the following command from the cinchy.argocd repository:

1. Log in to your ArgoCD application console and refresh the apps to ensure that all changes were picked up.

Turn on the platform and apply your configurations

1. Turn your platform back on. In a Kubernetes deployment,

End-Users

The “End-Users” of the Cinchy platform are those that apply the functionalities created by the “Cinchy Builders” to their business objectives. This can be employees, customers, partners, or systems. Cinchy has two types of end-users: direct and indirect.

• Direct Users log into Cinchy via the data browser

• Indirect Users (also commonly referred to as "external users") view/edit data via a third-party application/page that connects to Cinchy via API

What can end-users do?

Cinchy End-Users are able to:

• Create and save personal queries. Unlike traditional saved queries made by builders, personal saved queries can't be shared and aren't auto exposed as APIs.

• Use Tables, Saved Queries, and Experiences created by

• Track version history for the full lifecycle of data

• Bookmark and manage data

• Access data through application experiences

• An end-user can be part of the

View and manage data through a single UI

Cinchy’s data collaboration platform features a Universal Data Browser that allows users to view, change, analyze, and otherwise interact with all data on the network. The Data Browser even enables non-technical business users to manage and update data, build models, and set controls, all through an easy and intuitive UI.

Only see the accessible data

Data on the network is protected by cellular-level access controls, data-driven entitlements, and superior data governance. This means that users can only view, edit, or manipulate data that has been granted access to from the data owner (Image 1).

Track version history for full data lifecycle

All data is automatically version-controlled and can be reverted to previous states with the proper permissions. On all data tables, you can see changes made by users, systems, or external applications through Data Synchronization or by using a Collaboration Log (Image 2).

Access saved queries on the data network

Users can access and run saved queries that are available to them through the Data Marketplace. All queries respect Universal Access Controls meaning you will only see the data that you have access to (Image 3).

Bookmark and manage data in a secure marketplace

Users can also access all accessible tables, queries, and applets through the Cinchy Marketplace. Here you can also order tiles and bookmark favourites (Image 4).

Access data through rich application experiences

Users can also experience their data through custom application experiences that are created by Builders on the platform. All application experiences also respect Universal Access Controls meaning you will only be able to see the data you have been granted access.

Here is an example Experience (Image 5):

Upgrading on Kubernetes

When it comes time to upgrade your various components, you can do so by following the below instructions.

"cinchy_instance_configs": {
          "database_connection_string": "User ID=cinchy;Password=<password>;Host=<

Prerequisites

• Download the latest Cinchy Artifacts from the Cinchy Releases Table > Kubernetes Artifacts column (Image 1). For this upgrade, please download the Cinchy v5.5 k8s-template.zip file.

Configure to the newest version

1. Navigate to your cinchy.argocd repository. Delete all existing folder structure except for the .git folder/directory and any custom changes you may have implemented.

2. Navigate to your cinchy.kubernetes repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

1. Navigate to your cinchy.terraform repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented.

2. Navigate to your cinchy.devops.automation repository. Delete all existing folder structure except for the .git file and any custom changes you may have implemented and your deployment.json.

3. Open the new Cinchy v5.4 k8s-template.zip file you downloaded from the Cinchy Releases table and check the files into their respective cinchy.kubernetes, cinchy.argocd, cinchy.terraform and cinchy.devops.automation repositories.

4. Navigate to the new aws.json/azure.json files and compare them with your current deployment.json file. Any additional fields in the new aws.json/azure.json files should be added to your current deployment.json.

"cinchy_instance_configs": {
          "database_connection_string": "User ID=cinchy;Password=;Host=;Port=5432;Database=development;Timeout=300;Keepalive=300;TrustServerCertificate=True",

1. Open a shell/terminal from the cinchy.devops.automations directory and execute the following command:

dotnet Cinchy.DevOps.Automations.dll "deployment.json"

1. Commit all your changes (if there were any) in each repository.

2. If there were any changes in your cinchy.argocd repository you may need to redeploy ArgoCD.

   1. Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.

   2. Execute the following command to deploy ArgoCD:

bash deploy_argocd.sh

1. If there were any change to the cluster components, execute the following command from the cinchy.argocd repository:

bash deploy_cluster_components.sh

1. If there were any change to the Cinchy instance, execute the following command from the cinchy.argocd repository:

bash deploy_cinchy_components.sh

1. Log in to your ArgoCD application console and refresh the apps to ensure that all changes were picked up.

1. Navigate to the CinchySSO Folder > appsettings.json file.

2. Find the following line:

add key="TlsVersion" value=""

1. Replace the above line with the following:

add key="TlsVersion" value="1.2"

1. Navigate to the Cinchy Folder > web.config file.

2. Find the following line:

add key="TlsVersion" value=""

1. Replace the above line with the following:

add key="TlsVersion" value="1.2" 

1. Restart the application pools in IIS for the changes to take effect.

Cinchy Upgrade Utility

The Cinchy Upgrade Utility was previously introduced in v5.2 to facilitate a mandatory INT to BigInt upgrade. This tool will continue to be used in subsequent releases as an easy way to deploy necessary changes to your Cinchy platform.

For version 5.5, you must run the Upgrade Utility to fix a row-breaking issue that could be triggered on cells with over 4000 characters, where you are unable to update any column in your record.

Please review the Utility Guide or Upgrade Guide for further details.

New: Personal Access Tokens

You now have the option to use personal access tokens (PATs) in Cinchy, which are alternatives to using passwords for authentication. Similar to Cinchy Bearer Tokens, you can use a Cinchy PAT to call the Cinchy API as your current user, meaning your associated access controls will be honoured as well. Cinchy PATs, however, have an expiration date of up to 1 year. A single user can have up to 5 PATs active at one time.

For information on setting up, configuring, and managing PATs, please review the documentation here.

MongoDB

We've added MongoDB to our Connections offering as both a source and target connector.

MongoDB is a scalable, flexible NoSQL document database platform known for its horizontal scaling and load balancing capabilities, which has given application developers an unprecedented level of flexibility and scalability.

Review the following documentation to use this new capability in Cinchy:

• Setting up a MongoDB Collection (Event Triggered) as a source connector

• Setting up a MongoDB Collection as a source connector

• Setting up MongoDB as a target connector

• Setting up a MongoDB change stream

Enhancements

• We're continuing to improve our text editor functionality for forms. You can now embed tables and images into your text. We've also made various styling and usability quality of life updates, including the addition of checkbox style lists.

• We've added support for ephemeral volumes in Connections on a Kubernetes deployment. Unlike persistent volumes, ephemeral storage is unstructured and the space is shared between all pods running on a node**;** it allows pods to be started and stopped without being limited to the location of persistent volume. Running more than one pod for Connections per availability zone enables you to effectively leverage auto scaling functionality.

• We've updated the Connections experience to enable more use cases. You can now use CDC parameters in Calculated Columns and use the CinchyID in the sync key in real-time syncs.

• Kafka supports cluster encryption and authentication, which can encrypt data-in-transit between your applications and Kafka. We've added the ability to include this encryption/authentication in the Listener Config when setting up real-time syncs using Kafka.

  • Using this parameter will specify which protocol will be used for communication between client and server. Cinchy currently supports the following options: Plaintext, SaslPlaintext, or SaslSsl.

    • Paintext: Unauthenticated, non-encrypted.

    • SaslPlaintext: SASL-based authentication, non-encrypted.

    • SaslSSL: SASL-based authentication, TLS-based encryption.

  • Review the Listener Config documentation on Kafka here.

• We've improved the implementation of tooltips such that linked columns display the tables that they link to. Hovering over the i symbol on a linked column will show the linked domain and table in the following format: Domain - Table; ex: HR - Employees. You can now also see them in the grid view.

• We've introduced a Retry Configuration for REST API sources and targets. This will automatically retry HTTP Requests on failure based on a defined set of conditions. This capability provides a mechanism to recover from transient errors such as network disruptions or temporary service outages.

  • For more information on using this configuration, refer to the documentation here for REST sources and here for REST targets.

• We've increased the default retention for Prometheus from 5GB to 50GB to allow you to store more metric data at a time.

  • This change is automatically reflected in new v5.5 deployments. Customers on previous v5 versions wishing to implement the change are able to rerun the automation script and deploy the new template to reflect the update.

• To make the Forms experience more responsive and process quicker, we've introduced lazy loading of records while searching. Instead of loading and rendering every form record in the search box, which can be a slow process for use cases with millions of records, lazy loading will initially retrieve a limited number of records. These results can then be further optimized by inputting your Lookup Filter Conditions.

• We've added the ability to pass parameters from a REST response into post sync scripts during both real-time and batch data syncs, allowing you to do more with your REST API data.

  • For an example and instructions on this capability, please refer to the documentation here.

• Data changes in Cinchy (CDC) can now be used to trigger a data sync from a REST API or MongoDB data source to a specified target. This works as an alternative to RunQuery.

  • For more information, please review the documentation here (REST API) and here (MongoDB).

• We've added two new functions, JSON_ESCAPE and URL_ESCAPE, which can be used in Connections to escape parameter values when used in constructing the body of a REST API Request or in the URL

• We've added an Authorization header type for REST API data syncs in Connections. An authorization request header can be used to provide credentials that authenticate a user with a server, allowing access to a protected resource. Selecting this header defines the Header Value as a password field.

Bug Fixes

• We've solved an issue that was causing Connections to get stuck behind long running jobs despite there being capacity to execute. This fix enables predictable execution behavior without stoppage.

• We've fixed an issue in the MatchEngine where execution was failing in versions of Cinchy above 5.2.

• File sourced data syncs will no longer fail, allowing you to run Connection jobs with uploaded files without the risk of a file not found error when auto scaling is enabled.

• To prevent needlessly exhausting Cinchy IDs, the platform will no longer continuously retry to update records that have failed to save. This can sometimes occur when a value causes a calculated field to violate a uniqueness constraint. If the below error appears, you will have to manually update the cell to retry the save.

• We've fixed a bug that was causing the Connections UI to crash if you attempted to run a job while there was an empty parameter in the Info tab (ex: no name or formula)

• We've fixed a bug that would causes images in Forms to sometimes appear with a label above them, using the image's URL as the label's value.

• We've fixed a bug that was forcibly terminating authenticated sessions in Grafana, now allowing you to work without interruptions.

• We've solved an issue where using a form as a child form with file links wouldn't render the link thumbnail correctly in the "edit record" view.

• We've fixed a bug that prevented record updates when multiple users attempted to update a row in too quick of a succession.

• We've fixed an issue where doing delta batch syncs with a REST API target wouldn’t replace the @COLUMN parameter correctly.

• We've fixed a bug in Connections where an Oracle sync target would have the wrong tag in the Config XML.

• We've fixed a bug that was causing a “Listener is running” message to erroneously appear when the status of the listener was actually set to Disabled.

• We've fixed a bug that was preventing REST API real-time sync execution errors from being inserted into the execution errors table.

Deprecation of the k8s.gcr.io Kubernetes Image Repository

The Kubernetes project runs a community-owned image registry called registry.k8s.io in which to host its container images. On April 3rd, 2023, the registry k8s.gcr.io was deprecated and no further images for Kubernetes and related subprojects are being pushed to this location.

Instead, there is a new registry: registry.k8s.io.

New Cinchy Deployments: this change will be automatically reflected in your installation.

For Current Cinchy Deployments: please follow the instructions outlined in the upgrade guide to ensure your components are pointed to the correct image repository.

You can review the full details on this change on the Kubernetes blog.

Connections UI Change to Sync Behaviours Tab

To continuously improve our Connections experience, we've made changes to the Sync Behaviours tab for Full-File data syncs.

• Record behaviour is now presented via radio buttons so that you can see and select options quicker and easier than ever before.

• We've added a new "Conditional" option for Changed Record Behaviours. When Conditional is selected, you will be able to define the conditions upon which an Update should occur. For instance, you can set your condition such that an update will only occur when a "Status" column is changed to Red, otherwise it will ignore the changed record. This new feature provides more granularity on the type of data being synced into your destination and allows for more detailed use cases. For more information on this new function please review the documentation here.

Enhancements

Deployment

We've added support AWS EKS EBS volume encryption for customers wishing to take advantage of industry-standard AES-256 data encryption without having to build, maintain, and secure their own key management infrastructure.

By default, the EKS worker nodes will have a gp3 storage class for new deployments. If you are already running a Cinchy environment: make sure to keep your eks_persistent_apps_storage_class to gp2 within the DevOps automation aws.json file.

If you want to move to gp3 storage or gp3 storage and volume encryption: you will have to delete the existing volumes/pvc's for Kafka, Redis, OpenSearch, Logging Operator and Event Listener with StatefulSets so that ArgoCD can recreate the proper resources.

Should your Kafka cluster pods not come back online after deleting the existing volumes/pvc's, restart the Kafka operators. You can verify the change by running the below command:

kubectl get pvc --all-namespaces

Platform

• Miscellaneous security fixes.

• General CDC performance optimizations.

Connections

• Continuing to increase our data sync capabilities and features, you can now use @CinchyID as a parameter in post sync scripts when the source is from a Cinchy Event (such as the Event Broker, the Event Triggered REST API, and the Event Triggered MongoDB sources). This means that you can now design post sync scripts that take advantage of the unique CinchyID value of your records.

• To better communicate the relationship between the Source and any required Listener Configurations, we've added additional help text to event-based sources to the Source step of a connection. This text will help explain when a listener configuration is required as part of the sync.

• We've expanded on our Cinchy Event Triggered data sync source features (REST API and MongoDB), allowing you more freedom to utilize your data. You now have the ability to reference attributes of the CDC Event in your calculated columns. (Note that syncs making use of this must limit their batch size to 1.)

• To better enable your business security and permission-based needs, you are now able to run the Connections pod under a service account that uses an AWS IAM (Identity and Access Management) role, which is an IAM identity that you can create to have specific permissions and access to your AWS resources. To set up an AWS IAM role for use in Connections, please review the documentation here.

• You are also able to use AWS IAM roles when syncing S3 file or DynamoDB sources in Connections. For more information, please review the "Auth Type" field in the relevant data sync source pages.

• To increase your data sync security and streamline authentication, we've added support for the use of x.509 certificate authentication for MongoDB Collection Sources, MongoDB (Cinchy Event Triggered) Sources, and MongoDB Targets. This new feature can be accessed directly from the Connections UI when configuring your data sync. For more information, please review the configuration pages for MongoDB Collection Source, MongoDB (Cinchy Event Triggered) Source, and MongoDB Targets.

Bug Fixes

Platform

• We've fixed a bug that was causing bearer token authenticated APIs to stop working on insecure HTTP Cinchy environments.

• We've fixed an issue relating to the .NET 6 upgrade that was causing the Event Listener and Worker to not start as a service on IIS in v5.4+ deployments.

• We've fixed a “Column doesn’t exist” error that could occur in PostGres deployments when incrementing a column (ex: changing a column data type from number to text).

• We've fixed a bug where table views containing only a single linked column record would appear blank for users with “read-only” permissions.

Connections

• We've fixed a bug where the Listener Configuration message for a data sync using the MongoDB Event source would return as "running" after it was disabled during an exception event -- the message will now correctly return an error in this case.

• We've fixed a bug that was preventing DELETE actions from occurring when Change Approvals were enabled on a CDC source.

• In continuing to provide useful troubleshooting tools, we've fixed a bug that was preventing dead messages from appearing in the Execution Errors table when errors occurred during the open connection phase of a target. This error may have also occurred when a MongoDB target had a connection string pointing to a non-existent port/server.

• We've fixed a bug that was preventing Action Type column values of "Delete" from working with REST API target Delta syncs.

• We've fixed a data sync issue preventing users from using environment variables or other parameters in connection strings.

• We've fixed a bug in the Polling Event data sync where records would fail with a “unique constraint violation” if both an insert and an update statement happened at nearly the same time. To implement this fix, you need to add the “messageKeyExpression” parameter to your listener config when using the Polling Event as a source.

• We've fixed a bug that was causing data syncs to fail when doing platform event inserts of any type into Salesforce targets.

• We've fixed a bug where using the ID Column in a Snowflake target sync would prevent insert and update operations from working.

• We've fixed a bug where attempting to sync documents using a UUID (Universally Unique IDentifier) as a source ID in a MongoDB Event Triggered batch sync would result in a blank UUID value when saved to a Cinchy table.

Meta-Forms

We've made application stability and quality fixes to Forms, including:

• Custom date formats now work in Grid, Form, and Child Form views.

• A child form that has a Link column reference to a parent record now auto populates with the parent record's identity.

• A space has now been added between multi-select values when displaying a record in an embedded child table.

• Negative numbers can now be entered into Number type inputs on forms.

• We've fixed an issue where updated file attachments on a form would fail to save.

CQL

• We've fixed a bug that was causing a “Can’t be Bound" error when you attempted to use an UPDATE query on a multi-select link column as a user with multiple filters active.

Homepage

Once you log in to Cinchy, you'll be on the Homepage (Image 1). From here, you can navigate to a variety of tables, queries, and applets you have access to.

You can return to this page at any time by clicking the Cinchy logo in the top left corner.

Searching

‌All objects you have access to in your Marketplace (including bookmarks) are searchable and can be filtered by typing the partial or full name of the object you are searching for in the search bar (Image 2).

You can also search by object type by clicking on either Tables, Queries, or Experiences in the toolbar.

Bookmarks

‌You can bookmark your most often used objects and rearrange them to your liking within your bookmarks.

To bookmark an object, select the star. The star will be yellow when bookmarked, and grey when not (Image 3).

The object will pop into your “Bookmark” section. To rearrange your bookmark, drag and drop the object into the desired order.

Network Map

You "Network Map" shows a visualization of all tables in Cinchy you have access to and how they're all connected (Image 4).

Each of the coloured circles represents an object in Cinchy. The lines between them show the links between them.

You are able to search and open tables from this view using the search bar on the left (Image 5).

You can see what the network looked like in the past by clicking and dragging the pink circle along the timeline at the bottom.

Network Map extra parameters

Cinchy v5.2 added the ability to include new parameters on the URL path for your network visualizer to focus your node view. You can now add Target Node, Depth Level, and Max Depth Level parameters.

Example: <base url>/apps/datanetworkvisualizer?targetNode=&maxDepth=&depthLevel=

• Target Node: Using the Target Node parameter defines which of your nodes will be the central node from which all connections branch from.

  • Target Node uses the TableID number, which you can find in the URL of any table.

  • Example: <base url>/apps/datanetworkvisualizer?targetNode=8 will show TableID 8 as the central node

• Max Depths: This parameter defines how many levels of network hierarchy you want to display.

  • Example: <base url>/apps/datanetworkvisualizer?maxDepth=2 will only show you two levels of connections.

• Depth Level: Depth Level is a UI parameter that will highlight/focus on a certain depth of connections.

  • Example: <base url>/apps/datanetworkvisualizer?DepthLevel=1 will highlight all first level network connections, while the rest will appear muted.

The below example visualizer uses the following URL (Image 6): <base url>/apps/datanetworkvisualizer?targetNode=8&maxDepth=2&depthLevel=1

• It shows Table ID 8 ("Groups") as the central node.

• It only displays the Max Depth of 2 connections from the central node.

• It highlights the nodes that have a Depth Level of 1 from the central node.

Logo

You can upload a custom logo to appear on your platform login screen and homepage. You will need to have admin access to do so.

Examples without a logo uploaded (Images 7&8)

Examples with a logo uploaded (Images 9&10)

Upload a logo

1. Navigate to <base url>/admin/index

2. Scroll to the bottom of the admin panel and navigate to the “Upload Logo” button.

3. Upload your logo.

Remove a Logo

1. Once uploaded, your logo is stored in the System Properties table_._

2. Navigate to the table and find the row with Name: Logo (Image 12)

1. Delete the Logo row to remove the logo.

Translate API

Translation API

POST <Cinchy-URL>/API/Translate

Pass in a list of literal GUIDs, along with a language and region. If translations are found in that language, they will be returned.

Request Body

Logic

• If the translation exists in the language and region specified, it will be returned.

• If the translation exists in the language but not the specified region, it will still be translated and returned.

• If the GUID exists but it's not available in the specified language, the default text in the Literals table will return.

• If the GUID doesn't exist or you don't have permission to it, it will return the GUID back as the translation.

System Tables

Cinchy has three tables to provide language support.

1. [Cinchy].[Literal Groups]

2. [Cinchy].[Literals]

3. [Cinchy].[Literal Translations].

Literal Groups

This table can optionally be used to group the translations. The default Cinchy strings belong to the Cinchy literal group. We recommend you create one literal group per applet or UI so you can retrieve the full list of GUIDs required for that page/applet easily.

Literals

This table defines all the strings that you want to translate.

Default Text

String that displays if no translation is found for the language specified.

GUID

GUID used to refer to the literal. A UUID will be generated by default, but can be overrode using the GUID Override field to something more human-readable.

Literal Group

Use this to group your strings so they can be easily retrieved. Note that this is a multi-select so you can use a single literal for multiple applets (including using the default Cinchy literals and translations for custom applets).

Literal Translations

This is the table where the translations are stored.

Translated Text

This is the translated string that's returned.

Literal

This is the literal the translation is for.

Language and Region

A language must be specified for a translation. Region can also be optionally specified for region specific words (ex. color vs colour).​

Cinchy Builders

Cinchy Builders use the Cinchy platform to build an unlimited number of business capabilities and use-cases.

The “Cinchy Builder” has access to perform the following capabilities:

• Change Table Schema (use Cinchy’s “Design Table” functionality)

• Grant access (use Cinchy’s “Design Controls” functionality)

• Edit Cinchy Data in Cinchy System Tables

• Create, Save, and Share Cinchy Queries

• Perform Cinchy Queries on the Cinchy data network

• Import/export packaged business capabilities (like deployment packages)

• Build Cinchy Experiences

• Perform integration with Cinchy (such as Cinchy Command Line Interface [CLI] operations)

• Create and Deliver an unlimited number of Customer Use Cases within Cinchy

• A builder can be part of the

The End-Users of the Cinchy platform are those that use the functionalities created by the “Cinchy Builders” to their business objectives.

of the Cinchy Platform can:

• Use Tables, Saved Queries, and Experiences created by “Builders”

What Builders do

Builders can leverage Cinchy as one platform to simplify solutions delivery as they:

1. Connect

2. Protect

3. Collaborate

4. Build

5. Reuse

Connect

Create your new network of data

Data collaboration eliminates point-to-point integration, reducing cost and complexity (including real-time, batch, on-prem, cloud, legacy, and SaaS services) and allowing custom data-sync configurations. This drives faster time to market, lower costs and improved usability.

Connect data to make silos and integration obsolete

When you connect a new data source to your data network, you can use it with data from any other source on the network with no further integration efforts. The more sources you connect, the more powerful and efficient it becomes. You can extend data on the network with attributes and entirely new entities, including calculated data, derived data, AI models, and user-managed data.

Protect

Manage and protect data down to the individual cell

Data on Cinchy is protected by cellular-level access controls, data-driven entitlements, and superior data governance. This includes meta architecture, versioning, and write-specific business functions that restrict user views, such as a managed hierarchy. Owner-defined permissions are universally enforced, significantly reducing the effort of managing them at the enterprise level. You can use existing Active Directory and SSO access policies to set controls for an individual user, external system, or user-defined functions (such as approving updates row by row or using bulk approvals).

Collaborate

Track version history for full lifecycle of data

All data is automatically version-controlled and can be reverted to previous states. You can see changes made by users, systems, or external applications through Data Synchronization or by using a Collaboration Log.

View and manage data through a single UI

Use the universal Data Browser to view, change, analyze, and otherwise interact with ALL data on the Fabric. Non-technical business users can manage and update data, build models, and set controls, all through an easy and intuitive UI.

Build

Create and share queries

Cinchy’s data collaboration platform features an intuitive Drag and Drop Query Builder that allows Builders to create using the Cinchy Query Language (), a proprietary language specific to Cinchy. All queries can be saved and shared, and query results automatically generate a full no-code API.

Consolidate legacy systems, create new solutions

By decoupling the data from the application, our Autonomous Data Network lets you consolidate legacy applications to increase operational agility and reduce overhead. You can create enterprise-grade solutions using the Application SDK as quickly as you would build Excel-based solutions and without the operational risk. Application SDK (React Native, Angular, and REST SDKs) lets you build custom applications for end users.

Add third-party visualization tools

For even more flexibility, connect your Data Network to third-party Data Visualization tools. You’ll be able to run cross-queries against all data on the Fabric while maintaining universal access policies for users, systems, and external applications.

Re-use

The more you use data collaboration, the more it’s capable of doing.

Any new data you add to the network will work in conjunction with any previously existing data instantly. This means you can re-use data in new ways, with no time-consuming integration efforts. Teams can collaborate directly in real-time, allowing it to act as a central data hub while simplifying integration. Unlike traditional data architecture projects, which grow more complicated as they involve more data sources, data collaboration delivers solutions faster and faster as more data is added to it.

Infrastructure configuration (on cluster)

The diagram below shows a high level overview of a possible Infrastructure diagram with components on the cluster, but your specific configuration may vary (Image 1).

AWS infrastructure configuration (outside cluster)

When deploying Cinchy version 5 on Kubernetes, you may deploy via Amazon Web Services (AWS). The diagram below shows a high level overview of a possible AWS Infrastructure with components outside the cluster, but your specific configuration may vary (Image 2).

Infrastructure component overview

Azure infrastructure configuration (outside cluster)

When deploying Cinchy v5 on Kubernetes, you may deploy via Microsoft Azure. The diagram below shows a high level overview of possible Azure Infrastructure with components outside the cluster, but your specific configuration may vary (Image 3).

Infrastructure component overview

Cluster level component overview

The following highlighted area provides a high-level overview of cluster level components used when deploying Cinchy on Kubernetes and what versions they're running.

These are created once per cluster. Clients may choose to run these components outside of the cluster or replace with their own comparable components. This diagram shows them in the cluster (Image 4).

Cluster level components

These are created once per cluster. Clients may choose to run these components outside of the cluster or replace with their own comparable components.

• Service Mesh - : Istio handles and routes all inbound traffic to your Cinchy instance, keeping it secure and managed.

• Monitoring/Alerting - & Prometheus consumes metrics from the running components in your environment, which you can visualize into user friendly graphs and dashboards by Grafana. Prometheus can also connect to third party services to provide alerting capabilities. Both Prometheus and Grafana use persistent storage.

• Logging - and : OpenSearch captures and indexes all logs in a single, accessible location. These logs can be queried, searched, and filtered, and Correlation IDs mean that they can also be traced across various components. These logging components take advantage of persistent storage.

• Caching - : Redis facilitates a distributed lock using RedLock, which guarantees lock synchronizations across Cinchy instances. It's also a storage location for the execution output when running batch data syncs.

• Event Processing - : This acts as the middleware for messaging between components through a queuing mechanism. Kafka features persistent storage.

Cluster configuration

Before you deploy Cinchy on Kubernetes, consider the following about your cluster configuration :

• How many clusters will you need?

• Will you be sharing from an existing cluster?

• Will you be running multiple environments on a single cluster?

Instance component overview

Each Cinchy instance uses the following components to either provide an experience to users/applications or connect data in/out of Cinchy. You can deploy multiple Cinchy instances per cluster, so these components will repeat for each environment.

The following highlighted area provides a high-level overview of instance level components used when running Cinchy on Kubernetes (Image 5).

• Meta Experiences: Cinchy offers pre-packaged experiences that you can import into your Cinchy environment and use on your data network. This includes experiences like and .

• Connections: Use the Cinchy Connections experience to create data syncs in/out of the platform. It features persistent storage.

• Data Browser: Cinchy’s data collaboration platform features a Universal Data Browser that allows users to view, change, analyze, and otherwise interact with all data on the network. The Data Browser even enables non-technical business users to manage and update data, build models, and set controls, all through an easy and intuitive UI.

• Identity Provider: An Identity Provider (IdP) creates and manages user credentials and associated identity attributes. Cinchy uses IdPs authentication services to authenticate end-users.

• Event Listener: The Event Listener picks up events from connected sources during a data sync. Review the for further information on the Event Listener. The Event Listener uses persistent storage.

• Event Stream Worker: The Event Stream Worker processes data picked up by the Event Listener during data syncs. Review the for further information on the Event Stream Worker. The Event Worker uses persistent storage.

• Maintenance (Batch Jobs): Cinchy through the CLI. This includes the data erasure and data compression deletions.

GitOps

is a declarative, GitOps continuous delivery tool for Kubernetes that simplifies the application deployment and lifecycle management. ArgoCD is highly recommended for deploying Cinchy, but you can also use another tool.

Once you set up the configurations, ArgoCD automates the deployment of the desired application states into your specified target environments. Implemented as a Kubernetes controller, it continuously monitors running applications and compares the current, live state against the desired target state (as specified in your repositories).

Contact support

If at any point you require help or clarification on this documentation or your Cinchy platform, you can reach out to our Support team:

• Via email: [email protected]

• Via phone: 1-888-792-6051

• Through the support portal:

1. Execute the following commands in any folder to generate the self-signed certificate:

openssl genrsa -des3 -out rootCA.key 4096

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt

openssl genrsa -out mydomain.com.key 2048

openssl req -new -sha256 -key mydomain.com.key -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=mydomain.com " -out mydomain.com.csr

1. Create a YAML file located at cinchy.kubernetes/platform_components/base/self-signed-ssl-root-ca.yaml.

2. Add the following to the YAML file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: self-signed-ca-pemstore
data:
  rootCA.crt: |
    <rootCA.crt>

1. Add the self signed root CA cert file to the cinchy.kubernetes/environment_kustomizations/cinchy_nonprod/base folder.

2. Add the yaml code snippet to the cinchy.kubernetes/environment_kustomizations/cinchy_nonprod/base/kustomization.yaml file, changing the below files key value as per your root ca cert file name:

configMapGenerator:
- name: self-signed-ca-pemstore
  behavior: replace
  files:
  - rootCA.crt

1. Add the following line to the cinchy.kubernetes/platform_components/base/kustomization.yaml file

- self-signed-ssl-root-ca.yaml

1. Add the below Deployment patchesJson6902 to each of your cinchy.kubernetes/environment_kustomizations/cinchy_nonprod/ENV_NAME/PLATFORM_COMPONENT_NAME/kustomization.yaml files, except base.

• Ensure that the rootCA.crt file name is matched with ConfigMap data, configMapGenerator files, and the patch subpath.

    - op: add
      path: /spec/template/spec/volumes/-
      value: 
        configMap:
          name: self-signed-ca-pemstore
        name: self-signed-ca-pemstore  
    - op: add
      path: /spec/template/spec/containers/0/volumeMounts/-
      value: 
        mountPath: /etc/ssl/certs/rootCA.crt
        name: self-signed-ca-pemstore
        subPath: rootCA.crt

1. Once the changes are deployed, verify the root CA cert is available on the pod under /etc/ssl/certs with below command. Make sure to input your own POD_NAME and NAMESPACE:

 kubectl exec -it POD_NAME -n NAMESPACE -- openssl x509 -in /etc/ssl/certs/rootCA.crt -text

Upgrading on IIS

This process can be run when upgrading from a Cinchy version that's not v5.0+.

Prerequisites

1. Follow this guide to take a backup of your database.

2. Extract the new build for the version you wish to upgrade to.

Upgrade process

1. Swap out the following configs with your current instance configs:

   1. Cinchy/web.config

   2. CinchySSO/appsettings.json

   3. Log4net.config

   4. Web.config

2. Execute the following command:

iisreset -stop

1. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.

2. Execute the following command:

iisreset -start

1. Start Cinchy in your browser.

New Connector

• A new connector has been added to the Cinchy Connections experience: you can now use Snowflake as a source and target connector when performing data syncs. You can review the documentation on connecting as a source here and as a target here.

GraphQL API Beta Release

• Our GraphQL API provides a complete and understandable description of your data and gives you the power to ask for exactly what data you need and nothing more all in a single request, while leveraging the existing ecosystem of GraphQL developer tools.

• This is a beta release that offers read-only queries. Future releases will include more query features and mutation support (writes).

Enhancements

Connections

• Performing Data Sync from Cinchy to Salesforce no longer requires write access to the sync key column. This means that you can maintain your Salesforce environment and security protocols without needing to either modify them or create additional attributes, for your sync to work.

• We've introduced a new STRING_ESCAPE() function that escapes single quotes when wrapped around data sync parameters. It uses the following syntax to wrap around parameters or column references respectively: STRING_ESCAPE(@COLUMN('yourcolumn')) or STRING_ESCAPE(@yourparameter). This function is particularly useful when used in a post sync script's CQL.

Data Browser

• We've added WCAG 2.1 AA Accessibility fixes to improve screen-reader performance and keyboard navigation accessibility.

• We’ve implemented a new loading screen for when Cinchy is installing and initializing.

Meta Forms

• We've improved the performance of Meta Forms by reducing the rendering time and adding visual guides to help you see which form sections have completed loading.

• Date fields with custom display formats will now render correctly, as opposed to showing up in mm/dd/yyyy format by default.

• In forms that have a 1:1 parent/child hierarchy, we've added the option to render the child form as a flattened form, instead of in a table grid.

• To improve UI consistency across Forms, the record selection drop down will now appear even if no records exist in the destination table.

CQL Updates

• We've added a new function, GetLastModifiedBy([Column]), which will return the CinchyID of the user who last modified the specified column. For more information on this new function, review the documentation here.

Bug Fixes

• We've fixed an error where scrolling in a table with a file column in certain situations prevents the UI from rendering all the data.

• We've fixed an issue where sorting by columns with a ‘%’ in the column name caused the rows not to sort correctly in the UI.

• We've fixed a bug in Meta Forms that prevented queries in child form filters from working as expected when using OR conditions.

Overview

You can delete tables on your Cinchy platform in three ways:

1. Use the "Design Table" tab in the relevant table. This option is available to any user with the "Design Table" entitlement on the table.

2. Use CQL. This option is available to any user with the "Design Table" entitlement on the table.

3. Use the Tables table. This option is available to any user with the "Delete Row" entitlement on the table, which is usually an Administrator.

To ensure that the relevant user has the correct entitlements, you can navigate to the Data Controls > Entitlements tab of the relevant table. The "Design Table" column should be checked off (Image 1).

Delete a table using Design Table

1. Navigate to the table you wish to delete as a user with "Design Table" access on it.

2. Select "Design Table" > "Info" > Delete (Image 2).

Delete a table using CQL

1. Navigate to the Query Builder as a user with "Design Access" on the table you wish to delete.

2. Use the DROP TABLE statement, shown below, to delete your table.

Syntax

DROP TABLE [Domain].[Table_Name]

Example

DROP TABLE [HR].[Employees]

Delete a table using the Tables table

1. Navigate to the Tables table a user with "Delete Row" access, generally an Administrator.

2. Find the row with the table that you want to delete.

3. Right-click on the row > Delete

Enter comments

Anyone who can view or edit a cell can comment on it. Any data that's read-only doesn't allow comments to be entered.

To add a comment:

1. Locate the desired cell

2. Right-click and select comment (Image 1).

3. Enter the comment in the comment window

4. Click "Comment" to finish

Edit comments

Comments can be modified only by only the individual(s) that have created the comment(s).To edit a comment, complete the following:

1. Hover over the comment

2. Click the pencil icon (Image 2).

3. Make the appropriate edit

4. Click the Submit button to save the change

Delete comments

Comments can be deleted only by the individual(s) who has created the comment(s).To delete a comment, complete the following:

1. Hover over the comment

2. Click the garbage bin icon (Image 3).

Archive comments

• A User can archive his own comment regardless of approve permissions

• A User with the Approve All permission can archive any cell comments.

• A User with the Approve Select Cell permission can archive comments on that specific cell

To archive all comments in a cell:

1. Hover over the comment

2. Click the Archive All button (Image 4).

System Table comments

Comments are stored in the [Cinchy].[Comments] table.

Upgrading on IIS

The following process can be run when upgrading any v5.x instance to v5.5 on IIS.

Prerequisites

1. Take a backup of your database.

2. Extract thefor the version you wish to upgrade to.

Upgrade process

1. Merge the following configs with your current instance configs:

   • Cinchy/web.config

   • Cinchy/appsettings.json

   • CinchySSO/appsettings.json

   • CinchySSO/web.config

2. If you are upgrading to 5.5 on an SQL Server Database and didn't do so in any previous updates, you will need to make a change to your connectionString in both your SSO and Cinchy appsettings.json. Adding will allow you to bypass the certificate chain during validation.

   Ex:

3. Execute the following command:

1. Replace the Cinchy and CinchySSO folders with the new build and your merged configs.

2. Execute the following command:

1. Open your Cinchy URL in your browser.

2. Ensure you can log in.

You can find the Data Controls menu on the left-hand navigation bar of a table.

From here you may select to:

• Change your

Upgrading on Kubernetes

When it comes time to upgrade your various components, you can do so by updating the version number in your configuration files and applying the changes in ArgoCD.

Configure to the newest version

1. Navigate to your Cinchy devops.automation repository

   1. Navigate to your deployment.json (You may have renamed this during your original Kubernetes deployment)

   2. In the cinchy_instance_configs section, navigate to the image tags. Replace the version number with the instance that you wish to deploy (Ex: v5.1.0 > 5.2.0).

1. Rerun the deployment script by using the following command in the root directory of your devops.automations repository:

1. Commit and push your changes.

Apply your configurations

If your environment isn't set-up to automatically apply upon configuration, complete the following the apply the newest version:

1. Navigate to the ArgoCD portal.

2. Refresh your component(s). If that doesn't work, re-sync.

Introduction

This section guides you through the deployment process for Cinchy version 5: from planning all the way through to installation and upgrades.

• If you are looking to deploy Cinchy v5, please start here and read through all the sub-pages:

  • Once you have familiarized yourself with the above documentation, you may move on to either of the below guides, depending on your preference:

• If you are a customer currently on v4 and want to upgrade to v5, start here:

If you have any questions about the processes outlined in this section, please reach out to the Cinchy Support team:

• Via email: [email protected]

• Via phone: 1-888-792-6051

• Through the support portal:

Upgrading on Kubernetes

When it comes time to upgrade your various components, you can do so by following the below instructions.

"cinchy_instance_configs": {
          "database_connection_string": "User ID=cinchy;Password=<password>;Host=<db_hostname>;Port=5432;Database=development;Timeout=300;Keepalive=300;TrustServerCertificate=True"}

Prerequisites

• Download the latest Cinchy Artifacts from the Cinchy Releases Table > Kubernetes Artifacts column (Image 1). For this upgrade, please download the Cinchy v5.6 k8s-template.zip file.

• Review the template changes for this upgrade.

Configuring to the newest version

1. Navigate to your cinchy.argocd repository. Delete all existing folder structure except for the .git folder/directory and any custom changes you may have implemented.

2. Navigate to your cinchy.kubernetes repository. Delete all existing folder structure except for the .git file.

1. Navigate to your cinchy.terraform repository. Delete all existing folder structure except for the .git file.

2. Navigate to your cinchy.devops.automation repository. Delete all existing folder structure except for the .git file and your deployment.json.

3. Open the new Cinchy v5.6 k8s-template.zip file you downloaded from the Cinchy Releases table and check the files into their respective cinchy.kubernete, cinchy.argocd, cinchy.terraform and cinchy.devops.automation repositories.

4. Navigate to the new aws.json/azure.json files and compare them with your current deployment.json file. Any additional fields in the new aws.json/azure.json files should be added to your current deployment.json.

"cinchy_instance_configs": {
          "database_connection_string": "User ID=cinchy;Password=<password>;Host=<db_hostname>;Port=5432;Database=development;Timeout=300;Keepalive=300;TrustServerCertificate=True"},

1. Open a shell/terminal from the cinchy.devops.automations directory and execute the following command:

dotnet Cinchy.DevOps.Automations.dll "deployment.json"

1. Commit all of your changes (if there were any) in each repository.

2. If there were any changes in your cinchy.argocd repository you may need to redeploy ArgoCD.

   1. Launch a shell/terminal with the working directory set to the root of the cinchy.argocd repository.

   2. Execute the following command to deploy ArgoCD:

bash deploy_argocd.sh

1. If there were any change to the cluster components, execute the following command from the cinchy.argocd repository:

bash deploy_cluster_components.sh

1. If there were any change to the Cinchy instance, execute the following command from the cinchy.argocd repository:

bash deploy_cinchy_components.sh

1. Log in to your ArgoCD application console and refresh the apps to ensure that all changes were picked up.

Appendix A

Template changes (Kubernetes 5.6)

• The AWS EKS version has been upgraded to support up to v1.24.

• We've added support for AWS EKS EBS volume encryption. By default EKS worker nodes will have gp3 storage class.

  • For current Cinchy environments you must keep your eks_persistent_apps_storage_class to gp2 in your DevOps automation aws.json file.

  • If you want to move to gp3 storage or gp3 storage and volume encryption, you will have to delete any existing volumes/pvc's for Kafka, Redis, OpenSearch, Logging Operator and Event Listener with statefulset. This ensures that ArgoCD will take care of recreation of resources.

  • If your Kafka cluster pods aren't coming back you must restart your Kafka operators.

  • You can verify the change by running the following command: "kubectl get pvc --all-namespaces".

• The Connections app has changed from StatefulSet to Deployment. The persistence volume has changed to emptyDir.

• We've modified the replica count from 1 to 2 for istiod and istio ingress.

• We've disabled the ArgoCD namespace: istio injection.

  • If this is already enabled on your environment you may keep it as is, such as keeping the cinchy.kubernetes/cluster_components/servicemesh/istio/istio-injection/argocd-ns.yaml file as it's without commenting content in it.

• The Istio namespace injection has been removed.

  • If this is already enabled on your environment please keep it as is -- otherwise it will force you to redeploy all of your Kubernetes application components.

• We've upgraded the AWS Secret Manager CSI Driver to the latest version due to crashing pods.

• We've added support for the EKS EBS CSI driver in lieu of using in-tree EBS storage plugin.

• We've changed the EKS Metrics server port number in order to support newer versions of Kubernetes.

• We've set fixed AWS Terraform providers version for all components.

• We've installed the cluster autoscaler from local charts instead of remote charts.

• The deprecated azurerm_sql_server Terraform resource has been changed to azurerm_mssql_server

• The deprecated azurerm_sql_database resource has been changed to azurerm_mssql_database

• The deprecated azurerm_sql_failover_group has been changed to azurerm_mssql_failover_group

• The deprecated azurerm_sql_firewall_rule has been changed to azurerm_mssql_firewall_rule

Kubernetes vs IIS

When choosing to deploy Cinchy version 5, you must decide whether to deploy via Kubernetes or on a VM (IIS).

Kubernetes is an open-source system that manages and automates the full lifecycle of container-based applications. You now have the ability to deploy Cinchy v5 on Kubernetes, which helps to simplify your deployment and enhance your scaling. Kubernetes can maximize your container capacity and scale up/down with your current operations.

• Grafana, OpenSearch, OpenSearch Dashboard: Working together, these three applications provide a visual logging dashboard for all the information coming in from your database pods. This streamlines your search for information by putting the control into your hands and compiling your logs in one easy to access place — you can now write a query against all your logs, in all your environments. You will have access to a default configuration out of the box, but you can also customize your dashboards as well.

• Prometheus: With the Kubernetes addition, you now have access to Prometheus for your metrics dashboard. Prometheus records real-time metrics in a time series database used for event monitoring and alerting. You can then create custom dashboards to display your data in an easy to use visual that makes reporting on your metrics easy, and even set up push alerts based on your custom needs.

You also have the option to run Cinchy on Microsoft IIS, which was the traditional deployment method before Cinchy v5. Internet Information Services (IIS) for Windows Server is a flexible, secure and manageable Web server for hosting anything on the Web.

Choose a database

Before deploying Cinchy v5, you must select which database you want to use.

The following list outlines the supported databases for Kubernetes Deployments.

For IIS Deployments please review the architecture requirements here.

Microsoft SQL Server

MS SQL Server

• Microsoft SQL Server is a relational database management system. As a database server, it's a software product with the primary function of storing and retrieving data as requested by other software applications—which may run either on the same computer or on another computer across a network.

• Resource limits

Azure SQL Database

• Microsoft Azure SQL Database is a managed cloud database provided as part of Microsoft Azure. It runs on a cloud computing platform, and access to it's provided as a service. Managed database services take care of scalability, backup, and high availability of the database.

• Differences between Azure SQL and Azure Managed SQL

• Resource Limits

Azure Managed SQL Instance

• SQL Managed Instance is a managed, cloud-based, always up-to-date SQL instance that combines broad SQL Server engine compatibility with the benefits of a fully managed PaaS.

• Differences between Azure SQL and Azure Managed SQL

• Resource Limits

Amazon Aurora

Amazon Aurora

• Amazon Aurora (Aurora) is a fully managed relational database engine that's compatible with MySQL and PostgreSQL. It combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. Aurora is part of the managed database service Amazon Relational Database Service (Amazon RDS). Amazon RDS is a cloud web service that makes it easier to set up, operate, and scale a relational database.

• Resource Limits

PostgreSQL

PostgreSQL

• PostgreSQL is a free and open-source relational database management system emphasizing extensibility and SQL compliance. PostgreSQL comes with features aimed to help developers build applications, administrators to protect data integrity and build fault-tolerant environments, and help you manage your data no matter how big or small the dataset.

AWS RDS for PostgreSQL

• Amazon RDS makes it easy to set up, operate, and scale cloud-based PostgreSQL deployments. With Amazon RDS, you can deploy scalable PostgreSQL deployments with cost-efficient and resizable hardware capacity. Amazon RDS manages complex and time-consuming administrative tasks such as PostgreSQL software installation and upgrades; storage management; replication for high availability and read throughput; and backups for disaster recovery. Amazon RDS for PostgreSQL gives you access to the capabilities of the familiar PostgreSQL database engine.

• Resource Limits

Azure PostgreSQL Database

• This is a fully managed and intelligent Azure Database for PostgreSQL. Enjoy high availability with a service-level agreement (SLA) up to 99.99 percent, AI-powered performance optimization, and advanced security. A fully managed database that automates maintenance, patching, and updates. Provision in minutes and independently scale compute or storage in seconds.

• Resource Limits

Sizing considerations and requirements

Before deploying Cinchy v5, you need to define your sizing requirements.

Sizing

Kubernetes sizing

Cluster sizing recommendations vary and are dependant on a number of deployment factors. We've provided the following general sizing recommendations, but encourage you to explore more personalized options.

CPU: 8 Cores

Memory: 32GB Ram

Number of Servers: 3

AWS: m5.2xlarge

Azure: D8 v3

IIS sizing

For sizing recommendations and prerequisites about an IIS deployment, please review the IIS deployment prerequisites.

Application storage requirements

If you are choosing to deploy Cinchy v5 on IIS, then you need to ensure that your VM disks have enough application storage to run your clusters.

Object storage requirements

Cinchy supports both Amazon S3 and Azure Blob Storage.

If you are using Terraform for your Kubernetes deployment, you will need to set up a new S3 compatible bucket to manually to store your state file. You will also need a bucket for Connections, to store error files created during data syncs.

You will create your two S3 compatible buckets using either Amazon or Azure. Ensure that you use the following convention when naming your buckets so that the automation script runs correctly: <org>-<component>-<cluster>. These bucket names will be referenced in your configuration files when you deploy Cinchy on Kubernetes.

Example Terraform Bucket: cinchy-terraform-state

Example Connection Bucket: cinchy-connections-cinchy-nonprod

S3 provides unlimited scalability and it charges only for what you use/how much you store on it, so there are no sizing definitions.

• How to set up an Amazon S3 bucket

• How to set up Azure Blob Storage

Upgrading to v5 on Kubernetes

When you upgrade to Cinchy v5 on Kubernetes you are creating a separate instance. You will need to plan the migration of your database, and then follow the deployment installation guide.

Upgrading to v5 on IIS

To upgrade from v4+ to v5+ on IIS, review the documentation here.

Compatibility issues between databases or versions

If you choose to upgrade to Cinchy v5 on PostgreSQL, please review the following features that aren't currently available in that deployment.

These may be implemented in future versions of the platform.

• No Partitioning

• No Geospatial features

• No Column Indexing

• No Full Text Indexing

• No Column Level Encryption

You may also wish to review the list of CQL functions currently unsupported in PGSQL. Please note that this is a living document and that the development team is actively working on function translations between databases. Make sure to check back for the most up to date information.

• CQL Functions