Fabric Commands

Fabric includes a number of commands for viewing Fabric configurations, updating Fabric settings and running Fabric processes. Fabric commands can be executed either from the Fabric console or via the user code (project implementation) that invokes Fabric commands in the execute() and fetch() methods.

Fabric commands are not case sensitive. For example, Get, get, and GET are all equivalent.

In this document, commands are written in ALL CAPS when described in general, and in lowercase when shown as command-line examples. This is done for clarity only. You can type commands in any style you prefer, but it is good practice to remain consistent.

Fabric Help

After logging into Fabric, type HELP to view a list of available Fabric commands. To view the description and syntax of a specific command, type help [command name].

For example:

Fabric Commands — Main Groups

Fabric commands can be divided into the following groups:

Get Commands

Get Instance

The GET command is used to retrieve information for a given LUI and to synchronize information from variuos data sources if needed. Note that multiple LUs can be received using a GET command. However, multiple LUIs cannot be received from the same LU using a GET command.

The following message is displayed when attempting to get multiple LUIs from the same LU using a GET command:

Only single instance per LUT can be used on the same GET command.

The consistency level of the GET LUI command can be set to ONE. If it fails to achieve a QUORUM consistency level, the sync mode is set to OFF. To do so, run the following Fabric command on the session:

SET LUI_READ_ONE_WHEN_FAIL = true

Note that this command sets the consistency level at session level. The default value of this parameter is false.

The following table lists the GET commands:

Remote GET and GETF Commands

GET and GETF commands can be executed from a datacenter (DC) that is not connected to data sources if other DCs are connected to the source interfaces. To carry out a GET or GETF command in such a manner, populate the DC parameter name of the GET and GETF commands. This will invoke the remote DC connected to the data source via the JDBC. The remote GET and GETF commands return the instances after executing the commands on the remote Fabric node. Cassandra then replicates the data between the nodes of the Cassandra cluster.

The remote GET and GETF commands run on a random Fabric node on the remote DC. Therefore, always verify the permissions for the GET and GETF commands’ execution on Fabric’s local and remote nodes.

Users are responsible for determining whether an LUI sync is required, and should run the remote GET or GETF commands only in that case. This prevents unnecessary calls to the remote Fabric node by retrieving the local LUI version instead.

Delete LUI Command

The DELETE INSTANCE command deletes an LUI or multiple LUIs from Fabric. Unlike the GET command, several LUIs from the same LU can be deleted with a single DELETE command. The consistency level of the Delete Instance is set in the LU_INSTANCE_DELETE parameter of the config.ini file. The default value is LOCAL_QUOROM.

The following table lists the DELETE commands:

Release LU

The Fabric RELEASE command detaches either a specific LU from the session, or all schemas from it. If no specification is provided, all result sets close.

Fabric View

Fabric includes commands that display the Fabric configuration and settings. For example:

• Fabric cluster information:

  • CLUSTERID, returns the cluster identifier defined on the node.id.
  • CLUSTERSTATUS, returns the status of all Fabric nodes. Also includes: node_id, logical IDs, DC name, IP addresses.
  • TIME, gets the node system time.
  • VERSION INFO, the installed Fabric version. Note that when logged out of Fabric, you can retrieve the version using the k2fabric -version command.

• Information about the deployed implementation:

  • DESCRIBE, used for querying Fabric's metadata structure.
  • LIST, a list of deployed objects and Fabric credentials (ROLES, USERS, TOKENS, ROLE_PERMISSIONS, ENVIRONMENTS and METHODS).

• General information:

  • SET, displays the current session’s settings: Sync Mode, the LUI in scope, the deployed project name, Global values and the active environment.

Fabric Settings

SET Command

The Fabric SET command displays the values of Fabric session's settings (such as project name, sync mode, scope) as well as the session variable values. Note that settings with default values are not displayed; they appear in the SET command's output only after being modified to non-default values.

Fabric Setting — Session Level

The Fabric SET command enables updating Fabric settings at session level.

• Set global variables.

• Sync settings:

  • Set sync mode
  • Set sync timeout
  • Set ignore source exception
  • Set always_sync
  • Set sync_on_demand

• Set the active environment

