Git Integration and Export Reference

Integrate solutions with Git repositories.

Reference → Solution → DevOps → Track Changes | Git 

Git Export Architecture

Hybrid Configuration Management

Git-Friendly JSON Format

Git-Friendly JSON Format

Configuration

Enabling Git Export

Navigate to Solution → Settings → Version Control:

Export Modes

Automatic Export:

• Monitors configuration changes
• Exports on version increment
• Batches rapid changes
• Background operation

Manual Export:

• Export All - Complete solution
• Export Module - Selected module
• Export Current - Active object

File Naming Convention

All JSON files are exported to a single flat directory using standardized naming:

Examples:

Git/
??? AlarmsGroups.json
??? AlarmsItems.json
??? DevicesChannels.json
??? DevicesNodes.json
??? DevicesPoints.json
??? ScriptsExpressions.json
??? ScriptsTasks-ServerStartup.json
??? ScriptsTasks-DataProcessor.json
??? UnsTags.json
??? UnsUserTypes.json
??? UserType-LabelingMachine.json
??? UserType-Motor.json

Benefits:

• Simple enumeration: ls *.json returns all files
• Pattern matching: ScriptsTasks-*.json finds all script tasks
• Predictable paths for MCP/AI tools
• Alphabetical grouping by module prefix

JSON File Format

Standard Structure (Format v1.1)

json

{
  "ObjectIdentification": {
    "TableType": "ScriptsTasks",
    "SolutionName": "MyProject"
  },
  "ExportMetadata": {
    "ExportDate": "2025-08-23T10:30:00Z",
    "ExportUser": "john.doe",
    "ExportProduct": "FrameworX",
    "ExportProductVersion": "10.1.1.1011",
    "ExportFormat": "1.1"
  },
  "Data": [
    { /* object properties */ }
  ]
}

Note: The Data section is always an array, even for single-object exports.

Fields Filtered from Export

The following fields are excluded from export to reduce file size and improve readability:

Auto-Generated Fields:

Compiled/Binary Data:

Build Results:

Calculated Fields:

Conditional Filtering:

Note: Fields with empty or null values that represent configurable options (such as Description, Trigger, NamespaceDeclarations) are kept in the export for discoverability.

Export Categories

Individual Object Files ({TableType}-{Name}.json):

• Script Tasks and Classes
• Display Layouts
• Dataset Queries
• Report Definitions
• Symbol Definitions

Bulk Table Files ({TableType}.json):

• Tags (UnsTags)
• Alarm Items (AlarmsItems)
• Device Points (DevicesPoints)
• Expressions (ScriptsExpressions)
• UserType Definitions (UnsUserTypes)

JSON Import Behavior

The import function uses the same JSON format as export.

Import Behavior Rules

Conflict Detection

Import uses DateModified to detect potential conflicts:

• If system object is newer than import file → Warn and skip
• If import file is newer than system object → Safe to update (future feature)
• If dates are equal → Skip (no changes)

Import Order Dependencies

When importing related objects, order matters:

1. Independent objects first: Tags, Channels, AlarmGroups, StorageLocations, DatasetDBs
2. Dependent objects after: Nodes→Channels, Points→Nodes+Tags, AlarmItems→Tags+Groups

TableType Reference

Valid TableType values:

Object Reference Formats

When JSON fields reference other objects, use these formats:

Security & Sensitive Data

Data Protection

Environment Variables

json

{
  "DatabaseConnection": "${DB_CONNECTION}",
  "EmailServer": "${SMTP_SERVER}",
  "HistorianPath": "${HISTORIAN_PATH}"
}

Variables resolved at runtime for environment-specific deployment.

Git Workflow

Recommended Process

1. Initialize Repository

bash

cd /path/to/solution
git init
git remote add origin https://github.com/company/scada-config.git

1. Development Branch

bash

git checkout -b feature/new-alarm-logic
# Make changes in FrameworX
git add .
git commit -m "Add temperature monitoring for Reactor-3"
git push origin feature/new-alarm-logic

1. Code Review
   • Create pull request
   • Team reviews changes
   • Merge to main branch

Branching Strategy

Main Branches:

• main - Production-ready code
• develop - Integration branch for features

Feature Branches:

• feature/new-screens - New display development
• feature/alarm-updates - Alarm system modifications
• feature/script-optimization - Script performance improvements

Maintenance Branches:

• hotfix/critical-alarm-fix - Emergency production fixes
• release/v2.1 - Release preparation and stabilization

Branch Hierarchy:

• Main branch serves as production baseline
• Develop branch integrates all feature work
• Feature branches created from develop
• Hotfix branches created from main for urgent fixes
• Release branches created from develop for version preparation

Best Practices Checklist 

What to Export

• Export to Git:
  • Application configuration
  • Display definitions
  • Script code
  • Alarm rules
  • Report templates
  • Static settings
• Keep in Database Only:
  • Runtime tag values
  • Historical data
  • User passwords
  • Session information
  • Temporary data
  • High-frequency updates

Commit Guidelines

Performance

Export Performance

Note: File counts and sizes reduced compared to previous format due to field filtering and flat structure.

Optimization Tips

(No change)

CI/CD Integration

Example GitHub Actions

yaml

name: Validate FrameworX Configuration

on:
  pull_request:
    branches: [ main, develop ]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    
    - name: Validate JSON Schema
      run: |
        for file in $(find . -name "*.json"); do
          python validate_schema.py $file
        done
    
    - name: Check Tag Naming Convention
      run: python check_naming.py ./UnsTags.json
    
    - name: Verify No Credentials
      run: |
        ! grep -r "password\|credential\|secret" --include="*.json"

Note: CI/CD scripts simplified due to flat directory structure - no need to traverse nested folders.

Troubleshooting

See Also

• → Object Model Quick Reference — Complete object reference
• → JSON Import/Export Specification — Detailed field reference
• → Track Changes Designer UI Reference — Internal change tracking

In this section...