What’s the purpose of Dataware and Data Collaboration?

Dataware is the emergence of a common group of technologies that solve data related problems across many business use cases. One of the most exciting new categories within this group is Data Collaboration.

Data Collaboration solves the costly, time-consuming, and ineffective integration processes born from silo-ing your data in a traditional app-centric environment. Instead of your data serving your applications, data collaboration refocuses and pivots to a model where your data is at the forefront and is being served by your apps (Image 1).

Harnessing this power, Cinchy connects unlimited data sources within a networked architecture, offering persistent delivery of real-time solutions, without complex integrations. And the more data you connect into your data network, the more powerful your processes can be.

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 is 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.

This process of making copies now consumes up to 50% of the resources on large IT projects, and it's the reason that delivery often takes months, sometimes years, and costs millions (Image 2).

How can this be fixed?

Data Collaboration: Using Dataware for accelerated solutions delivery

With data collaboration, you shift your approach from integration for data sharing, to access for data collaboration (Image 3).

For every app you build where you leverage data collaboration, you’re able to access the network to reuse information for future apps. Your IT team will find that previous projects have already connected many of the data sources they need to the network.

Cinchy's data collaboration platform does for application development what the power grid does for individual buildings. In the same way that buildings no longer need to generate their own power thanks to the power grid, with a data collaboration platform applications no longer need to manage, integrate, and protect their own data (Image 4).

Organizations can build data collaboration applications in half the time, while enabling effortless and copyless data sharing across applications. Using Cinchy is unique in that it eliminates the "integration tax" that today consumes half of most enterprise IT budgets -- that is to say, data collaboration makes integration obsolete (Image 5).

Now, instead of connecting apps to gain access to data through costly point-to-point integration, your apps serve your data by leveraging and connecting it all together via Cinchy. In this way, you can still gain the best usage out of your apps through zero-copy integration while avoiding the disadvantages of data silo-ing. You have both full access to and full control of your data (Image 6).

Not just connected, but autonomous.

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

Autonomous data exists independently of any application. It is self-controlled, self-protected, and self-describing. This creates a number of benefits compared to traditional app-dependent data, including the ability to simplify cross-application usage and reporting. And 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 thus the principle underpinning Collaborative Intelligence, the entire basis of Dataware and Cinchy.

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

Universal access controls, automated governance

One of the most significant advantages of dataware is the ease with which data owners can set universal data access controls at the cellular level, and automate data quality (Data Governance) with a “golden record” of data.

In effect, it is removing the need to maintain access controls within individual apps and centralizing these functions in an incredibly efficient way.

Compare this with designing and maintaining controls within thousands of apps and systems independently. It’s not only incredibly challenging and costly, but virtually impossible to maintain consistency (Image 7).

Game Changer: Network Effects for IT delivery

Dataware 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 more efficient to operationalize.

It's the same with dataware. The more you connect your data, the harder and better it works. It's the ability to have the platform take care of your whole data journey and transformation. You don't have to manage the changes of all your applications, regression testing, the QA you have to go through, etc.

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.

Now that you know how efficient and secure things can be there is no going back.

Let's build the connected future, together.

New Rich Text Editing Capabilities in Forms

Customize the appearance of your Form text with our new rich text editing capabilities. Enabling this on your text columns will give you access to exciting new formatting options previously unavailable in Forms such as:

• Bold, Italic, Underlined text

• Checklists

• Headers

• Hyperlinks

• etc.

For more information on how to make a visual impact with our new rich text editing capabilities, please review the documentation here.

Editable GUIDs

A GUID is a globally unique identifier, formatted as a 128-bit text string, that represents a unique ID. All Cinchy Tables and Columns have a GUID.

You now have the ability to display and edit table and column GUIDs within the Design Table screen.

This feature is particularly useful when deploying between Cinchy instances.

For example, in a model deployment, you must have matching GUIDs on your columns in order for them to properly load between environment A and environment B. There might be times when these GUIDs don’t automatically match, however, such as if you manually added a new column to environment B and also manually added it to environment A.

In this case, the two columns would have different GUIDs, and the model deployment would fail. With this new capability, however, you can match up conflicting GUIDs to properly load your model.

Polling Event Data Sync

Version 5.4 of the Cinchy platform introduces data polling, which uses the Cinchy Event Listener to continuously monitor and sync data entries from your SQLServer or DB2 server into your Cinchy table. This capability makes data polling a much easier, effective, and streamlined process and avoids implementing the complex orchestration logic that was previous necessary to capture frequently changing data.

You can read more about setting up Data Polling here.

BigInt Upgrade Utility

A mandatory database upgrade script was introduced in v5.2 that increased the number of possible Cinchy IDs that can be generated (read the releases note here). To streamline this process further, we have created a utility to deploy the changes. This should save you valuable time and resources when performing the upgrade, even on large databases.

For more information on the utility, please review the documentation here.

New Platform Default Timeout

For new environments (or if your setting was previously left blank), we have changed the Cinchy default session timeout from 30 minutes to 7 days. This will keep you logged in and working without interruptions. You can further change or revert this session timeout value in your appsettings.

In an IIS deployment, you can find the value in your CinchySSO > appsettings.json