• SET ATTACH_POLICY command, sets the MicroDB attachment policy to the Fabric session. The valid values are:

  • LATEST (default) - check the Storage for the latest version of the MicroDB. Use the one in cache only if it is the latest version.
  • ANY - use the MicroDB from cache if available, otherwise retrieve the MicroDB from Storage.
  • TRY_LATEST - try to retrieve the latest MicroDB from Storage. If the operation fails, use the one in cache, if exists.
  • The default can be changed in the config.ini file.

• SET OUTPUT command, sets the output format of the query's results.

• SET INSTANCE_TTL command, sets the Time To Live (TTL) in seconds for each LUI; the LUI is automatically deleted from Fabric after the set TTL ends. Fabric V7.1 adds the option to avoid saving the LUI in Fabric (instead of save and delete) if the TTL is set to zero. When the TTL is set to zero, Fabric does not clean older versions of the LUI (if any exist). The TTL must be greater than zero in order to clean the LUI from Fabric.

• SET LUI_READ_ONE_WHEN_FAIL command, sets the consistency level for the GET LUI command to ONE. If it fails to achieve a QUORUM consistency level, the sync mode is set to OFF.

• SET FROM command, updates several settings in one compound command using JSON structure with the following syntax: "set from '{["scope" : {\}],]["attached" : {"\": "\"[ , "": "<LUI>"} , …]}' " . The command is built from two optional parts, each can be omitted:

  • Scope, holds one or more set commands like "sync" or "environment".

  • Attached, the LUs to be loaded into the session. Several LUIs can be specified if they are from different LUTs.

  • Examples:

  fabric>set from '{ "attached" : {"Customer": "1", "ORDERS": "4"}}';
  (1 row affected)
  
  fabric>set from '{ "scope" : {"sync": "on", "environment" : "_dev"}, "attached" : {"Customer": "1", "ORDERS": "3"}}';
  (1 row affected)
  
  fabric>set from '{ "scope" : {"sync": "force", "environment" : "UAT1"}}';
  (1 row affected)
  

• SET USER_ROLES command, returns the list of roles of the connected user.

• SET AUTO_MDB_SCOPE command, allows querying the Logical Unit without performing the GET command explicitly ("No Get") when an SQL statement includes a WHERE clause with the filter by IID. The filter must include the field name defined as Instance ID Column of the LU Root Table; otherwise an error message is shown.

  The following logic is performed on each SQL statement run:

  • Sync the LUI based on the defined sync mode.
  • Execute the query.
  • Release the instance.

  Queries without a filter by IID cannot be executed in this mode. To deactivate it, set AUTO_MDB_SCOPE to false.

  fabric>set auto_mdb_scope=true;
  (1 row affected)

  fabric>select * from CRM.customer where customer_id = 123;
  |CUSTOMER_ID|SSN       |FIRST_NAME|LAST_NAME|HAS_OPEN_CASES|VALIDATIONS_NOT_PASSED|
  +-----------+----------+----------+---------+--------------+----------------------+
  |123.0      |7416713403|Gaynelle  |Gill     |0             |null                  |

  (1 rows)

  fabric>select customer.customer_id, subscriber.contract_id, subscriber.contract_description 
  from CRM.customer, CRM.subscriber where customer.customer_id = 123;
  |CUSTOMER_ID|CONTRACT_ID|CONTRACT_DESCRIPTION|
  +-----------+-----------+--------------------+
  |123.0      |314.0      |5G tether           |
  |123.0      |315.0      |10G LTE             |
  |123.0      |316.0      |450 min             |
  |123.0      |317.0      |Unlimited call      |
  |123.0      |318.0      |Unlimited text      |

  (5 rows)

  fabric>select * from CRM.address where entity_id = 123;
  Cannot execute the query due to missing WHERE clause on the IID column.

This feature enables querying Fabric by various external systems (such as BI) that are not familiar with the Fabric syntax. They can use standard SQL language rather than the Fabric GET command. For external connection to Fabric, AUTO_MDB_SCOPE=true should be set via the Fabric Connection URL.

• SET DEFAULT command, can be used to reset all related session-level parameters to their default value.

• SET DB_PROXY command, can be used to activate the scope of the operations for a specified DB interface; all operations will then use this interface until deactivated.

  • Syntax: SET DB_PROXY [= <interface name>]

  • If the interface name is not specified, the command will show the current interface name.

  • To turn it off use: set db_proxy=off.

  • A new parameter — ENABLE_DB_INTERFACE_PROXY — was added to the config.ini file; it is set by default to false. Set it to true to enable using this new command.

