Integration

Gain full control of your system integration architecture with Nodinite's Integration Landscape. This page guides you to visually design, document, and manage integrations for robust governance, traceability, and operational excellence.

✅ Visually design and document integrations before implementation
✅ Map all dependencies and relationships for complete traceability
✅ Manage your service portfolio and prioritize based on real data
✅ Integrate seamlessly with Monitor Views and Log Views for end-to-end insight

Understanding Integration as the Root Object

An Integration serves as the root object in the Nodinite Repository Model—the highest-level entity that ties all other Repository entities together. Think of an Integration as a documented integration scenario answering: "What business capability or technical workflow are we implementing?"

What makes Integration the "root object"?

An Integration contains and references all other Repository entities:

• Systems - Which systems participate? (SAP, BizTalk, Dynamics 365)
• Services - How do they connect? (Service endpoints with direction and contracts)
• Transport Contracts - What gets logged? (Message Types + Endpoints combinations)
• Message Types - What formats are exchanged? (XML invoices, JSON orders, EDIFACT shipments)
• Endpoints - Where physically? (HTTPS URLs, file paths, MSMQ queues, SFTP servers)
• Custom Metadata - Business context (owner, SLA, priority, environment, approval status)

Without an Integration tying these entities together, you'd have isolated documentation: Systems without relationships, Services without context, Messages without business purpose. Integration is the glue that creates a cohesive integration CMDB.

Examples of Integration Scenarios

• "Order-to-Cash: SAP to Dynamics 365 via BizTalk"
• "Employee Onboarding: HR+ to Azure AD to Office 365"
• "Invoice Processing: Supplier Portal to BizTalk to SAP ERP"
• "Real-time Inventory Sync: MES ↔ WMS bidirectional"
• "Customer Master Data: Salesforce to SAP via Azure Logic Apps"

Design-First Integration Approach

Design your Nodinite Integration instance before you create the solution to:

• Share and communicate your proposed solution (design first, not document later)
• Ensure visibility of all dependencies and relationships upfront
• Manage service portfolio and plan or prioritize based on facts, not assumptions
• Meet architectural requirements set by your enterprise or solution architects—both formal and informal
• Validate implementation by comparing design vs actual logged events

The Design-First Workflow:

1. Create Integration - Document business scenario ("Order-to-Cash") before coding
2. Define Systems - Identify participants (source, destination, intermediaries)
3. Map Services - Connect Systems through Services showing direction
4. Specify Transport Contracts - Define Message Types and Endpoints for each Service
5. Add Custom Metadata - Capture owner, SLA, environments, approval status
6. Share with Stakeholders - Use Integration Landscape to visualize and gain approval
7. Implement - Developers build following documented design
8. Auto-Validate - Logged events populate landscape confirming design matches reality

This design-first approach prevents "build first, document never" chaos that costs integration teams months of retrofitting documentation.

The graphical representation, called Integration Landscape, illustrates the relationships between the different Nodinite Repository Model artifacts.

Here are some quick facts about the Nodinite Integration repository item:

✅ Each Integration has a unique name.
✅ You can create any number of (unique) Integrations.
✅ Organize your Integrations using unlimited Custom Metadata and Custom Fields.
✅ You can associate Integrations with Monitor Views.
✅ You can access Integration data from within Log Views.
✅ A well-defined Integration lets you easily apply relevant filters on Log Views.
✅ You can associate Systems containing Services and Contracts.

How Integrations Fit into the Integration CMDB

Integrations are the top layer in Nodinite's purpose-built integration CMDB (Configuration Management Database). Unlike generic IT CMDBs tracking servers and applications, Nodinite focuses specifically on integration relationships:

CMDB Hierarchy:

• Level 1: Integration (Business Scenario) - "What workflow are we implementing?"
• Level 2: Systems (Participants) - "Who is involved in this workflow?"
• Level 3: Services (Connection Points) - "How do participants connect?"
• Level 4: Transport Contracts (Log Points) - "What specific message exchanges occur?"
• Level 5: Message Types (Formats) - "What data structures are exchanged?"
• Level 6: Endpoints (Physical Channels) - "Where do messages physically travel?"

This hierarchy ensures completeness. You can't have orphaned Services (they belong to Integrations), you can't have undefined Transport Contracts (they reference specific Message Types and Endpoints), and you can't have Messages without context (they're tied to Integrations via Transport Contracts).

Integration CMDB Enables Key Capabilities

✅ Portfolio Management: See all integration scenarios across your enterprise catalog
✅ Dependency Mapping: Understand which Integrations share Systems, Services, or Endpoints
✅ Impact Analysis: When a System changes, see all affected Integrations instantly
✅ Service Reuse: Identify Services used across multiple Integrations for consolidation opportunities
✅ Living Documentation: Integrations auto-populate from logged events—documentation builds itself
✅ Operational Context: Integrations appear in log filters, monitor views, and alerts providing business context

The Integration as root object concept ensures your CMDB always has complete, traceable, operationally-integrated documentation.

Tip

You gain instant rewards that grow as you invest in the Repository! The more Integrations you document, the richer your operational context becomes across logging, monitoring, and alerting.

Use the Actions button in the Integrations Overview to quickly access related entities:
Animated example showing quick access to relations in the Nodinite Repository.

The Interactive Integration Landscape: A Truly Unique Feature