“ConfigSettings”: {
	“AppSettings”: {
		"CinchyAccessTokenLifetime": "7.00:00:00",

In a Kubernetes deployment, you can find the value in your deployment.json file.

// The Cinchy session timeout
"cinchy_session_timeout" : "7.00:00:00",

Enhancements

• We have upgraded our application components to .NET 6.0 to ensure official Microsoft support for another 2 years. See the documentation here for more on .NET 6.

• We have added a silent refresh to the Connections experience to keep your session active while you're on the UI and to keep you working without interruptions.

• Real time data sync will now continue to retry if an "Out of Memory Exception" is thrown, avoiding unnecessary downtime.

• You now have the ability to choose between Debian or Alpine based Docker images when using a Kubernetes deployment of the Cinchy platform to be able to connect to a DB2 data source in Connections.

  • When either installing or upgrading your platform, you can use the following Docker image tags for the listener, worker, and connections:

    • Alpine: "5.x.x"

    • Debian: "5.x.x-debian"

• You now have the option to update the default passwords for Grafana and Opensearch in a Kubernetes deployment by configuring your deployment.json file. See here for instructions on updating Grafana and here for Opensearch.

• We have increased the average throughput for CDC subscriptions returning the Cinchy ID, so that it will now be able to process a greater number of events per second. Being able to reliably exceed 1000 events per second, based on the average use case, means that you can leverage the CDC capability for more demanding use cases.

• Prior to this release, the Files API could only handle files up to 100mb. We have now upped the maximum default file size to 1GB and have added a configurable property to allow you to set your own upload size should you wish.

  • In an IIS deployment, you can find the value in your Cinchy > appsettings.json

“ConfigSettings”: {
	“AppSettings”: {
		“MaxRequestBodySize”: 1073741824 // 1g

• In a Kubernetes deployment, you can find the value in your deployment.json file.

// this field defaulted at 1gb, dictates the max file upload size set in the web appsettings.json
"web_max_request_body_size" : 1073741824,

Bug Fixes

• We have fixed an error that occurred when attempting a data sync with conflicting target and source data types in link columns, where the error message would read: Value must be specified from the available options

• We have fixed an issue that was preventing new Connection jobs from starting when a previous job got stuck.

• We have fixed an issue where data syncs would fail if your sync key used a Target Column with a Link Column property that is different from the Primary Linked Column in the table definition.

• We have fixed a bug that was impacting write performance to tables on PostgreSQL with Data Change Notifications enabled.

• We have fixed a "cell entitlements failed" error on Forms that would occur if a Form column contained a single quote in the column name.

• We have fixed an issue on Forms where adding a [Created By] or [Modified By] field would return an error.

• The /healthcheck no longer redirects to the initialization screen during a Cinchy startup, allowing you to properly hit the endpoint.

Table of Contents

Another Move Toward Infinite Scalability

We have increased the number of possible Cinchy IDs that can be generated. This in turn allows the creation of more records within one table, so that you can create and manage larger data sets.

Previous Limit: 2,147,483,647 (2^31-1) Cinchy IDs per table

Updated Limit: 9,223,372,036,854,775,807 (2^63-1) Cinchy IDs per table

For backward compatibility with your database, you will need to manually run the below script against your TSQL or PGSQL databases. For instructions on how to run this upgrade, see the documentation here.

Connections Enhancements

• We have expanded our Connections capabilities to support binary file types as a data source. Review the documentation here for more information.

• We have improved the Connections experience by now making it optional to input a username or password when starting a batch sync job. This field can now be left blank if you want to run the job as the currently logged in user.

• We have added new optimizations and quicker processing of Kafka messages for real time data syncs in Connections.

• For added security, any logged password or sensitive parameters from the request details of a SOAP connector data sync is now redacted in the logs.

• Dead messages in the event listener are now written out to the execution errors table for easy collection and querying.

• The Connections experience now supports sourcing file based data sources from Azure Blob Storage and Amazon S3.

General Enhancements

• You now have the option to free up database space by using S3 compatible or Azure Blob Storage for file storage. This is configured in your deployment.json for Kubernetes installations and the appsettings.json in an IIS deployment.

  • If you are upgrading from an earlier v5 version, you can update your previous configuration to take advantage of this. For further instructions, review the documentation here.

• You are now able to run an erasure maintenance job on records that link to the Files table to delete the underlying referenced file.

• We have made improvements to the Files API to avoid cache build up and optimize the API.

• General security fixes and updates.

GraphQL (Beta)

• We have added anonymous API access to GraphQL, no token required.

• We have added write operations to our GraphQL beta, meaning that you can now insert and modify data.

Bug Fixes

• We have fixed a UI instability bug that resulted in the inability to resize view panes in the query designer and difficulty in selecting any cell in the first row of a table. This bug was affecting Chromium users (Google Chrome, Brave, Microsoft Edge, etc.) who had recently updated their internet browsers.

• We have fixed a bug that caused the “Created” column to incorrectly display as the last approved date of the column instead of the column created date.

• You can now add/remove a column from a table that has a columnar index without needing to remove said index entirely. We have also fixed a bug that prevented users from reapplying their columnar index to a table once it had been removed.

• We have fixed an issue where an “Unsupported Function Call” error was raised in certain situations when using the REPLACE function in conditional calculated columns in Connections.

• We have fixed a bug that caused unnecessary updates to the Users table when a user’s Language and Region was not set.

• We have fixed a bug that was causing some GUID calculated columns to appear as blank, such as in the Integrated Clients table. If you are experiencing this bug, a manual update on the affected rows, either through the UI or through an UPDATE query, will resolve it.

• We have fixed an issue where the '&' in links was sometimes showing up as 'amp&' in the table view instead. This fix will only appear for customers on Postgres/Microsoft SQL servers 2017 or higher.

• We have fixed an issue where certain Update statements on multi-select link columns were failing to properly update with the link values specified. This bug was affecting statement with long strings done via the API.

• We have fixed a bug that was causing the Event Listener to pick up and process messages from deleted configs from the LIstener Configs table.

• We have fixed a bug that was causing an InvalidOperationException when executing a POST request to a Saved Query API.

• We have fixed a bug that was throwing errors on reconciliation when Data Syncs compared Text Conditional Calculated Columns to Links (PGSQL).

• FOR JSON PATH now works as expected in Postgres deployments.

Table of Contents

New Capabilities

• Cinchy on Kubernetes: We have added the ability for deploying 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.

  • Fluentbit, Opensearch: Available to those who deploy on Kubernetes, Fluentbit 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.

  • Grafana and Prometheus: 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.

  • PostgreSQL: 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 is standards-compliant, reliable, highly programmable, and allows for concurrency. Utilizing this deployment makes Cinchy more affordable and scalable. We recommend Amazon Aurora for AWS users.

  • Kafka: 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: Redis is currently being used to facilitate a distributed lock using RedLock, which guarantees lock synchronizations across Cinchy instances. It is 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 Datasources 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 have 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 for Connections, the Worker, and the Event Listener.

CQL Updates

• We have added support for the INSERT INTO SELECT statement, which copies data from one table and inserts it into another table. Click here for more information 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. Click here for more information on OUTPUT.

• We have added support for the TRUNCATE TABLE statement, which removes all rows from a table, without logging the individual row deletions. Click here for more information on TRUNCATE TABLE. (Please note that we do not 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.

• Enablement 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.

Download the Release Notes

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 repo.

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 have 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 have 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 have 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 have added additional help text to event-based sources to the Source step of a connection. This help text will help better elucidate when a listener configuration is required as part of the sync.

• We have 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.

• To make troubleshooting easier, Connections Builders are now able to download batch sync logs directly from the Experience UI. This prevents the need to have to either wait for logs to appear in Opensearch or relying on an administrator/support to provide logs

• 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 have 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 have fixed a bug that was causing bearer token authenticated APIs to stop working on insecure HTTP Cinchy environments.

• We have 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 have 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 have fixed a bug where table views containing only a single linked column record would appear blank for users with “read-only” permissions.

Connections

• We have 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 have 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 have 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 have fixed a bug that was preventing Action Type column values of "Delete" from working with REST API target Delta syncs.

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

• We have 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. In order to implement this fix, you need to add the “messageKeyExpression” parameter to your listener config when using the Polling Event as a source. Please review the documentation here for further information.

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

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

• We have 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 have 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 have fixed an issue where updated file attachments on a form would fail to save.

CQL

• We have 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.

Overview

Becoming comfortable with the Cinchy terms and verbiage is an essential step to broaden your understanding of the platform and Data Collaboration as a whole. We have created this handy guide featuring to help you better understand the words and phrases you may see appear throughout this wiki space.

B

Batch Sync

A Batch Sync is one of the two types of Data Syncs that you can perform using Cinchy. by processing a group or a ‘batch’ of data all together rather than each piece of data individually. When the data sync is triggered it will compare the contents of the source to the target. The Cinchy Worker will decide if data needs to be added, deleted or updated. Batch sync can either be run as a one-time data load operation, or it can be scheduled to run periodically using an external Enterprise Scheduler

C

Cinchy Administrator

The is a user or user group with special within the Cinchy platform. An administrator can be either an or a

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

A Non-Builder Admin can:

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

• Modify data controls for tables

Cinchy Builder

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 ad hoc Cinchy Queries on the Cinchy data network

• Import/export packaged business capabilities (i.e. deployment packages)

• Build Cinchy Experiences

• Perform integration with Cinchy (e.g. Cinchy Command Line Interface [CLI] operations)

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

Cinchy CLI

CinchyDXD

CinchyDXD is a downloadable utility used to move Data Experiences (DX) from one environment to another. This includes any and all objects and components that have been built for, or are required in, support of the Data Experience.

Cinchy ID

Cinchy ID is a unique identifier assigned automatically to all records within a normal table. The Cinchy ID is associated with the record permanently and is never reassigned even if the record is deleted.

Cinchy Query Language (CQL)

Cinchy Query Language can be used in many ways, including but not limited to:

• ​Building queries through the query editor that can return, insert, delete, and otherwise manage your data.

• ​Creating, altering or dropping views for tables​

• ​Creating, altering or dropping indexes​

Cinchy Upgrade Utility

Cinchy End-User

• 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

Cinchy End-Users are able to:

• Create and save personal queries. Unlike traditional saved queries made by builders, personal saved queries cannot be shared and are not auto-exposed as APIs.

• Track version history for the full lifecycle of data

• Bookmark and manage data

• Access data through application experiences

Connections Experience

D

Dataware

Data Browser

Data Collaboration

Data Collaboration entails the collection, exchange and use of data from different origins within an organization. This interaction creates data products with data owners acting as experts for their specific data domains. The interaction of these various data set domains also results in dramatically informed insights that are solely driven by the interactions of the data itself.

Data Destination(s)

Data Source(s)

Data Synchronizations

E

Entitlements

Entitlements refers to the set of permissions that you are granted for any piece of data. Cinchy allows entitlements to be set at a very granular level, meaning you can give individual users or user groups access to things like:

• Viewing a data sync

• Running a job

• Viewing a specific table row or column

• Editing a specific table cell

• Etc.

Experiences

L

Listener Configuration

M

MDQE

• Healthchecks returning a critical status

• Upcoming Project Due Dates/Timelines

• Client Risk Ratings reaching a high threshold

• Tracking Ticket Urgency or Status markers

• Unfulfilled and Pending Tasks/Deliverables

• Etc.

In a nutshell, MDQE monitors for specific changes in data, and then pushes out notifications when that change occurs.

Meta Forms

It lives on top of the data collaboration platform, allowing builders to create forms with custom configurations and users to access this data outside of the tabular view that is native to Cinchy.

N

Network Map

Each node represents a table you have access to within Cinchy, and each edge is one link between two tables. The size of the table is determined by the number of links referencing that table. The timeline on the bottom allows you to check out your data network at a point in the past and look at the evolution of your network.

Q

Queries/Saved Queries

R

Real Time Sync

Cinchy Upgrade Utility

The Cinchy Upgrade Utility was previously introduced in v5.2 in order 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 in order 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 or 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 , 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

MongoDB

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

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

Enhancements

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

• We have 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 have 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 have 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.
• We have 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 have 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.
• We have 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 have 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 have 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.
• 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.
• We have 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 have 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 have 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 have 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.

• In order 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 have 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 have 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 have fixed a bug that was forcibly terminating authenticated sessions in Grafana, now allowing you to work without interruptions.

• We have 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 have fixed a bug that prevented record updates when multiple users attempted to update a row in too quick of a succession.

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

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

• We have 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 have fixed a bug that was preventing REST API real-time sync execution errors from being inserted into the execution errors table.

Table of Contents

New Connector

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

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.

Data Browser

• We have 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 have 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 have 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

Bug Fixes

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

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

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

Introduction

This section of Cinchy's documentation will guide 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: Deployment Planning Overview and Checklist

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

    • Kubernetes Deployment Installation

    • IIS Deployment Installation

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

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

• Via email: support@cinchy.com

• Via phone: 1-888-792-6051

• Through the support portal: Support Portal

1. How to Enable TLS 1.2

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

2. Find the following line:

add key="TlsVersion" value=""

3. Replace the above line with the following:

add key="TlsVersion" value="1.2"

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

5. Find the following line:

add key="TlsVersion" value=""

6. Replace the above line with the following:

add key="TlsVersion" value="1.2" 

7. You may need to restart the application pools in IIS for the changes to take effect.

1. Overview

Cinchy supports integration with any Identity Provider that issues SAML tokens (e.g. Active Directory Federation Services) for authenticating users.

It follows an SP Initiated SSO pattern where the SP will Redirect to the IdP and the IdP must submit the SAML Response via an HTTP Post to the SP Assertion Consumer Service.

Below is a diagram outlining the flow when a non-authenticated user attempt to access a Cinchy resource (Image 1).

2. Configure SAML Authentication - IIS Deployments

Cinchy must be registered with the Identity Provider. As part of that process you'll supply the Assertion Consumer Service URL, choose a client identifier for the Cinchy application, and generate a metadata XML file.

The Assertion Consumer Service URL for Cinchy is the base URL for the CinchySSO application followed by "{AcsURLModule}/Acs"

e.g. https:///<CinchySSO URL>/Saml2/Acs

e.g. https://myCinchyServer/Saml2/Acs

To enable SAML authentication within Cinchy, follow the below steps:

1. You can find the necessary metadata XML from the applicable identity provider you're using the login against. Place the metadata file in the deployment directory of the CinchySSO web application.

2. Update the values of the below app settings in the CinchySSO appsettings.json file.

• SAMLClientEntityId - The client identifier chosen when registering with the Identity Provider

• SAMLIDPEntityId - The entityID from the Identity Provider metadata XML

• SAMLMetadataXmlPath - The full path to the metadata XML file

• AcsURLModule - This parameter is needs to be configured as per your SAML ACS URL. For example, if your ACS URL looks like this "https:///<CinchySSO URL>/Saml2/Acs", then the value of this parameter should be "/Saml2"

Once SSO is enabled, the next time a user arrives at the Cinchy login screen they will see an additional button for "Single Sign-On".

3. Configure SAML Authentication - Kubernetes Deployments

1. Retrieve your metadata.xml file from the identity provider you're using the login against.

2. Navigate to your cinchy.kubernetes\environment_kustomizations_template\instance_template\idp\kustomization.yaml file.

3. Add your metadata.xml patch into your secrets where specified below as <<metadata.xml>>

- target:
    version: v1
    kind: Secret
    name: idp-secret-appsettings
  patch: |-
    - op: replace
      path: /data/appsettings.json
      value: <<idp_appsettings_json>>
    - op: add
      path: /data/metadata.xml
      value: <<metadata.xml>>

4. Navigate to your devops.automation > deployment.json in your Cinchy instance.

5. Add the following fields into the .json and update them below using the metadata.xml.

"sso": {
    "SAMLClientEntityId": "cinchy-dev", // Cinchy instance name
    "SAMLMetadataXmlPath": "/usr/share/appsettings/metadata.xml",
    // All below values get from metadata.xml and fill them here.
    "SAMLIDPEntityId": "",
    "SAMLSSOServiceURL": "",
    "AcsURLModule": "",
    "FirstNameExternalClaimName": "",
    "LastNameExternalClaimName": "",
    "EmailExternalClaimName": "",
    "MemberOfExternalClaimName": "",
    "metadata.xml": "BASE64_ENCODED_METADATA.XML"
}

6. Navigate to your kubernetes\environment_kustomizations_template\instance_template_encoded_vars\idp_appsettings_json.

7. Update the below code with your proper AppSettings and ExternalIdentityClaimSection details.

{
    "ConfigSettings": {
        "AppSettings": {
            "SAMLClientEntityId": "<<SAMLClientEntityId>>",
            "SAMLIDPEntityId": "<<SAMLIDPEntityId>>",
            "SAMLMetadataXmlPath": "<<SAMLMetadataXmlPath>>",
            "SAMLSSOServiceURL": "<<SAMLSSOServiceURL>>",
            "AcsURLModule": "<<AcsURLModule>>",
        },
        "ExternalIdentityClaimSection": {
            "FirstName": {
                "ExternalClaimName": "<<FirstNameExternalClaimName>>"
            },
            "LastName": {
                "ExternalClaimName": "<<LastNameExternalClaimName>>"
            },
            "Email": {
                "ExternalClaimName": "<<EmailExternalClaimName>>"
            },
            "MemberOf": {
                "ExternalClaimName": "<<MemberOfExternalClaimName>>"
            }
        }
    }
}

8. Run devops automation script which will populate the updated outputs into the cinchy.kubernetes repo.

9. Commit your changes and push to your source control system.

10. Navigate to your ArgoCD dashboard and refresh the idp-app to pick up your changes. It will also delete your currently running pods in order to pick up the latest secrets.

11. Once the pods are healthy, you can verify the changes by looking for the SSO Tab on your Cinchy login page.

4. User Management

Before a user is able to login through the SSO flow, the user must be set up in Cinchy with the appropriate authentication configuration.

Users in Cinchy are maintained within the Users table in the Cinchy domain. Each user in the system is configured with 1 of 3 Authentication Methods:

• Cinchy User Account - These are users that are created and managed directly in the Cinchy application. They log into Cinchy by entering their username and password on the login screen.

• Non Interactive - These accounts are intended for application use.

• Single Sign-On - These users authenticate through the SSO Identity Provider (configured using the steps above). They log into Cinchy by clicking the "Login with Single Sign-On" link on the login screen.

4.1 How to define a new SSO User

Create a new record within the Users table with the Authentication Method set to "Single Sign-On".

4.2 How to convert an existing user to SSO User

Change the Authentication Method of the existing user to "Single Sign-On".

4.3 Logging in with SSO

Once a user is configured for SSO, they can then click the "Login with Single Sign-On" link on the login page and that will then take them through the Identity Provider's authentication flow and bring them into Cinchy.

5. Automatic User Creation - IIS Deployments

Once SSO has been enabled on your instance of Cinchy, by default, any user that does not exist in the Cinchy Users table will not be able to login regardless if they are authenticated by the Identity Provider.

Enabling Automatic User Creation means that upon login, if the Identity Provider authorizes the user, an entry for this user will automatically be created in the Cinchy Users table if one does not already exist. This means that any SSO authenticated user is guaranteed to be able to access the platform.

In addition to creating a user record, if AD Groups are configured within Cinchy, then the authenticated user will automatically be added to any Cinchy mapped AD Groups where they are a member. See AD Group Integration for additional information on how to define AD Groups in Cinchy.

See below for details on how to enable Automatic User Creation.

5.1 Prerequisites for Automatic User Creation

The Identity Provider configuration must include the following claims in addition to the base configuration in the SAML token response:

• First Name

• Last Name

• Email

In order to enable automatic group assignment for newly created users (which is applicable if you plan on using AD Groups), then you must also include an attribute that captures the groups that this user is a member of (e.g. memberOf field in AD)

5.2 Configuration Setup

Enabling automatic user creation requires the following changes. For IIS Deployments this will be done to the appsettings.json file in the CinchySSO web application.

1. Add ExternalClaimName attribute values under "ExternalIdentityClaimSection" in appsettings.json file. Do not add the value for "MemberOf" if you don't want to enable automatic group assignment .

2. The ExternalClaimName value must be updated to create a mapping between the attribute name in the SAML response and the required field. (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname is the name in the SAML response for the FirstName field)

"ExternalIdentityClaimSection": {
			"FirstName": {
				"ExternalClaimName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
			},
			"LastName": {
				"ExternalClaimName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
			},
			"Email": {
				"ExternalClaimName": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
			},
			"MemberOf": {
				"ExternalClaimName": "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
			}
		}

6. Further Reading

• Configuring ADFS

• AD Group Integration

Overview

Beginning in Cinchy v5.6, 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 AWS IAM role authentication, please review the procedure below.

1. AWS IAM Role Authentication

1. To check that you have an OpenID Connect set up with the cluster (the default for deployments made using the Cinchy automation process), run the below command within a terminal:

aws eks describe-cluster --name <CLUSTER_NAME> --query "cluster.identity.oidc.issuer"

1. The output should appear like the below. Make sure to note this down for later use.

https://oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>

1. Log in to your AWS account and create an IAM Role policy through the AWS UI. Ensure that it has S3 access.

2. Run the below command in a terminal to create a service account with the role created in step 3. If your cluster has a special character like an underscore, skip to section 1.1.

eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name "my-role" --attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve

1.1 Cluster Names with Special Characters

If your cluster name has a special character, like an underscore, you will need to create and apply the yaml. Follow section 1 up until step 4, and then follow the below procedure.

1. In an editor like Visual Code or similar, create a new file titled "my-service-account.yaml" in your working directory. It should contain the below content.

/apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

1. In a terminal, run the below command:

kubectl apply -f my-service-account.yaml -n <namespace>

1. In an editor like Visual Code or similar, create a new file titled "trust-relationship.json" in your working directory. It should contain the below content.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::$account_id:oidc-provider/$oidc_provider"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "$oidc_provider:aud": "sts.amazonaws.com",
          "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
        }
      }
    }
  ]
}