• SET BUFFER_RESULT_SET command, enables uploading all the following SELECT statements from Fabric to memory.

  • Syntax: SET BUFFER_RESULT_SET = true
  • To inactivate it, set it back to false.
  • The purpose is to prevent the MicroDB SQLite file from being locked, which can occur when a GET & SELECT from LU1 is followed by loop of GET & SELECT from LU2.

• SET CLUSTER_DISTRIBUTE_AFFINITY command, used for distributing the subsequent Fabric command to the specified affinity.

  • Syntax: SET CLUSTER_DISTRIBUTE_AFFINITY = <AFFINITY>
  • Use ALL to distribute the following Fabric command to all live nodes.

Fabric Setting via JDBC Connection URL

Fabric allows setting session variables via the Connection URL by concatenating them to the connection string using the following syntax:

jdbc:fabric://[server:port]?user=[user_name]&password=[password]&[key1]=[value1]&[key2]=[value2]

For example:

jdbc:fabric://[localhost:5124]?user=admin&password=admin&timeout=0&sync=off&auto_mdb_scope=true

This can be used when external systems (such as BI) that are not familiar with Fabric syntax connect to Fabric. The delimiter can be either & or ;.

Fabric Setting — Cluster Level

Use the SET_GLOBAL command to set an active environment or a global value on a Fabric cluster.

The values are kept in the System DB global_settings table under k2system schema.

Fabric Security and Credentials

Fabric Security Commands

• Master key generation commands are used for encrypting LUI data and interface details. Click to open the Fabric Devops Security articles and learn more about Fabric Security Hardening.
• Fabric Credentials Commands, a list of commands used for setting Fabric credentials such as users, roles, tokens or permissions.

Deploy and Drop Commands

Fabric commands to deploy Fabric implementation and Fabric Environments on the Fabric console.

Drop LU Command

The DROP LUTYPE command deletes LU metadata (the LU schema) and its LUIs from Fabric. The DROP command also deletes the LU from Storage and the related LU entry from the k2_lut_info in the System DB. Once the LU is dropped, it should be redeployed to the Fabric server.

Click for more information about Fabric System DB.

This command is primarily intended for use in Testing environment to restart deployment configurations. In Production, the DROP LUTYPE command and the reset.sh script are rarely used. A possible scenario is to clean the environment after a soft launch prior to starting an actual Production run. A Drop is followed by an initial load / migration of the data for the dropped LU.

Drop LU Syntax

DROP LUTYPE [LU Name];

Example:

fabric>DROP LUTYPE Customer;

Fabric Environments and Interfaces

Fabric enables deploying Fabric environments and setting active environments at session or cluster level.

The interfaces of an active environment can be tested using the TEST_CONNECTION command. To do so, run the TEST_CONNECTION command without parameters to test the connection of all interfaces (DB and non-DB) in the active environment.

Run Queries on System DB

CQL queries can be run on Cassandra System DB in the Fabric server using the CQL command only for the selected statement.

Example of CQL command on Cassandra:

fabric>cql select * from k2view_customer.entity;

Click for more information about Cassandra Basic Commands.

Jobs Commands

Get the Fabric jobs' list and status, start, stop, update and resume jobs.

Click for more information about Fabric jobs.

Batch Process Commands

The Batch Process mechanism enables executing different types of Fabric commands in a batch mode on remote Fabric nodes.

Fabric includes commands for starting, retrying and canceling batch process executions, as well as commands for monitoring their progress.

MIGRATE commands serve as aliases for BATCH commands.

Click for more information about the Fabric Batch Process mechanism.

Process Control

PS and Kill Commands

• The PS command displays the current tasks running on the Fabric cluster, allowing you to run it on node1 and view running tasks on node2. The PS command displays different types of tasks such as Fabric commands, Fabric jobs, Web Service and Graphit, Sync processes, Broadway Actor, parser, or user logic. When a task/thread is specified as a parameter, it shows its stack trace.

• The KILL command terminates tasks currently shown by the PS command. Note that you can terminate a task running on a different node within the Fabric cluster.

Execution Monitoring