The Integration Landscape is Nodinite's signature capability—a visual, interactive, explorable representation of your integration portfolio. No competing product offers this capability.

What Makes the Integration Landscape Revolutionary

Visual Integration Design:

• Drag Systems onto the canvas to design Integrations before building them
• Connect Systems through Services showing direction and message flow
• Add Transport Contracts defining which Message Types and Endpoints are valid
• Share the visual diagram with architects, business stakeholders, and developers

Auto-Population from Logging:

• Integrations appear automatically when logged events include Context Options
• Systems "light up" when messages flow through them
• Services show traffic indicators and last-activity timestamps
• Living documentation: Landscape reflects reality without manual updates

Interactive Exploration:

• Click an Integration to see participating Systems, Services, and Transport Contracts
• Click a System to see all Integrations it participates in
• Click a Service to jump to log events for that Service's Transport Contracts
• Hover over connections to see which Services link Systems together

Operational Health Visibility:

• Integrations show health status when Services link to monitored Resources
• Color indicators (green/yellow/red) display real-time operational state
• Click through from landscape → Service → Resources → Monitor Views for deep-dive troubleshooting

The landscape makes Integrations tangible—not just database records, but visual, interactive architecture that anyone can understand.

Integrations in Operational Systems

Integrations aren't just design documentation—they're embedded throughout Nodinite's operational features:

In Logging

Filter log events by Integration to see messages for specific business scenarios:

• "Show me all log events for the Order-to-Cash Integration"
• "Which Integrations had errors in the last 24 hours?"
• "Compare message volumes across Integrations this month vs last month"
• Integration context appears in every log event (via Transport Contracts) providing business meaning

In Monitoring

Associate Integrations with Monitor Views for targeted operational visibility:

• Create a Monitor View showing health of all Services in the "Order-to-Cash" Integration
• Alert only when critical Integrations experience errors (prioritize by business impact)
• Dashboard widgets show Integration-level metrics (throughput, error rate, latency)

In Business Process Monitoring (BPM)

Integrations bridge technical implementations to business processes:

• A BPM diagram for "Order-to-Cash" references the Integration providing visibility into technical execution
• Business users see: "Order processing step implemented via Integration INT001"
• Clicking the BPM step navigates to the Integration Landscape showing Systems, Services, and current health
• Technical teams drill from BPM → Integration → Services → Log Events for end-to-end troubleshooting

In Alerting

Email and webhook alerts automatically include Integration context:

• "Integration Order-to-Cash failed: Message from SAP to BizTalk rejected"
• Custom Metadata attached to Integrations (owner, SLA, escalation contacts) appears in alert body
• Recipients immediately understand business impact without checking documentation
• Alert routing targets Integration owners based on Custom Metadata

This operational integration means Integrations serve quadruple duty: design documentation, operational filter, business context provider, and alert metadata source.

Manage Integrations

Explore how to work with Integrations using the Nodinite Web Client user guide in the Core Services section. Use the following user guides to work with Integrations:

• Integrations Overview
• Add or Manage Integration
• Working with the Integration Landscape

Custom Metadata

You can add any number of Custom Metadata fields to an Integration, just as you can with all entities in the Nodinite Repository Model.

Custom Fields

You can add any number of Custom Fields to an Integration, just as you can with all entities in the Nodinite Repository Model.

Who Uses Integrations?

Different roles interact with Integrations for different purposes:

Enterprise Architects: Design the integration portfolio at the highest level. Define which business capabilities require integrations and establish governance policies.

Solution Architects: Document integration scenarios before implementation. Use the Integration Landscape to share proposed solutions with stakeholders and gain approval.

Integration Developers: Implement Integrations following documented designs. Ensure logging includes Context Options that populate Integrations automatically for validation.

Operations Teams: Filter log events and monitor views by Integration for business-context troubleshooting. "Show me all errors in the Order-to-Cash Integration."

Business Analysts: Understand technical implementations supporting business processes. Use Integration Landscape to see which Systems participate in workflows like Order-to-Cash or Procure-to-Pay.

Support Teams: Receive alerts with Integration context identifying business impact. Route issues to the correct teams based on Integration ownership metadata.

Compliance Officers: Verify which Integrations handle regulated data. Use Custom Metadata to track GDPR, HIPAA, or industry-specific compliance requirements per Integration.

View Integration

From the Integration Landscape and the Integrations Overview, end-users can click a button to view the result:
Example of a populated Integration showing Systems, Services, Transport Contracts, and Custom Metadata.

Next Step

Integrations Overview (manage your integration catalog)
Add or manage Integration (create new integrations)
Integration Landscape (visualize and explore interactively)
Learn about Systems (Integration participants)
Learn about Services (how Integrations connect Systems)

Related Topics

Understanding Repository Model Entities

Repository Model (complete integration CMDB overview)
Systems (participants in Integrations)
Services (connection points between Systems)
Endpoints (physical transport channels)
Message Types (message format identification)
Transport Contracts (log point definitions in Services)

Managing Integrations

Custom Metadata (add business context to Integrations)
Custom Fields (legacy metadata approach)
Articles (attach documentation to Integrations)
Resources (operational health monitoring)

Operational Features

Log Views (filter log events by Integration)
Monitor Views (associate operational monitoring with Integrations)
Alarm Plugins (alerts include Integration context)