For example,

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::204393242335:oidc-provider/oidc.eks.ca-central-1.amazonaws.com/id/8A024CF24ADD3925BEFA224C4BDD005B"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.ca-central-1.amazonaws.com/id/8A024CF24ADD3925BEFA224C4BDD005B:aud": "sts.amazonaws.com",
                    "oidc.eks.ca-central-1.amazonaws.com/id/8A024CF24ADD3925BEFA224C4BDD005B:sub": "system:serviceaccount:devops-aurora-1:connections-serviceaccount-s3"
                }
            }
        }
    ]
}

1. Execute the following command to create the role, referencing the above .json file:

aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"

For example,

aws iam create-role --role-name connections-role-test --assume-role-policy-document file://trust-relationship.json --description "testing sa role for pod"

1. Execute the following command to attach the IAM policy to your role:

aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws:iam::$account_id:policy/my-policy

For example,

aws iam attach-role-policy --role-name connections-role-test --policy-arn=arn:aws:iam::aws:policy/AmazonS3FullAccess

1. Execute the following command to annotate your service account with the Amazon Resource Name (ARN) of the IAM role that you want the service account to assume:

kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role

For example,

kubectl annotate serviceaccount -n devops-aurora-1 connections-serviceaccount-s3 eks.amazonaws.com/role-arn=arn:aws:iam::204393242335:role/connections-role-test