The TRACE command enables tracing of internal Fabric operations upon request and recording them in tracing files.

Click for more information about the Tracing mechanism.

CommonDB & Reference Tables

Fabric enables the creation of Reference tables that can be used by all LUs and Web Services. A Reference table generally holds cross-project data that serves as a reference and is shared by all LUs in the project. For example, a Postal Code table maps customer addresses to their postal codes.

Reference table commands enable performing synchronization, checking sync status, and ensuring Reference tables synchronization is completed before the workflow proceeds.

Click for more information about Reference tables.

Fabric Transactions

Fabric enables running a single transaction on a specific LU table of the Instance ID or on a Reference table. When this functionality is used, Fabric becomes the master of the data rather than syncing data from external systems. Thus, Fabric can receive transaction feeds and apply updates to the relevant Instance ID or Reference table. Use a BEGIN command to start a transaction before running INSERT, UPDATE or DELETE commands, and end it with COMMIT or ROLLBACK commands to confirm or cancel the updates.

The following Fabric commands support transactional operations:

• BEGIN, start a transaction.
• SELECT, UPDATE, INSERT, and DELETE, run Select, Insert, Update and Delete transactions on the LUI or Reference table data.
• COMMIT and ROLLBACK, confirm or cancel the updates.

Fabric also enables writing the transaction into a delta table using the SET ASYNC_TRX=true command.

Click for more information about Fabric Transactions.

CDC and Search

The Fabric Change Data Capture (CDC) solution notifies external systems about data changes and provides built-in integration with Elasticsearch to support cross-LUI search capabilities.

For example: Search all customers named “John Doe” that live in “New-York”.

The Fabric SEARCH command initiates a search on Elasticsearch, while the CDC_REPUBLISH_INSTANCE command allows republishing CDC data on LUI.

Broadway Command

The Fabric BROADWAY command enables running a Broadway flow and providing the LU name and execution parameters using param=value syntax. The flow can be invoked by a command after it has been deployed. The command syntax is:

broadway <LUT>.<FLOW_NAME> [param1=value1, param2=value2...] RESULT_STRUCTURE=<ROW/COLUMN/CURSOR>

Below are the types of execution parameters:

1. External input arguments of a flow, if they exist.

