- 7 minutes to read

What is a Resource?

Monitor every link in your integration chain, from on-premise to cloud, with Nodinite Resources. Each Resource represents a specific, monitorable component in your systems integration landscape, providing real-time health status, automated alerts through Alarm Plugins, and self-service control through Remote Actions.

Key Benefits

  • ✅ End-to-end visibility - Every link in your integration chain becomes a monitorable Resource
  • ✅ Real-time health status - Instant visual indicators (OK, Warning, Error, Unavailable, Connection Error)
  • ✅ Self-service operations - Business users can monitor and manage Resources without IT access
  • ✅ Flexible organization - Group Resources by Application or Category for any business scenario
  • ✅ Context-sensitive help - Associate knowledge base articles with Resources for instant troubleshooting guidance

The Resource Journey

graph LR subgraph "Data Source" MA[fa:fa-monitor-waveform Monitoring Agent
Collects health data] end subgraph "Resource Definition" R[fa:fa-lightbulb-on Resource
Queue, Service, API, DB] APP[fa:fa-box-open Application] CAT[fa:fa-folder Category] MA -->|"Discovers"| R R -->|"Belongs to"| APP R -->|"Classified as"| CAT end subgraph "Monitoring" MS[fa:fa-watch-fitness Monitoring Service
Tracks state changes] MV[fa:fa-display Monitor View
Displays to users] R -->|"Evaluated by"| MS MS -->|"Includes in"| MV end subgraph "Self-Service" USER[fa:fa-user Business User
Monitor & control] MV -->|"Accessible to"| USER end style MA fill:#3F827B,color:#fff style MS fill:#3F827B,color:#fff style R fill:#2678BD,color:#fff style MV fill:#9E59BB,color:#fff style USER fill:#E47528,color:#fff

From data collection to business user self-service: green marks the backing components (Monitoring Agent, Monitoring Service), blue the Resource itself, purple the Monitor View where users see it, and orange the business user who acts on it.

A Resource is a specific object/unit being monitored by a specific Monitoring Agent. A Resource originates from Monitoring Agents. The current state of the Resource is tracked by the Monitoring Service.

The design goal is to represent every link in the System Integration chain as a Resource—enabling true end-to-end monitoring.

The Bridge Between Monitoring and BPM

Resources are the critical link that connects real-time monitoring with business process visualization:

  • In Monitor Views - Resources provide health status, metrics, and remote actions for operational monitoring
  • In BPM - Resources are tied to Services in process steps, bringing real-time operational status into business process diagrams
  • Bidirectional visibility - Click a Resource in a Monitor View to see which BPM processes it belongs to, or click a BPM step to see the underlying Resources and execute remote actions

This dual perspective means:

  • ✅ Operations teams monitor Resources for health and performance
  • ✅ Business users see the same Resources in context of their business processes
  • ✅ Remote actions work in both views - Start/stop services from Monitor Views OR directly from BPM steps
  • ✅ Single source of truth - One Resource, multiple visualizations for different audiences
graph TB subgraph "Monitoring Agent Discovers" MA[fa:fa-monitor-waveform Monitoring Agent] R[fa:fa-lightbulb-on Resource
SQL Server, Queue, API, Service] MA -->|"Discovers & monitors"| R end subgraph "Dual Usage" MV[fa:fa-display Monitor View
Operations perspective] SVC[fa:fa-gear Service
Repository Model] BPM[fa:fa-project-diagram BPM Step
Business perspective] R -->|"Included in"| MV R -->|"Tied to"| SVC SVC -->|"Placed in"| BPM end subgraph "Self-Service Actions" USER1[fa:fa-user Operations Team
Monitor View] USER2[fa:fa-user Business User
BPM View] RA[fa:fa-wrench Remote Actions
Start/Stop/Restart] MV -->|"Access"| USER1 BPM -->|"Access"| USER2 USER1 -->|"Execute"| RA USER2 -->|"Execute"| RA end style R fill:#2678BD,color:#fff style MV fill:#9E59BB,color:#fff style BPM fill:#9E59BB,color:#fff style RA fill:#E47528,color:#fff

Resources (blue) serve both operational monitoring and business visualization: the purple Monitor View and BPM are the two perspectives, connected through Services in the Repository Model, and both lead to the same orange Remote Actions.

Resource Relationships and Cardinality

The diagram below shows the structural relationships and cardinality between the core entities in Nodinite's monitoring model:

