Repository Model: Living Integration Intelligence
Integration landscapes are vast, complex, and constantly changing. Teams struggle to answer basic questions: How many integrations do we have? Which systems are connected? Who owns each integration? What happens when something breaks? Without accurate documentation, teams face:
- Stale documentation: Visio diagrams, Word documents, and spreadsheets drift from reality within weeks
- Discovery paralysis: Nobody can quickly find which integrations touch a specific system or business process
- Slow incident response: Responders waste minutes hunting for owners, SLAs, and dependency maps
- Knowledge silos: Critical integration knowledge lives in people's heads and leaves with them
- Disconnected tools: Documentation lives apart from logging, monitoring, and incident management
The Nodinite Repository Model turns integration documentation from a static burden into living, actionable intelligence. It's a CMDB-inspired database for integrations that stays current through logging, feeds your operational views and alerts, and answers questions when teams need them most.
- ✅ Interactive Integration Landscape - Explore your whole portfolio visually; no competitor offers this
- ✅ A CMDB built for integrations - Purpose-built for message flows, not generic IT assets
- ✅ Living documentation - Auto-populates from Log Events through Context Options
- ✅ Operational intelligence - Embedded in Log Views, Monitor Views, Alarm Plugins, and BPM
- ✅ Automation-native - Create, update, and query every entity through the Web API
- ✅ Unlimited metadata - Enrich any entity with Custom Metadata, no rigid schemas
- ✅ Multi-persona - Serves business users, architects, developers, and operations teams
- ✅ Zero marginal cost - Create unlimited Repository entries at no extra licensing cost
The Integration Landscape builds itself as you log events with Context Options, and you can sculpt it by hand or through the Web API.
Understanding the Repository Model
The Repository Model documents what integrates, who participates, how they connect, and where messages travel. An Integration is the root object; it groups the Services that connect Systems. Each Service holds Transport Contracts, the log points that combine Message Types and Endpoints. With the BPM or Mapify license, Domains and BPMs add the business-process view on top.
Relationships between the Repository Model entities: blue nodes are core entities included with the Repository; purple nodes need the BPM license (Domains: the BPM or Mapify license). The Integration Landscape draws exactly these relations.
The Integration CMDB Hierarchy
Each entity answers one question about your landscape. The entity pages link back here for the full chain.
| Level | Entity | Answers | Example |
|---|---|---|---|
| 1 | Integrations | What business scenario is implemented? | Order-to-Cash |
| 2 | Systems | Who participates? | SAP, BizTalk, Dynamics 365 |
| 3 | Services | How do participants connect, and in which direction? | SAP.SVC001 - Send Orders |
| 4 | Transport Contracts | Which log points belong to the Service? | Message Type + Endpoint combinations |
| 5 | Message Types | What format is exchanged? | http://SAP.Order/2.0#Order |
| 6 | Endpoints | Where do messages physically travel? | https://sap.company.com/orders |
The Logging Service matches the Message Type and Endpoint of every logged event against the Transport Contracts, so each event is tied to its Service, System, and Integration.
Who Contributes to the Repository
Formal and informal) roPL(Project Management
ICC/Service Owner) roArch(Enterprise/Solutions
Architects) roDeveloper(Developers) roTest(Testers) roITOPS(IT Operations) roAM(Application
Management) roBusinessDemands --- roPL roPL --- roArch roArch --- roDeveloper roDeveloper --- roTest roTest --- roITOPS roITOPS --- roAM end roRepository(fa:fa-sitemap Repository) roBusinessDemands --- roRepository roPL --- roRepository roArch --- roRepository roDeveloper --- roRepository roTest --- roRepository roITOPS --- roRepository roAM --- roRepository
The Repository Model captures knowledge from across your organization, from business requirements through development, testing, operations, and application management.
Tip
When everyone contributes, everyone benefits. Business analysts document requirements, architects define integration patterns, developers pass Context Options while logging, and operations teams add SLAs and contacts. Institutional knowledge stays in the Repository, not in people's heads.
Repository Model Building Blocks
Each building block has a concept page (what it is and why it matters) and a Web Client user guide (how to work with it).
The Repository Model entities as they appear in the Nodinite Web Client.
Core Entities
| Entity | Documents | Web Client User Guide | Add or Manage | |
|---|---|---|---|---|
| Integrations | Business scenarios, the root object | Integrations Overview | Add or manage Integration | |
| Systems | Participants: applications, partners, platforms | System Overview | Add or manage System | |
| Services | Connection points with direction and Transport Contracts | Service Overview | Add or manage Service | |
| Endpoints | Physical transport channels (URI, protocol, direction) | Endpoints Overview | Add or manage Endpoint | |
| Message Types | Message formats; the binding point for Search Fields | Message Type Overview | Add or manage Message Types |
Enrichment and Knowledge
| Building block | Documents | Web Client User Guide | Add or Manage | |
|---|---|---|---|---|
| Custom Metadata | Owners, SLAs, environments, and any business context | Custom Metadata Overview | Add or manage Custom Metadata | |
| Custom Fields | Reusable field definitions (prefer Custom Metadata for new work) | Custom Fields Overview | Add or manage Custom Field | |
| Knowledge base Articles | Operator instructions and technical documentation | Articles Overview | Add or manage Article | |
| Images | A shared Image Library for Articles and Custom Metadata | Images Overview | ||
| Files | A shared File Library for non-image assets | Files Overview |
Process and Architecture Modeling (Mapify and BPM Licenses)
| Building block | Documents | License | Web Client User Guide | |
|---|---|---|---|---|
| BPMs | Business processes as swimlanes of Domains, steps, and Services | BPM | BPM Overview | |
| Domains | Organizational boundaries: BPM swimlanes and map boundaries | BPM or Mapify | Domains Overview | |
| C4 Diagrams | Standards-based architecture views bound to live Repository entities | Mapify | C4 Diagrams Overview | |
| Component Types | Icons and categories for C4 and Mapify shapes | Mapify | Component Types Overview |
See License Options and Feature Matrix for exactly what each license includes.
Repository Data in Daily Operations
The Repository Model isn't a documentation silo. Its data appears wherever your teams work:
- Integration Landscape - Click any System, Service, or Integration to see its relations, logs, and monitoring state
- Log Views - Filter log events by Integration, System, Service, Message Type, or Endpoint; a log event's Repository Model tab shows the Custom Metadata of its Message Type, End Point, Services, and Contracts
- Monitor Views - Show operational status next to the documentation context
- Alarm Plugins - Include owner, SLA, and affected integrations in every alert; use the HTTP Webhook plugin to open tickets in ITSM tools such as ServiceNow or Jira
- BPM - Plot the logged events of one transaction onto Domain swimlanes
- Reports - Build governance and compliance reports on Repository data through the Web API
Faster Incident Response
When an integration fails at 2 AM, responders get the context with the alert instead of searching wikis: affected Systems, the responsible team, the SLA, and the dependent Integrations. Attach runbooks as Knowledge base Articles so the fix is one click away.
Automation-First Documentation
- Web API - Create, update, and query every Repository entity from scripts and DevOps pipelines
- Context Options - Pass Repository context with each Log Event so the Repository builds itself as systems run
- Generate C4 Diagram Sets - Turn the Integration Landscape into architecture diagrams
Common Challenges the Repository Model Solves
| Challenge | How the Repository Model solves it | Learn more |
|---|---|---|
| Stale documentation | The Integration Landscape auto-populates from logged events; manual updates enhance it but aren't required | Context Options |
| "Which integrations touch this system?" | Open the System to see every Integration, Service, and Endpoint that depends on it | Systems |
| Slow, chaotic incident response | Alerts carry owner, SLA, and dependency metadata from the Repository | Custom Metadata |
| Knowledge walks out the door | Entities carry Custom Metadata and linked Knowledge base Articles | Articles |
| Governance and compliance gaps | Record owners and compliance tags with Custom Metadata, and report on data flows through the Web API | Reports |
Licensing
The core Repository Model (Integrations, Systems, Services, Endpoints, Message Types, Custom Metadata, Custom Fields, Articles, Images, and Files) is part of every license. BPMs need the BPM license; C4 Diagrams and Component Types need the Mapify license; Domains are available with either. See License Options and Feature Matrix.
Next Steps
- Add or manage Integration - Start documenting your integration landscape
- Add or manage System - Define the systems in your architecture
- Add or manage Service - Connect Systems through Services
- Integration Landscape - Explore your Repository visually
- Creating Your First C4 Diagram - Or import one instead
Related Topics
- Integrations - The root object of the Repository Model
- Systems - Participants in your integrations
- Services - Connection points with Transport Contracts
- Endpoints - Physical transport channels
- Message Types - Message formats and Search Field binding
- Custom Metadata - Add business context to any entity
- Custom Fields - Reusable custom field definitions
- Articles - Knowledge base for operators and developers
- Images - Shared Image Library
- Files - Shared File Library
- BPM - Business Process Models
- Domains - Organizational boundaries for BPM and maps
- Architecture Diagrams - C4 diagram sets bound to Repository entities
- What is C4 Diagrams - C4 levels and how they map to Repository concepts
- Component Types - Icons for C4 and Mapify
- License Options and Feature Matrix - What each license includes
- Mapify - Interactive and static relation views
- Logging Service - Ties logged events to Repository entities
- Log Event - Include Repository context when logging