1. Confirm that the role and service account are configured correctly by verifying the ouput of the following commands:

aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
aws iam get-role --role-name connections-role-test --query Role.AssumeRolePolicyDocument

1.2 Authorizing for Data Syncs

To ensure that the Connections pod's role has the correct permissions, the role specified by the user in AWS must have its Trusted Relationships configured as such:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"AWS": "<role-arn-created-above>",
				"Service": "s3.amazonaws.com"
			},
			"Action": "sts:AssumeRole"
		}
	]
}

1.3 Confirmation

To confirm that the Connections app is using the service account:

1. Navigate to the cinchy.kubernetes repo > connections/kustomization.yaml file

2. Execute the following:

- op: replace
      path: /spec/template/spec/serviceAccountName
      value: connections-serviceaccount-s3

1. From a terminal, run the below command:

kubectl describe deployment connections-app -n <namespace>

1. The output should look like the following:

Table of Contents

1. 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, 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.

• Grafana, Opensearch, Opensearch Dashboard: Working together, these three applications provide a visual logging dashboard for all of 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 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.

• 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 prior to Cinchy v5. Internet Information Services (IIS) for Windows Server is a flexible, secure and manageable Web server for hosting anything on the Web.

We recommend using Kubernetes to deploy Cinchy v5, because of the robust features that you can leverage, such as improved logging and metrics. Using Kubernetes allows for a greater ability to scale your Cinchy instances as well as the ability to lower your costs by using PostgreSQL.