erDiagram MONITORING_AGENT { string name string type } RESOURCE { string name string status string description } CATEGORY { string name } APPLICATION { string fullPath } APPLICATION_SEGMENT { string segmentName int level } MONITORING_AGENT ||--o{ RESOURCE : "1 to 0 or more" RESOURCE }|--|| CATEGORY : "many to exactly 1" RESOURCE }o--o| APPLICATION : "many to 0 or 1" APPLICATION ||--|{ APPLICATION_SEGMENT : "1 to 1 or more" APPLICATION_SEGMENT ||--o{ APPLICATION_SEGMENT : "1 to 0 or more"

One Agent discovers zero or more Resources. Every Resource belongs to exactly one Category. An Application path such as Subscription / Resource Group / App Name is split by Mapify into a virtual hierarchy of Application Segments—enabling grouped navigation without changing the underlying data.

Key Cardinality Rules

Relationship Cardinality Rule
Monitoring Agent → Resource 0..* One Agent produces zero or more Resources
Resource → Category 0..1 Each Resource usually belongs to exactly one Category
Resource → Application 0..1 A Resource usually belongs to exactly one Application
Application → Application Segment 1..* An Application path produces one or more Segments
Application Segment → Application Segment 0..* A Segment contains zero or more child Segments

Application Path Grouping Example

A Logic App Resource named OrderProcessor with Application set to Production Subscription / Integration RG and Category set to Logic App produces two virtual Application Segments in Mapify:

Production Subscription          (level 0 – root)
  └── Integration RG             (level 1)
        └── OrderProcessor       ← Resource Name (Category: Logic App)

The Resource itself (OrderProcessor) is not part of the Application path — the Application field contains only the grouping hierarchy (Production Subscription / Integration RG). Mapify splits that string on / to build the virtual tree, then places the Resource as a leaf node beneath its deepest segment.

Resource States

The actual Resource has one of the following states at any given moment, which represents its evaluated condition:

State Description
✅ OK Online - All's well; The Resource is operational
⚠️ Warning Warning state raised - One or more minor problems are detected
❌ Error Error state raised - One or more major problems are detected
🚫 Unavailable Resource not available - Used to indicate an error/fatal condition usually since the Monitoring Agent Configuration or resource unavailable or can't be reached from the Monitoring Agent. Also, some Monitoring Agents use this state to indicate bad configuration, or inability to evaluate the Resource
🚫 Connection Error Monitoring Service fails to communicate with the Monitoring Agent - Service is offline (server is shutdown/rebooting), connectivity issues (bad network), invalid Monitoring Agents configuration, or invalid Remote Configuration

How a Resource Changes State

stateDiagram-v2 [*] --> OK: Agent reports healthy OK --> Warning: Minor problem detected OK --> Error: Major problem detected Warning --> Error: Problem gets worse Warning --> OK: Problem resolved Error --> OK: Fixed manually or by Auto Healing OK --> Unavailable: Resource cannot be reached or evaluated Unavailable --> OK: Resource reachable again OK --> ConnectionError: Monitoring Service loses contact with the agent ConnectionError --> OK: Agent reachable again state "Connection Error" as ConnectionError classDef ok fill:#93d16d,color:#000 classDef warning fill:#FFD525,color:#000 classDef error fill:#c33d34,color:#fff classDef unavailable fill:#D5396D,color:#fff classDef connection fill:#9E59BB,color:#fff class OK ok class Warning warning class Error error class Unavailable unavailable class ConnectionError connection

Typical state transitions for a Resource: green OK, yellow Warning, red Error, pink Unavailable (the agent cannot reach or evaluate the Resource), and purple Connection Error (the Monitoring Service cannot reach the agent). Any state can move to any other; the diagram shows the common paths. Expected State can change how a reported state is evaluated, and Auto Healing can run Remote Actions to bring a Resource back to OK.

Severity Order

When several Resources must be summed up as one state, the highest of their status codes wins. Resource lists use the same rule as a sort: they sort by status code, descending, so the most severe state comes first:

  1. Connection Error (4)
  2. Unavailable (3)
  3. Error (2)
  4. Warning (1)
  5. OK (0)

That is: Connection Error, then Unavailable, then Error, then Warning, then OK. The status-code bar chart directly under the filters in a Monitor View stacks the states in this same order, with the same colors across Monitor Views and dashboards. The lightbulb on a Service in a BPM follows the same "highest status code wins" rule for its Resources; see BPM Integrated Monitoring.

Monitor View Live Monitor tab with the status-code bar chart under the filters, showing Error (3), Warning (3), and OK (16) of 22 Resources (7.10)
The bar chart lists the states in severity order with the count of Resources in each and the total to the right.

Examples

Here are real-world Resources from different monitoring scenarios, showing how the status indicators appear in the Resources list:

Resources Overview list filtered on azure, showing Resources in Error, Warning, and OK state
Each row shows the Resource with its Monitoring Agent, Category, and Application; the row color and icon show the state.

The following properties are available on a Resource:

Property Description
Name The name of the Resource
Description The user-friendly description about the Resource
Web Site Provides the ability for a link to additional external documentation
Monitoring Agent Configuration The name of the Monitoring Agent Configuration the Resource origins from
Application The name of the Application
Category The name of the Category

Expected State

Use the dedicated Expected State feature page to learn how to:

  • Override state evaluation for planned maintenance and known issues
  • Document each override with clear operational context
  • Interpret visual indicators when real and expected states differ

Pair this with Auto Healing when you want automated remediation through Remote Actions.

Note

The LogText should not change over time for a resource that do not change its state. This is due to the caching mechanism trying to conserve bandwidth and costs when using service bus relaying.

State / Status Code values

Internally within Nodinite the following Status Code values are being used:

State Status Code values
✅ OK 0
⚠️ Warning 1
❌ Error 2
🚫 Unavailable 3
🚫 Connection Error 4

Next Steps

Add or manage Resource
Add or manage Monitor View
Services - Understand how Resources connect to BPM
Business Process Models (BPM) - See Resources in business context

Resource Organization

Monitoring and Actions

BPM Integration

Security