Knowledge Base Academy Community My Tickets
Fabric 8.1
Fabric 8.1 Fabric 8.0 Fabric 7.2 Fabric 7.1 Fabric 7.0 Fabric 6.5 Fabric 6.4

LU Tables Overview

LU tables are the basic building blocks for creating Logical Units and their Schemas. Their purpose is to hold data, which is retrieved from various sources after it has been transformed according to a project’s requirements.

An LU table can also act as the master data, which holds data that is generated in Fabric and not synced by source systems.

Click for more information about how to add an LU Table to an LU Schema.

LU tables can be created either automatically, for example, by using the Auto Discovery Wizard or manually.

When building a table manually, you should first define the table's properties, columns and indexes, and then create the Table Population map, which holds the transformation and mapping rules.

Creating a population for an LU table is optional. When a table acts as the master data, it does not get feeds from source systems and the Table Population is made redundant.

LU tables can be created either manually or based on data source tables. In the latter option, a table population is automatically created in accordance with the table's definitions.

LU Table Definitions

In an LU table window you can define the following:

  • Table Columns - holds a list of columns and their definitions.
  • Table Indexes - holds a list of indexes that are added to an LU table for improving the selection process. Each LU table can have several indexes where each index can contain several columns.
  • CDC Indexes - holds a list of table fields to be published to an external system using the CDC mechanism. This is done per CDC topic, for example 'Search', which is used for a cross-instance search within the Elasticsearch engine. Read here to learn how to configure it.
  • Other Table Properties - where table properties, such as the Primary Key, Sync Method or related Enrichment functions, are defined.

Built-in Platform LU Tables

Several LU tables are automatically generated by the platform and are not displayed in the LU Schema window. Among them are:

  • _k2_main_info, which stores the last deployed LU version and the last sync instance. This table is used internally by Fabric.

Field Name

Description

lu_name

Logical Unit name

version

Version of the last deploy which impacted the LU Schema.

instance_id

Instance Id

version_timestamp

Timestamp of the LU schema last deploy. This field exists due to backward compatibility.

  • _k2_objects_info, which stores the LU instance's statistics. The table is updated when a sync has been performed. In case of the References LU, it is also updated when there has been a verification whether to perform a sync or not.

Field Name

Description

table_name

LU table name

object_name

Object name, population name or enrichment function name

type

Object type: 6 - population, 10 - enrichment function

verified_time

Last time of verification as to whether the object should be synced or not

start_sync_time

Object's last sync start time

end_sync_time

Object's last sync end time

start_write_time

Start time of the last write LU instance into the SQLite file

last_write_time

End time of the last write LU instance into the SQLite file

number_of_records

Number of processed records

time_to_populate_in_sec

Total time in seconds to run the object

next_time_to_populate_object

Next time the object should be synced

version

Version of the object's last deployed schema

sync_error

Object's sync error message in case of a failure

​

LU Tables Overview

LU tables are the basic building blocks for creating Logical Units and their Schemas. Their purpose is to hold data, which is retrieved from various sources after it has been transformed according to a project’s requirements.

An LU table can also act as the master data, which holds data that is generated in Fabric and not synced by source systems.

Click for more information about how to add an LU Table to an LU Schema.

LU tables can be created either automatically, for example, by using the Auto Discovery Wizard or manually.

When building a table manually, you should first define the table's properties, columns and indexes, and then create the Table Population map, which holds the transformation and mapping rules.

Creating a population for an LU table is optional. When a table acts as the master data, it does not get feeds from source systems and the Table Population is made redundant.

LU tables can be created either manually or based on data source tables. In the latter option, a table population is automatically created in accordance with the table's definitions.

LU Table Definitions

In an LU table window you can define the following:

  • Table Columns - holds a list of columns and their definitions.
  • Table Indexes - holds a list of indexes that are added to an LU table for improving the selection process. Each LU table can have several indexes where each index can contain several columns.
  • CDC Indexes - holds a list of table fields to be published to an external system using the CDC mechanism. This is done per CDC topic, for example 'Search', which is used for a cross-instance search within the Elasticsearch engine. Read here to learn how to configure it.
  • Other Table Properties - where table properties, such as the Primary Key, Sync Method or related Enrichment functions, are defined.

Built-in Platform LU Tables

Several LU tables are automatically generated by the platform and are not displayed in the LU Schema window. Among them are:

  • _k2_main_info, which stores the last deployed LU version and the last sync instance. This table is used internally by Fabric.

Field Name

Description

lu_name

Logical Unit name

version

Version of the last deploy which impacted the LU Schema.

instance_id

Instance Id

version_timestamp

Timestamp of the LU schema last deploy. This field exists due to backward compatibility.

  • _k2_objects_info, which stores the LU instance's statistics. The table is updated when a sync has been performed. In case of the References LU, it is also updated when there has been a verification whether to perform a sync or not.

Field Name

Description

table_name

LU table name

object_name

Object name, population name or enrichment function name

type

Object type: 6 - population, 10 - enrichment function

verified_time

Last time of verification as to whether the object should be synced or not

start_sync_time

Object's last sync start time

end_sync_time

Object's last sync end time

start_write_time

Start time of the last write LU instance into the SQLite file

last_write_time

End time of the last write LU instance into the SQLite file

number_of_records

Number of processed records

time_to_populate_in_sec

Total time in seconds to run the object

next_time_to_populate_object

Next time the object should be synced

version

Version of the object's last deployed schema

sync_error

Object's sync error message in case of a failure

​

© Copyright 2024 K2VIEW