Skip to main content

Ghost Data Event in RCOM Gateway

Ghost Data is a specialized data serialization format designed primarily for communication between the RCOM Gateway and the RcomMobile service. It encapsulates structured tabular data, typically representing object records or system states, into a compact, efficient JSON payload. Although it was originally developed for RcomMobile, the Ghost Data format is generic and extensible, making it usable by any other RCOM Gateway service that conforms to its schema.

This article explains what Ghost Data is, where it's used, and how to construct, interpret, and leverage it within workflows.

What Is Ghost Data?​

Ghost Data is a serialized JSON structure used to represent tabular data across multiple entity types (e.g., users, locations, inventory). It encapsulates rows of data with a compact column mapping and supports efficient serialization/deserialization.

Example:​

{
  "T": [ 
    {
      "TN": "T_USER",
      "CN": "OBJECT_ID;CLIENT_ID;OBJECT_GROUP_ID;...;ACCESS",
      "CT": "...",
      "DR": [ { "c": [ ... ] }, { "c": [ ... ] } ]
    }
  ]
}

Where:

  • T: Array of tables.
  • TN: Table name (e.g., T_USER, T_LOCATION).
  • CN: Semicolon-separated column names.
  • CT: Column types (used internally for rendering/validation).
  • DR: Data Rows. Each object has a c array with positional column values.
info

Each record is a positionally mapped list of values (c) corresponding to the column names (CN).

Use Case​

Use CasePurpose
RcomMobile communicationCore serialization format for syncing object state and lists
WorkflowsSome workflow actions convert tabular data into GhostData
REST API endpointsSelectable as an event type (GhostData) for data ingestion
MQTT topicsLightweight structure ideal for MQTT payloads
Custom dashboards/UIEfficient backend-to-frontend data transfer format

Ghost data Features​

FeatureGhostData
FormatJSON
StructureTables with rows and columns
Workflow-compatible✅ Yes
Supports filtering❌ No
Primary UseMobile sync, REST APIs, batch transfer

Example Ghost Data Structure​

Below is a simplified snippet of actual Ghost Data for a T_USER table:

{
  "T": [
    {
      "TN": "T_USER",
      "CN": "OBJECT_ID;CLIENT_ID;USER_NAME;TIME_CREATED;ACCESS",
      "CT": ";;;1;2",
      "DR": [
        {
          "c": [
            "*******-4620-****-a496-**********",
            "dummyclient",
            "admin",
            "2025-04-11T08:30:48.707+02:00",
            2
          ]
        }
      ]
    }
  ]
}

To interpret:

  • The column USER_NAME maps to "admin"
  • ACCESS maps to integer 2 (may represent a permission level)

Creating Ghost Data in Workflows​

To create Ghost Data in a workflow:

  • Use a ConvertToGhostData action block.
  • Input must be a dictionary of the following shape:
Dictionary<string, List<Dictionary<string, string>>>

Each key in the dictionary is a table name (e.g., "T_USER"), and the value is a list of rows represented as dictionaries.

Example input:​

{
  "T_USER": [
    { "USER_NAME": "admin", "ACCESS": "2" },
    { "USER_NAME": "user1", "ACCESS": "1" }
  ]
}

This input will be serialized into Ghost Data JSON format and stored in a result variable for downstream use.

✅Best Practices​

  • Always match column names (CN) with the keys in your input dictionaries.
  • Use consistent table names (TN) across your services.
  • Keep column orders stable if client-side processing expects fixed indexes.
  • Prefer ConvertToGhostData over manual construction, it validates the structure and serializes consistently.
  • Use CastDictionaryList to rehydrate Ghost Data into usable row structures inside workflows.

Related Articles