Skip to content

Design

Unlike the other example applications here, this application has no tar.gz file. The application makes direct use of the REST API endpoints to register itself and all the data points it will use during the business logic processing.

You can use the application as the basis for new work or re-use key files in your own application. The Models, Services, and App.cs are the core code elements needed for successful HCC2 REST Server interaction.

The main application business logic is implemented in App.cs. This document details how the application monitors several HCC2 built-in data points, tracking their maximum and minimum values and writing the results, along with other metrics, to new data points. The application primarily uses a poll-response mechanism for data collection with an optional webhook-based configuration monitoring system.

Folder Structure

edgesdk2examplecsharp/          # Root project folder - HCC2 REST client example
│
├── Configuration/              # Application configuration classes
│   ├─ AppConfig.cs             # Main application settings
│   ├─ Operation.cs             # HTTP operation definitions
│   └─ WebhookConfig.cs         # Webhook endpoint configuration
│
├── Models/                     # Data transfer objects and models
│   ├─ ApiResult.cs             # Generic API response wrapper
│   ├─ DataPoint.cs             # Base data point definition
│   ├─ DataPointAdvanced.cs     # Extended data point with metadata
│   ├─ ErrorMessage.cs          # Error response structure
│   ├─ Metadata.cs              # Data point metadata
│   ├─ ProvisionStatus.cs       # Application provisioning state
│   ├─ ReadResponse.cs          # Data point read response
│   ├─ UnityUI.cs               # UI configuration for Unity Edge
│   ├─ WebhookMessage.cs        # Webhook message structure
│   └─ WriteDataPointRequest.cs # Data point write request
│
├── Services/                   # Core service implementations
│   ├─ HeartbeatService.cs      # Application health monitoring
│   ├─ IHeartbeatService.cs     # Heartbeat service interface
│   ├─ IRestClientService.cs    # REST client interface
│   ├─ IWebhookService.cs       # Webhook handling interface
│   ├─ RestClientService.cs     # HCC2 REST API client
│   └─ WebhookService.cs        # Webhook subscription handler
│
├── Utilities/                  # Helper classes and utilities
│   └─ Logger.cs                # Application logging
│
├─ App.cs                       # Main application logic
├─ Program.cs                   # Application entry point
├─ README.md                    # Project documentation
├─ docker-compose.yml           # Docker container configuration for deployment
├─ docker-compose-test.yml      # Docker container configuration for local tests
├─ Dockerfile                   # Docker image definition
└─ HCC2RestClient.csproj        # Project file and dependencies

Core Application Flow

RunAsync:Application Setup Diagram

Application Flow Documentation

The following sections are implemented in 'App.cs'.

RunAsync Flow

The RunAsync method initializes and sets up the application:

  1. Server Connection

    • Waits for REST server availability
    • Retries with configured delay and max retries
  2. Data Point Creation

    • Creates configuration points:
      • configrunningperiod (Double)
      • maxminrestartperiod (Double)
    • Creates general points for monitoring:
      • runcounter (Double)
      • lastruntime (String)
      • cpuusagecurrent (Double)
      • cpuusagemax/min (Double)
      • memoryusagecurrent (Double)
      • memoryusagemax/min (Double)
      • temperature (Double)
      • failcount (Uint32)
  3. Application Setup

    • Registers application with HCC2
    • Sets up data points
    • Stores FQN (Fully Qualified Name) mappings for configuration and general points
    • Exits if no data points are available
  4. Webhook Configuration

    • If enabled, sets up webhook handling
    • Subscribes to configuration topics
    • Otherwise defaults to REST polling
  5. Core Registration

    • Delays 5 seconds for core registration
    • Starts heartbeat service
  6. Provisioning Check

    • Polls for provisioning status
    • Waits for HCC2 user to DEPLOY (first time or when configuration changes)
    • Continues when HasNewConfig is true
  7. Initialization

    • Reads initial data point values
    • Sets healthy heartbeat state
    • Changes heartbeat period to 30s
    • Launches business logic

RunBusinessLogicAsync Flow

The business logic runs in a continuous loop:

  1. Variable Initialization

    • Sets up counters and metrics
    • Initializes monitoring variables
    • Sets default configuration values
  2. Configuration Management

    • Via Webhooks:
      • Processes queued messages
      • Updates period and restart values
    • Via REST:
      • Reads config data points
      • Updates period and restart values
    • Validates config ranges:
      • period: 1-60 seconds
      • restartMinutePeriod: 1-24*60 minutes
  3. Reset Check

    • Checks if restart period elapsed
    • Resets counters and statistics if needed
    • Updates last reset timestamp
  4. Metrics Collection

    • Reads system metrics:
      • CPU usage
      • Memory usage
      • Temperature
    • Updates min/max tracking
    • Resets tracking on first run
  5. Data Writing

    • Writes updated values back to HCC2:
      • Run counter
      • Last runtime
      • Current/min/max CPU usage
      • Current/min/max memory usage
      • Temperature
      • Failure count
    • Includes quality and timestamp
  6. Health Management

    • Updates heartbeat state based on success
    • Increments failure count on errors
    • Logs run statistics
  7. Cycle Delay

    • Waits for configured period
    • Period adjustable via configuration (1-60s)

Error Handling

  • Maintains failure count
  • Updates heartbeat state on failures
  • Logs errors with stack traces
  • Graceful shutdown of services
  • Cleanup of webhooks and heartbeat on exit

Configuration Methods

Two modes of operation:

  1. Webhook Mode

    • Real-time configuration updates
    • Reduced network traffic
    • Requires TCP port 8100 access
  2. REST Polling Mode

    • Regular configuration checks
    • Higher network usage
    • More resilient to network issues

Further Reading

Review the accompanying REST documentation for more information about how an application can interact with the HCC2 system via the REST API.