Skip to content

System Overview

This area explains how IntegraMon is built technically, how the major runtime parts interact, and where to continue when you need deployment, operations, or deeper component-level analysis.

Chapters

API reference

IntegraMon already exposes live API reference UIs:

Use them as the primary source when you need endpoint lists, request shapes, or quick manual API tests. For authenticated endpoints, obtain a JWT via /api/token/ first and then authorize with Bearer <token>.

Core principle

IntegraMon runs as a container-based application. It can be operated in SAP BTP / Cloud Foundry, in a public or private cloud, or in an on-premise environment as long as the relevant SAP CPI or Edge-related target landscape is reachable.

In practice, connectivity is more important than the hosting label itself. Especially for Edge Integration Cell and hybrid network scenarios, IntegraMon should run where the required API and operational connections are reliably available.

Runtime layers

IntegraMon can be read as four cooperating layers:

  1. User-facing React screens for setup, monitoring, and administration
  2. Django REST APIs for configuration, documentation, admin, and CPI data access
  3. Domain services, worker loops, and alert/archive logic in the backend
  4. Persistent storage plus outbound connectivity to SAP CPI, Edge, SMTP, and supporting infrastructure

Each tenant configuration moves through all four layers. A user creates or edits the configuration in the frontend, the backend persists the structure in cConfig and cConfigExt, worker jobs use that structure at runtime, and the resulting messages, artifacts, alerts, and archives are written back for later UI queries.

High-level architecture

flowchart LR
    U[User or Admin] --> FE[React frontend]
    FE --> API[Django APIs]
    API --> CFG[cConfig and cConfigExt]
    API --> DOCS[Docs service]
    API --> CPI[SAP CPI and Edge APIs]
    API --> MAIL[SMTP and notification services]
    W[Worker loops] --> CFG
    W --> CPI
    W --> DATA[cpi message, alert, archive, package tables]
    API --> DATA
    FE --> API

Main responsibilities

  • The frontend owns user interaction, field validation hints, and context-specific help.
  • The backend API owns persistence, permissions, data assembly, and integration endpoints.
  • Worker processes own recurring collection and evaluation tasks such as package sync, message sync, alert evaluation, archive maintenance, and keystore synchronization.
  • The documentation system exposes technical and product-facing markdown trees through the same docs UI with separate sources and permissions.

Where to go next

  • Use Module Map to understand the major files and runtime responsibilities.
  • Use Core Flows to trace what happens during create, update, monitoring, and operational review.
  • Continue with Deployment and Operations for environment-facing work.