Change tracking
  • 21 Jan 2022
  • 2 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Change tracking

  • Dark
    Light
  • PDF

Article summary

Every change to every resource in your EchoStream Tenant (including the Tenant itself) is stored for the life of your Tenant in EchoStream.

Change tracking provides critical functionality for:

  • meeting compliance requirements of know who changed what when.
  • debugging problems that occur within your Tenant's processing network after changes are made.
  • auditing your Tenant's users activities.
  • automating the implementation of changes to Managed Apps, Managed Nodes, External Apps, Cross Accoutn Apps, and External Nodes.

Access to the tracked changes is provided to you via the EchoStream Application, API calls or via the emission of the change itself as a message that you can process in your Tenant.

Getting changes

You can use the API to list changes across your entire Tenant or to list changes for a specific EchoStream resource in your Tenant. You can use the EchoStream Application to list changes to a specfic resource in your Tenant.

Listing changes across all resources in your Tenant

To list changes across your Tenant you must use the API. Simply call Query.ListChanges and provide the desired date range.

NOTE - depending on your date range, there may be many changes. You should probably consider providing a limit when calling this API and paginating the changes that are returned.

Listing changes for a specific EchoStream resource in your Tenant

To list changes for a specific resource you can use either the EchoStream Application or the API.

Using the Application

Simply navigate to the resource (e.g. - Processor Node) that you wish to examine the changes for and choose List Changes. The detailed changes that were made to that resource will be displayed to you.

Using the API

To list changes using the API, you must construct a GraphQL query that gets the resource to list changes for (using one of the Query.GetXXX calls) and within that call ask for the ListChanges field (make sure to provide the necessary parameters).

Processing changes in your Tenant's processing network

Every Tenant is automatically given a Change Emitter Node. This Change Emitter Node will emit every change that to a resource in your Tenant if that resource has incurred an emittable change (there are some changes that are EchoStream internal; these will not be emitted, but are available via the UI/API).

Your Tenant automatically uses this mechanism to route changes that affect Managed, External or Cross Account Apps via the App Change Router Node. For those Apps that wish to receive these changes, simply connect an Edge from the App Change Router to the App's App Change Reciever Node (this is done automatically for you for Managed Apps).

You can also create Nodes to process changes and connect those Nodes to the Change Emitter. Some use cases for this could be:

  • firing the change into an alert management system so that your Ops team is notified immediately of any change.
  • sending the change to a Machine Learning algorithm to detect anomalies.
  • storing all changes into a Data Lake/ Data Mart for long term delta analysis.