2. Result Structure enables defining the format of the flow output. The default mode is configurable via config.ini. Three modes exist:

   • COLUMN (default) — the outputs are returned as each output in a column.

   |result |date         |                                                 
   |+-----+--------------+                                                 
   |15     |2022-07-19   |
   

   • ROW — the Broadway flow outputs are returned as each output in a row.

   |column |value       |                                                     
   |+-------+-----------+                                                   
   |result   |15        |                                                   
   |date     |2022-07-19|
   

   • CURSOR — the output of the first flow is transformed into a table; all other outputs are disregarded.

   Case 1: The following output:

   |column   |value     |
   +---------+----------+
   |result   |1,2,3     |
   |date     |2022-07-19|
   

   will be transformed into:

   |result |
   +-------+
   |1      |
   |2      |
   |3      |
   

   Case 2: The following output:

   |column   |value                                                                 |
   +---------+----------------------------------------------------------------------+
   |result   | [{ val1: 1,val2: 2,val3: 3},{ val1: 4,val2: 5,val3: 6}               |
   |date     | 2022-07-19                                                           |
   

   will be transformed into:

   |val1 |  val2  | val3
   +-----+--------+-----
   |1    |  2     |  3
   |4    |  5     |  6
   

3. Recovery parameters:

   • recoveryId, a unique ID for running the flow with a recovery point. Flow recovery is enabled only if the recovery ID is provided.

   • recoveryTtl (optional), time to live (in seconds) for keeping the recovery point in the Cassandra broadway_recovery_point table under the k2system keyspace. The default value is defined in the Broadway config.ini section with the RECOVERY_TTL_SEC key.

   • recoveryMaxTries (optional), specifies the maximum number of retries allowed before a flow is deleted from the Cassandra broadway_recovery_point table. The default value is defined in the Broadway config.ini section with the RECOVERY_MAX_RETRIES key.

   Click for more information about Broadway Recovery Points.

   • Example of running in a recovery mode:

   fabric>broadway AT_MPI.files_test recoveryId=rl1, recoveryTtl=3000, recoveryMaxTries=5, param1=test1, param2=test2;
   

4. Profiler Telemetry:

   • To invoke the Broadway profiler, set profilerTelemetry to true. This will add the profiler results to the command results, under the profilerTelemetry key.

   Click for more information about Broadway Profiler.

   • Example of running with a profiler:

   fabric>broadway P2.getLUVariable luName='P2' variableName='TDM_TAR_ENV_NAME' profilerTelemetry=true;
   

Queries Helpers

An SQL statement can be preceded by either the EXPLAIN keyword or the EXPLAIN QUERY PLAN phrase. When used, the SQL statement behaves like a query and returns details about its operations. If the EXPLAIN keyword or phrase is omitted, the statement executes normally.

EXPLAIN and EXPLAIN QUERY PLAN are intended for interactive analysis and troubleshooting purposes only.

Example:

MDB Export / Import

Fabric supports exporting and importing LUIs (Logical Unit Instances) for backup, testing, data sharing, and cross-environment migration. LUIs can be transferred either via PostgreSQL interfaces or through file-based interfaces in SQLite format.

These capabilities are useful for scenarios such as environment replication, regression testing with fixed data snapshots, or issue reproduction and debugging.

MDB_EXPORT Command

Syntax:

MDB_EXPORT <LU>[.<IID>] WITH INTERFACE_NAME=<name> [optional parameters]

The command operates in three modes:

1. Schema Export to PostgreSQL (without IID)

   • Creates or replaces the LU schema in the specified PostgreSQL interface.

   • All table definitions, constraints (PKs, FKs, indexes), and structure are exported.

   • An __iid column is added to each table and included in the PK.

   • If PHYSICAL_FK=true (default), foreign keys are included in the schema.

   • Returns the number of exported tables.

2. LUI Data Export to PostgreSQL (with IID)

   • Exports LUI data from Fabric to the PostgreSQL interface.

   • Respects table constraints and structure, using PKs and FKs.

   • Returns the number of exported rows.

   • Supports:

     • INCLUDED_TABLES / EXCLUDED_TABLES for granular control
     • REMOTE_IID to assign a different target IID in the exported schema

3. LUI Data Export to File

   • Exports LUI data from Fabric to an SQLite file through a file-type interface.

   • Useful for portability, testing, and reproducibility across environments.

   • File-type interfaces can include S3, Azure Blob, GCS, SFTP, or local file system.

   • Syntax: MDB_EXPORT <LU>.<IID> WITH INTERFACE_NAME=<file-interface> [REMOTE_IID=<file-name>]

MDB_IMPORT Command

Syntax:

MDB_IMPORT <LU>.<IID> WITH INTERFACE_NAME=<name> [optional parameters]

The command supports two modes:

1. Import from PostgreSQL into Fabric

   • Replaces the current LUI data in Fabric with data from the PostgreSQL interface.

   • Supports:

     • EXCLUDED_TABLES to skip specific tables
     • REMOTE_IID to use a source IID different from the target IID

2. Import from File into Fabric

   • Imports LUI data from a file-based interface into Fabric.

   • Suitable for restoring fixed test sets or debugging datasets.

   • Syntax: MDB_IMPORT <LU>.<IID> WITH INTERFACE_NAME=<file-interface> [REMOTE_IID=<file-name>]

Parameters Reference

| Parameter | Description | | ----------------- | ------------------------------------------------------------ | | INTERFACE_NAME | Name of the PostgreSQL or file-type interface. | | INCLUDED_TABLES | A comma-separated list of table names (optionally containing columns) to be included. | | EXCLUDED_TABLES | A comma-separated list of table names (optionally containing columns) to be excluded. | | FK | When true, includes FK-linked tables/columns even if excluded (default: true). | | PHYSICAL_FK | When true, FKs are physically created in schema (default: true). | | REMOTE_IID | Optional. Used for renaming the IID in the target schema or file. |

This flexible export/import system allows teams to efficiently move LUIs across environments, using either database- or file-based approaches.

MDB Size

Fabric provides the MDB_SIZE command to return the size of one or several MDBs. The syntax is:

• Return the size of the specified instance:

MDB_SIZE <LUT_NAME>.'<INSTANCE_ID>'

• Return the size of the listed instances:

MDB_SIZE <LUT_NAME>.(<instance 1,instance 2,etc...>)