2. Choosing a Database

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

The following list outlines which databases we support for Kubernetes Deployments.

For IIS Deployments please review the architecture requirements here.

2.1 Microsoft SQL Server

2.1.1 MS SQL Server

• Microsoft SQL Server is a relational database management system. As a database server, it is 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

2.1.2 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 is 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

2.1.3 Azure Managed SQL Instance

• SQL Managed Instance is a managed, always up-to-date SQL instance in the cloud 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

2.2 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 web service that makes it easier to set up, operate, and scale a relational database in the cloud.

• Resource Limits

2.3 PostgreSQL

2.3.1 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.

2.3.2 AWS RDS for PostgreSQL

• Amazon RDS makes it easy to set up, operate, and scale PostgreSQL deployments in the cloud. 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

2.3.3 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

3. Sizing Considerations and Requirements

Prior to deploying Cinchy version 5, you need to define your sizing requirements.

3.1 Sizing

3.1.1 Kubernetes Sizing

Cluster sizing recommendations vary and are dependant on a myriad of deployment factors. We have provided the following very 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

3.1.2 IIS Sizing

For sizing recommendations and prerequisites concerning an IIS deployment, please review the documentation found here.

3.2 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.

3.3 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

There is no sizing definitions, as S3 provides unlimited scalability and it charges only for what you use/how much you store on it.

• How to set up an Amazon S3 bucket

• How to set up Azure Blob Storage

Table of Contents

1. Component Diagram

The below diagram shows a high level overview of Cinchy's Infrastructure components when deploying on IIS.

2. Component Overview

Table of Contents

Can I get a record count from a delimited file before running the CLI?

You can use PowerShell to count the lines in a delimited file and based on the result decide if you will run the CLI.

$row_count=(get-content sample_150k.csv).length
write-host $row_count

If ($row_count -lt 50000)
{
     exit
}
else {
      Write-host "run CLI"
}

There is currently no way for you to find out how many records will be inserted/updated/deleted if you run a CLI without performing the sync.

Can I restore my deleted data?

If the record is still in the table, but has been overwritten by mistake, access your Collaboration Log for the row, and restore back to the correct version.

If your row has been deleted by mistake, access your Recycling Bin, locate the row and restore it.

The only way to truly delete data on the platform is through Data Erasure and Data Compression.

Can I send multiple comma-delimited values to a query parameter? [i.e. 234,233,365 to be used in WHERE [Id] IN (@param)]

For example: 4,10,15 to be used in WHERE [Id] IN (@param)

This can be done by using parameters in {}, such as {0},{1},...

These will be replaced with the exact text when running the query.

For example: ​ SELECT * FROM [HR].[Employees] WHERE [Deleted] IS NULL AND [Employee ID] IN ({0}) (Image 1).

Cinchy dates are being saved as a 1900-01-01 when updating using a variable

When updating a date field using a variable, and no value is entered for that variable, the date field will be 1900-01-01. To avoid this, use a case statement to replace the empty string with NULL, as shown in the following example:

UPDATE E
SET E.[Date Hired]=CASE WHEN @dhired<>'' THEN @dhired ELSE NULL END
FROM [HR].[Employees] E
WHERE E.[Deleted] IS NULL AND [Employee ID]=@empid

Does a row filter restrict access for a Cinchy administrator?

Currently Cinchy Administrators have access to view/edit/approve all data in the platform. There is no way currently to restrict access for Cinchy administrators.

A workaround is to create a separate "administrators" group which has edit access to all Cinchy system tables, and just leave the "admin" user account or superadmins as "Cinchy administrators."

How can I automatically check if a CLI data sync was successful or failed?

You can check if a data sync was successful by its exit code. Below is sample code in Powershell to check for the exit code and what they mean.

Invoke-Expression $CLICommand
switch ($LASTEXITCODE) {
  0 { Write-Host "Completed without errors" }
  1 { Write-Host "Execution failed" }
  2 { Write-Host "Completed with validation errors" }
}

From the command prompt the following will also return the error code:

echo %ErrorLevel%

How can I check for platform errors?

In Version 4:

First check <base URL>/elmah, which stores web-related induced errors.

Then check the logs, which can be accessed from <base URL>/admin/index.

Cinchy logs will contain all exceptions thrown by the Cinchy Web application. This includes failed queries, stack overflows and much more.

CinchySSO logs will contain IDP errors.

In Version 5: Errors and Logs can be found through the Opensearch Dashboard.

How can I enter a new line into a field in Manage Data?

You can add line breaks in a cell on the UI, the same way as in Excel, by typing Alt+Enter. If you use the expanded row heights option, or manually expand the row, it will show the line breaks.

How can I prevent wrong data loading in from external applications?

The best way to load data from external sources into Cinchy, is by using a data sync.

You can do the following to preview your changes:

• Create staging tables to validate the data first.

• Use formatting rules in Cinchy, to highlight data that is not valid.

• Configure a CLI using a Cinchy Query source to move the data from the staging tables to the permanent tables.

How can I see who has modified my data?

Right click on the row you want additional information and select the Collaboration Log.

You can also add the "Modified By" and "Modified" columns into the current view/to your query if you want to see it for multiple rows at once.

How do I create a Cinchy user with a set password?

One Time setup:

1. Open the Users table

2. For the password of this user, copy the admin user's password and paste it into the Password field of "defaultuser".

3. Set the Password Expiration Timestamp to today

4. In an Incognito browser, navigate to the Cinchy website

5. Sign in as defaultuser with the admin user password

6. Cinchy will ask you to change the password for defaultuser, change it to a default password you will give out every time you create an account.

7. In the original session window, refresh the Users table and remove the Password Expiration Timestamp for defaultuser.

Each time, for new users:

1. Open the Users table

2. Create the new user, for example "sandip"

3. For the password of this user, copy the "defaultuser" password and paste it into the Password field of "sandip".

4. Set the Password Expiration Timestamp to today

5. Give the user their username and friendly password created in step 7 above. They will be asked to change their password on first sign in.

How do I get the change history through CQL?

You write the query for the records for which you want the change history, including system columns like [Version], [Created], ... and the columns for which you like to see the changes.

You can add an ORDER BY [Version] (either ASC or DESC)

Then you change the query return type to "Query Results (Including Version History )"

The following query will show when the Cinchy instances were upgraded.

SELECT [Version], [Modified], [Model Version]
FROM [Cinchy].[Models]
WHERE [Deleted] IS NULL AND [Name]='Cinchy'
ORDER BY [Version] DESC

How do I insert, update, and delete links in a multi-select field using CQL?

Removing and updating a multi-select a link, is the same as setting the link field. The field needs to be updated with the list of values.

The value is a concatenated string of '[Cinchy Id],[Version],[Cinchy Id],[Version],[Cinchy Id],[Version]' from the lookup values

UPDATE T
SET T.[Multi-Link Field Name] = '1,1,2,1,3,1'
FROM [Domain].[Table Name] T
WHERE T.[Deleted] IS NULL AND ...

