Skip to content

Core Flows

This page summarizes the recurring end-to-end flows that define how IntegraMon behaves in production.

Tenant creation flow

sequenceDiagram
    participant U as User
    participant W as Wizard UI
    participant API as Core Config API
    participant DB as cConfig and cConfigExt
    U->>W: Enter tenant setup
    W->>W: Normalize defaults and transport fields
    W->>API: POST /api/core/config/
    API->>DB: Create cConfig
    API->>DB: Fan out nested data into cConfigExt rows
    API-->>W: Return tenant id

Key effect: The wizard is not a temporary draft generator. It creates the persisted runtime base that later drives jobs, alerts, and data collection.

Tenant update flow

sequenceDiagram
    participant U as User
    participant S as Settings UI
    participant API as Core Config API
    participant DB as cConfig and cConfigExt
    U->>S: Edit existing settings
    S->>API: PUT or PATCH /api/core/config/:id
    API->>DB: Assemble old state
    API->>DB: Preserve secrets if not resubmitted
    API->>DB: Save changed ext sections
    API-->>S: Return refreshed config snapshot

Key effect: The system updates only the changed persisted sections but returns the assembled full configuration shape back to the client.

Monitoring collection flow

sequenceDiagram
    participant Worker as Worker loops
    participant CFG as cConfigExt
    participant CPI as SAP CPI or Edge
    participant DATA as Message and package tables
    Worker->>CFG: Read active tenant config
    Worker->>CPI: Query messages, packages, payloads, keystore
    CPI-->>Worker: Return remote data
    Worker->>DATA: Persist normalized runtime data

Key effect: Runtime collection is driven by tenant configuration, not by frontend state. The UI only reads the collected results later.

Operational review flow

sequenceDiagram
    participant U as User
    participant UI as Overview or popup UI
    participant API as CPI APIs
    participant DATA as Stored runtime data
    U->>UI: Open alerts, messages, archives, packages
    UI->>API: Request filtered tenant data
    API->>DATA: Query persisted records
    API-->>UI: Return result list and details

Documentation flow

sequenceDiagram
    participant U as User
    participant D as DocumentationCenter
    participant API as Docs API
    participant SRC as docs or sysdocs source tree
    U->>D: Open /docs or /sysdocs
    D->>API: Request tree, page, search
    API->>SRC: Resolve source-specific markdown
    API-->>D: Return filtered page and navigation data

Key effect: User docs and system docs share one UI shell but do not share one source tree.