In this example it would set [Multi-Link Field Name] to values with [Cinchy Id] 1, 2, and 3. The version after each Cinchy Id should be 1.

How do I know which version of Cinchy I am running?

Navigate to <baseURL>/healthcheck

(ex. if your current URL is https://cinchy.mycompany.com/Tables/123?viewId=0 then you would navigate to https://cinchy.mycompany.com/healthcheck)

The response looks this:

{ 
  "component": "Cinchy", 
  "version": "4.14.0.0", 
  "ipAddress": [ 
      "172.31.14.171", 
      "172.19.64.1" 
  ], 
  "systemTime": "2020-06-18T19:43:54.1692859Z", 
  "status": "Green", 
  "healthChecks": [ 
    { 
      "name": "Database Connectivity", 
      "description": "Validates that the application can connect to the database",
      "status": "Green" 
   } 
 ] 
}

In this case your Cinchy version is 4.14.0.0

If you would like to use the health check link for monitoring of the Cinchy application you can add "return503OnFailure=true" to the URL

How do I map a parameter's value to one of my target columns?

Use the model loader to load it back in the system (/apps/modelloader).

You create a calculated column in the source and give it the value of the parameter.

For each table, export and import the data via the UI.

<Parameters>
    <Parameter name="snapshotDate" />
</Parameters>
...
<Schema>
...
    <CalculatedColumn name="Snapshot Date" formula="@snapshotDate" dataType="Date" />
<Schema>

Then map the calculated source column to the target. The order of the columns in the source is important. If your source is a file, put the calculated columns at the end in the source, after all the actual columns in the file.

How do I parse a pipe delimited file using the CLI?

Set the delimiter to "|".

<DelimitedDataSource delimiter="|" textQualifier="&quot;"  headerRowsToIgnore="2" path="@filePath" encoding="UTF8">

How do I remove the leading 0 from an incoming field using the CLI?

This can be done by using Transformations in the sync configuration of a column. Here is an example:

<Column name="Value 2" dataType="Text" >
      <Transformations>
            <StringReplacement pattern="^0*" replacement="" />
      </Transformations>
</Column>

The pattern contains a regular expression:

^ - anchor for the beginning of the string

0 - the string to replace

* - quantifier to be applied to 0 or more occurrences

How do I clone a Cinchy table?

1. Export the Model to XML from the Design Table info tab

2. Open the exported model in an editor and change the name of the model

3. Change the name of the table

4. remove the guids from the table in the model and save the file

5. Use the modelloader at <cinchy base URL>/apps/modelloader to upload the modified model

6. Export the data from the Manage Data screen of the initial table and import it in the new table

How do I clone a domain?

If you just have a group of tables, see the instructions below. If you have tables, queries, you want to port the permissions, etc. you can use this: Data Experience Deployment - Cinchy Platform Documentation

Table only instructions:

1. Create a dummy Data Experience and add all your tables from your domain to it (Image 2).

2. Hit the following endpoint with the GUID in your row:

<CinchyURL>/api/createdxversion?guid=<GUID>

I am unable to use COALESCE with a link column in a calculated column

If [Person 1] and [Person 2] are Link columns and [Member] is a Text column, a calculated column with the following expression will fail to save:

COALESCE([Person 1],[Person 2],[Member])

Please cast the link columns to VARCHAR:

COALESCE(CAST([Person 1] AS VARCHAR(50)),CAST([Person 2] AS VARCHAR(50)),[Member])

I cannot disable Change Approvals

This is caused by records in Draft status. To retrieve these records, run a query with return type Query Results (Including Draft Data).

SELECT T.*
FROM [Your Domain].[Your Table] T
WHERE T.[Approval State] <> 'Approved'

After approving these records, you will be able to disable change approval.

I cannot find the [Cinchy].[Table Access Control] table

The [Cinchy].[Table Access Control] table does not show in the Market Place, but you can query for the data in the table.

SELECT *
FROM [Cinchy].[Table Access Control]
WHERE [Deleted] IS NULL AND [Table]='HR.Employees'

I cannot find the column I want to link to even though the column is present in the table

In this example it would set [Multi-Link Field Name] to values with [Cinchy Id] 1, 2, and 3. The version after each Cinchy Id should be 1."

Columns do not "Allow Linking" by default. Check the properties of the column in the original table and make sure that in “Show Advanced” the “Allow Linking” checkmark box is selected. If you do not have Design Table access to that table, you will need to ask someone who does to do it.

I have access to a table but I cannot see any rows

There are a couple reasons why you may not be able to see any rows:

• View Filter

• Data access controls

• Error with the View or Table

View Filter

Check the All Data view and see if there is data there, if that is the case but a particular view has no rows, there could be a filter on the view. For example, if there is a "Due Soon" or "My Actions" view, it could just be that there are no records assigned to you that require actioning.

Data Access Controls

Access controls set on the table could cause you to have access to 0 records. Since you are able to set row level filters in Cinchy, it may be the case that the permissions of the table has not changed, but the data has changed such that you no longer have permission or vice versa.

Error

There may be an error on the view. If the bottom of the page does not show 0 records then there may be an error on the page (Image 3).

Is it possible to correct/replace a table or column's GUID?

It can be done. It is very unlikely that the GUID you want to change to is already allocated, but you should still check. Filter the [Cinchy].[Table Columns] for the new GUID. You should not find it. Then replace it in two places:

• the json field in [Cinchy].[Tables] - replace it in the column definition

• the GUID field in [Cinchy].[Table Columns]

To replace the table GUID, replace it in the json in [Cinchy].[Tables] and in the GUID field in [Cinchy].[Tables].

When you are done, restart the Cinchy UI. ​

My Insert/Update statement is making multiple changes instead of just one

A query like the following will cause multiple inserts instead of one if your result type is set to Query Results instead of # of Rows Affected.

INSERT INTO [Customer].[Tickets] ( [Ticket Id], [Subject] )
VALUES ( 1900, 'This is a Test' );
SELECT [Cinchy Id],
       [Ticket Id],
       [Subject]
FROM [Customer].[Tickets]
WHERE [Deleted] IS NULL

The same applies to UPDATE statements.

If you need to perform inserts and updates in a query and want to return data at the end, another option is to use the "Single value (First Column of First Row)" return type, which will only be able to return a single value.

My query parameter is not working

When I pass a value to the following query, the result is empty.

DECLARE @nbdays AS INT;
SELECT @nbdays;

The query works without the DECLARE statement. When the DECLARE statement is present, the input variable is ignored, and needs to be SET. In order to still get the variable from the input, a second variable is needed.

DECLARE @nbdays AS INT;
SET @nbdays = @inputDays;
SELECT @nbdays;

Null values are not updating correctly in Salesforce using the data sync

When performing a data sync with a Salesforce target, you need to replace nulls with '#N/A' in the source. You can use ISNULL([Column],'#N/A') in the source query. The following is a link to the Salesforce documentation related to this topic:

https://help.salesforce.com/articleView?id=000328822&language=en_US&type=1&mode=1

Passing Parameters to a query called With Exec

Declare and set the parameters before invoking the query:

DECLARE @dep AS VARCHAR ( 500 );
SET @dep = 'Accounting';
EXEC [HR].[Employees and Departments]

[HR].[Employees and Departments] is:

SELECT [Employee ID],
       [Full Name],
       [Date Hired],
       [Department]
FROM [HR].[Employees]
WHERE [Deleted] IS NULL
      AND [Department] = @dep

Some of the columns have been rearranged under the default "All Data" view

The default All Data view displays the columns in the same order as in Design Table. But you can create a view and change the columns displayed and their order.

The multi-select option on the Link Column is disabled

Once link column is added to a table and saved, the multi-select checkbox should be disabled. If you need to change the option, you need to rename the column and create a new link column with the correct option.

What permissions are needed for a user to be able to create and edit views?

The user needs to have "Design Table" permissions granted for the table where he/she will create or edit views and also needs to have the "Can Design Tables" checked in the [Cinchy].[Users] table.

1. Generate the self-signed certificate by executing the following commands in any folder:

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

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

3. Add the following to the yaml file:

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

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

5. 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

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

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

7. 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

8. Once the changes are deployed, verify the root CA cert is available on the pod under /etc/ssl/certs with below command, inputing your own POD_NAME and NAMESPACE where noted:

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

1. Overview

In Cinchy v5.2, we implemented the ability to free up database space by using S3 compatible or Azure Blob Storage for file storage. This configuration is set in the deployment.json of a Kubernetes installation, or the appsettings.json of an IIS installation.

2. Kubernetes File Storage

1. If you are using a Kubernetes deployment, you will change your file storage config in the deployment.json.

2. Navigate to the object storage section, where you will see either S3 or Azure Blob storage, depending on your deployment structure.

Azure Example

        "object_storage": {
          // Cinchy requires a new Azure Blob Storage container for it's file storage. Select a unique name, the template convention follows <organization>cinchy<cluster name>
          // Storage Account Names can only consist of lowercase letters and numbers, and must be between 3 and 24 characters long
          "storage_account_name": "<organization>cinchynonprod",
          // Two storage containers are created, one for the Connections component and one for the Platform. The default naming convention is <cluster name>-<component>
          "connections_storage_container_name": "nonprod-connections",
          "platform_storage_container_name": "nonprod-platform",
          "connections_storage_type": "AzureBlobStorage",
          // The connection string to the Azure Blob Storage account, it can be retrieved by executing the following command after the terraform apply has completed
          // In the below command the <storage_account_name> and <deployment_resource_group> must be replaced with the values for those properties within this file
          // az storage account show-connection-string --name <storage_account_name> --resource-group <deployment_resource_group>
          "azure_blob_storage_conn_str": ""
        },

AWS Example

        "object_storage": {
          // Cinchy requires a new S3 bucket for it's file storage. Select a unique name, the template convention follows <organization>-<cluster name>
          "cinchy_s3_bucket": "<organization>-cinchy-nonprod",
          // During the S3 bucket creation, a tag named "Environment" is added to the resource and populated with the following value
          "cinchy_s3_environment_tag": "cinchy-nonprod",
          "connections_storage_type": "S3",
          // IAM user credentials (access key and secret) for access to this bucket. Ensure that the usre has the necessary privileges defined in IAM
          "connections_s3_access_key": "",
          "connections_s3_secret_access_key": "",
          // Optional - only set this value if you are using a third party S3 compatible service
          "connections_s3_service_url": ""
        },

3. To utilize Blob Storage or S3, update each line with your own parameters.

4. To utilize Local storage, leave each line blank with the exception of the Connections_Storage_Type, which should be set to Local:

          "connections_storage_type": "Local",

5. Run the deployment script by using the following command in the root directory of your devops.automations repo:

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

6. Commit and push your changes.

3. IIS File Storage

1. If you are using an IIS deployment, you will change your file storage config in the Cinchy Web appsettings file.

2. Locate the StorageType section of the file and set it to either "Local", "AzureBlobStorage" or "S3".

  "AppSettings": {
   ...
    "StorageType": ""      // Set this to "Local" to store files within Cinchy's database. Set this to "AzureBlobStorage" to store files within Azure Blob Storage. Set this to "S3" to store files within S3.
  },

3. If you selected "AzureBlobStorage", fill out the following lines in the same file:

  "AzureBlobStorageSettings": {
    "ConnectionString": "",    // ConnectionString used to connected to the Azure Blob Storage
    "Container": "",       // The container for Cinchy's file storage
    "BasePath": ""         // The base directory path of where to store files within the container (eg. cinchy/files)
  },

4. If your selected "S3", fill out the following lines in the same file:

  "S3Settings": {
    "AccessKey": "",       // Access Key for the IAM user. Ensure that the user has the necessary privileges defined in IAM
    "SecretAccessKey": "", // Secret for the IAM user. Ensure that the user has the necessary privileges defined in IAM
    "Region": "",          // Region of where the S3 bucket is located in
    "Bucket": "",          // S3 bucket for Cinchy's file storage
    "BasePath": "",            // The base directory path of where to store files within the bucket (eg. cinchy/files)
    "ServiceURL": ""       // (Optional) - only set this value if you are using a third party S3 compatible service
  }

Contacting 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: support@cinchy.com

• Via phone: 1-888-792-6051

• Through the support portal: Support Portal

1. Overview

There are various things to consider before deploying Cinchy v5.

The pages in this Deployment Planning section will guide you through the considerations you should think about and the prerequisites that you should implement before deploying version 5 of the Cinchy platform.

The pages in this section include:

• Deployment Architecture Overview: This page explores your two high-level options for deploying Cinchy, on Kubernetes or on VM, and why we recommend a Kubernetes deployment. It also walks you through the important decision of selecting a database to run your deployment on, as well as some sizing considerations.

  • Kubernetes Deployment Architecture: This page provides Infrastructure (for both Azure and AWS), Cluster, and Platform component overviews for Kubernetes deployments. It also guides you through considerations concerning your cluster configuration.

  • IIS Deployment Architecture: This page provides Infrastructure and Platform component overviews for IIS (VM) deployments.

• Deployment Prerequisites: This page details important prerequisites for deploying Cinchy v5.

2. Deployment Planning Checklist

We have provided the following checklist for you to use when planning for your Cinchy v5 deployment. Each item is linked to the appropriate documentation page to provide more insight and clarity.

• Will you run on Kubernetes or a VM?

WIndows IIS vs Kubernetes

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.

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

We recommend using Kubernetes to deploy Cinchy v5, because of the robust features that you can leverage, such as improved logging and metrics. Using Kubernetes allows for a greater ability to scale your Cinchy instances as well as the ability to lower your costs by using PostgreSQL.

The main differences between a Kubernetes based deployment and an IIS deployment are:

If you will be running on Kubernetes, please review the following checklist:

• Which database will you use?

• Define your sizing.

• Define 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?

  • Will you be using Cinchy's recommended cluster components or your own?

• Define your object storage requirements.

  • Create an S3 compatible bucket.

• Create your SSL Certs (With the option to use Self-Signed).

• Define your Secrets Management, if desired.

• Define whether you will use Cinchy's Docker Images or your own.

  • If using Cinchy’s, pull the images.

• Access the deployment repositories and copy them into your own repo (Github or similar).

If you will be running on IIS, please review the following checklist:

• Ensure that you have an instance of SQL Server 2017+

• Ensure that you have a Windows Server 2012+ machine with IIS 7.5+ installed

• Install .net core Hosting bundle Version 6.0

  • Specifically, install: ASP.NET Core/.NET Core Runtime & Hosting Bundle

• Ensure that you review the minimum web server hardware recommendations

• Ensure that you review the minimum database server hardware recommendations

• Define your application storage requirements.

• Ensure you have access to the release binary.

1. 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.

1.1 Configuring 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 repo:

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

3. Commit and push your changes.

1.2 Apply your Configurations

If your environment is not 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 does not work, re-sync.

Table of Contents

1. Introduction

This page details the instructions for deployment of Cinchy v5 on Kubernetes. We recommend, and have documented below, that this is done via Terraform and ArgoCD. This setup involves a utility to centralize and streamline your configurations.

The Terraform scripts and instructions provided enable deployment on Azure and AWS cloud environments.

2. Deployment Prerequisites

The following lists are required prerequisites for installing Cinchy v5 on Kubernetes.

Note that some prerequisites will depend on whether you are deploying on Azure or on AWS.

2.1 All Platforms

These prerequisites apply whether you are installing on Azure or on AWS.

• The following four Git repositories must be created. Any source control platform supporting Git may be used, e.g. Gitlab, Azure DevOps, Github

  • cinchy.terraform: This repo contains all Terraform configurations.

  • cinchy.argocd: This repo contains all ArgoCD configurations.

  • cinchy.kubernetes: This repo contains cluster and application component deployment manifests.

  • cinchy.devops.automations: This repo contains the single configuration file and binary utility that maintains the contents of the above three repositories.

• Download the artifacts for the four Git repositories. See here for information on accessing these. Check the contents of each of the directories into the respective repository.

• You must have a service account with read/write permissions to the git repos created above.

• The following tools should be installed on the machine where the deployment will run:

  • Terraform

    • For an introductory guide on Terraform + AWS, see here

    • For an introductory guide on Terraform + Azure, see here

  • Kubectl (v1.23.0+)

  • .NET Core 3.1.x

  • Bash (Git Bash may be used on Windows)

• If you are using Cinchy's docker images, pull them.

• You will need a single domain for accessing ArgoCD, Grafana, Opensearch Dashboard, and any deployed Cinchy instances. There are two routing options for accessing these applications - path based or subdomains. See below for an example with multiple cinchy instances:

• You will need an SSL certificate for the cluster. This should be a wildcard certificate if you will use subdomain based routing. You can also use Self-Signed SSL.

2.2 Azure Deployment

The following prerequisites are required if you are deployment Cinchy v5 on Azure.

• Terraform Backend Requirements:

  • A resource group that will contain the Azure Blob Storage with the terraform state.

  • A storage account and container (Azure Blob Storage) for persisting terraform state.

• The Azure CLI should be installed on the machine where the deployment will be run. It must be set to the correct profile/login

• The deployment template has the option of either leveraging an existing resource group or creating a new one:

  • If an existing resource group is preferred, the prerequisite requires the following be provisioned in advance of the deployment:

    • The resource group.

    • A VNet within the resource group.

    • A single subnet. It's important that the address range be sufficient for all executing processes within the cluster, e.g. a CIDR ending with /22 to provide a range of 1024 IPs.

  • If a new resource group is preferred, all resources will be automatically provisioned.

• The quota limit of the Total Regional vCPUs and the Standard DSv3 Family vCPUs (or equivalent) must provide sufficient availability for the required number of vCPUs (minimum of 24).

• An AAD user account to connect to Azure, which has the necessary privileges to create resources in any existing resource groups and the ability to create a resource group (if required).

2.3 AWS Deployment

The following prerequisites are required if you are deployment Cinchy v5 on AWS.

• Terraform Backend Requirements:

  • An S3 bucket that will contain the terraform state.

• The AWS CLI should be installed on the machine where the deployment will be run. It must be set to the correct profile/login

• The template has the option of either leveraging an existing VPC or creating a new one:

  • If an existing VPC is preferred, the prerequisite requires the following be provisioned in advance of the deployment:

    • The VPC. It's important that the address range be sufficient for all executing processes within the cluster, e.g. a CIDR ending with /21 to provide a range of 2048 IPs.

    • 3 Subnets (one per AZ). It's important that the address range be sufficient for all executing processes within the cluster, e.g. a CIDR ending with /23 to provide a range of 512 IPs.

    • If the subnets are private, a NAT Gateway is required to enable node group registration with the EKS cluster.

  • If a new VPC is preferred, all resources will be automatically provisioned.

• The limit of the Running On-Demand All Standard vCPUs must provide sufficient availability for the required number of vCPUs (minimum of 24).

• An IAM user account to connect to AWS which has the necessary privileges to create resources in any existing VPC and the ability to create a VPC (if required).

• The SSL certificate must be imported into AWS Certificate Manager, or a new certificate can be requested via AWS Certificate Manager.

  • If your are importing it, you will need the PEM-encoded certificate body and private key. You can find this, you can get the PEM file from your chosen domain provider (GoDaddy, Google, etc.) Read more on this here.

3. Initial Configuration

The following steps detail the instructions for setting up the initial configurations.

3.1 Configure the Deployment.json

1. Navigate to your cinchy.devops.automations repository where you will see an aws.json and azure.json.

2. Depending on the cloud platform that you are deploying to, select the appropriate file and copy it into a new file named deployment.json (or <cluster name>.json) within the same directory.

3. This file will contain the configuration for the infrastructure resources and the Cinchy instances to deploy. Each property within the configuration file has comments in-line describing its purpose along with instructions on how to populate it.

4. Follow the guidance within the file to configure the properties.

5. Commit and push your changes.

3.2 Execute cinchy.devops.automations

This utility updates the configurations in the cinchy.terraform, cinchy.argocd, and cinchy.kubernetes repositories.

1. From a shell/terminal, navigate to the cinchy.devops.automations directory location and execute the following command:

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

2. If the file created in "Configuring the Deployment.json" step 2 has a name other than "deployment.json", the reference in the command will will need to be replaced with the correct name of the file.

3. The console output should terminate with a "Completed successfully".

4. Terraform Deployment

The following steps detail how to deploy Terraform.

Cinchy.terraform Repo Structure - AWS

If deploying on AWS: Within the Terraform > AWS directory, a new folder named eks_cluster is created. Nested within that is a subdirectory with the same name as the newly created cluster.

To perform terraform operations, the cluster directory must be the working directory during execution. This applies to everything within step 4 of this guide.

Cinchy.terraform Repo Structure - Azure

If deploying on Azure: Within the Terraform > Azure directory, a new folder named aks_cluster is created. Nested within that is a subdirectory with the same name as the newly created cluster.

To perform terraform operations, the cluster directory must be the working directory during execution.

4.1 Cloud Provider Authentication

1. Launch a shell/terminal with the working directory set to the cluster directory within the cinchy.terraform repo.

2. If you are using AWS, run the following commands to authenticate the session:

export AWS_DEFAULT_REGION=REGION
export AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY_ID
export AWS_SECRET_ACCESS_KEY=YOUR_ACCESS_KEY

3. If using Azure, run the following command and follow the on screen instructions to authenticate the session:

az login

4.2 Deploy the Infrastructure

1. Execute the following command to create the cluster:

bash create.sh

2. Type yes when prompted to apply the terraform changes.

The resource creation process can take approx. 15-20 minutes. At the end of the execution there will be a section with the following header

======= Output Variables =======

If deploying on AWS, this section will contain 2 values: Aurora RDS Server Host and Aurora RDS Password

If deploying on Azure, this section will contain a single value: Azure SQL Database Password

These variable values are required to update the connection string within the deployment.json file (or equivalent) in the cinchy.devops.automations repo.

4.3 Retrieve the SSH Keys

The following section breaks down how to retrieve your SSH keys for both AWS and Azure deployments.

4.3.1 AWS SSH Keys

1. The SSH key to connect to the Kubernetes nodes is maintained within the terraform state and can be retrieved by executing the following command: