What is a Service?

Use Nodinite Services to document, govern, and integrate your enterprise systems with clarity and control. This page shows you how to map, manage, and automate every service endpoint in your integration landscape for robust SOA and seamless operations.

✅ Precisely document every service endpoint and its relationships
✅ Enable flexible SOA integration and robust governance
✅ Visualize and manage dependencies, direction, and contracts
✅ Empower your teams to automate, monitor, and evolve integrations with confidence

Understand SOA architecture to maximize the value of the Nodinite Repository Model.

Understanding Services in Your Integration Architecture

A Nodinite Service represents one end of a communication chain and, by definition, belongs to a Nodinite System. Think of Services as the "how" in your integration landscape:

• Systems identify who participates (SAP, BizTalk, Customer ABC)
• Services define how each System sends or receives messages (direction, contracts, endpoints)
• Integrations document what business scenarios connect Systems together

Services are the connection mechanism between Systems. Without Services, Systems would be isolated entities with no way to communicate. Services establish:

✅ Direction: Is this System sending, receiving, or both?
✅ Contracts: Which message formats and transport channels are valid?
✅ Ownership: Which System owns this service endpoint?
✅ Reusability: One Service can participate in multiple Integrations

Why Services Matter for SOA Governance

In Service-Oriented Architecture (SOA), Services represent business capabilities exposed as consumable endpoints. Nodinite Services align perfectly with SOA principles:

• Service Inventory Management: Catalog all service endpoints across your enterprise
• Service Versioning: Track multiple versions of the same service (v1, v2, v3)
• Service Reuse: Identify which Integrations consume each Service
• Service Impact Analysis: When a Service changes, see all affected Integrations instantly
• Service Portfolio Optimization: Identify redundant or underutilized Services for consolidation

Whether you're building microservices, REST APIs, SOAP web services, or message-based integrations, Services provide the governance layer that prevents chaos as your portfolio grows.

A Service in Nodinite has a unique name and includes these pre-defined properties:

• System – Acts as either the sending or receiving side of the communication chain

• Direction – Choose one of the following:

  • Send – Send one-way, such as to a file system
  • Receive – Receive one-way, such as from a file system
  • Two-way Receive – Act as a Web Service being called by a consumer (Request/Response)
  • Two-way Send – Act as a Consumer calling a Web Service, this is the outbound initiating call (Request/Response)
  • None – Not set, should be avoided
  • Unknown – Enough said...

    Review the Endpoint Directions user guide for related information about Endpoints.

• Transport Contracts (log points)

  • Endpoints – Define how the message is transmitted.
  • Message Types – Define the type of message payload (Order, Invoice, etc.).

• Enforce restrictions within Log Views by configuring the Service properly.

  • Always include the Endpoints and Message Types for Nodinite to dynamically determine which Integration the message exchange belongs to.

Name your Service for clarity and management:

• SVC001 – Receive Invoices from Customer A
• SVC002 – Send monthly salary to the bank

Tip

Include a unique identifier such as SVC001 to make it easier to filter and manage a large number of Services, simplifying administration.

This naming convention helps you understand and manage Services. The examples above include several information elements: the transport of messages (found in Endpoints), the type of message (the Message Types 'Invoice' and 'Salary'), the direction, and the source or destination (System such as 'Customer A' and 'Bank').

How Services Fit into the Integration CMDB

Services are a critical layer in Nodinite's purpose-built integration CMDB. They serve as the binding mechanism connecting Systems through Transport Contracts:

The Complete CMDB Chain:

1. Integrations (Root Object) - "Order-to-Cash integration"
2. Systems (Participants) - "SAP" sends to "BizTalk" which sends to "Dynamics 365"
3. Services (Connection Points) - "SAP.SVC001-Send Orders" connects to "BizTalk.SVC010-Receive Orders"
4. Transport Contracts (Log Points) - Combinations of Message Types + Endpoints defining what gets logged where
5. Message Types (Formats) - "SAP.Order.v2" identifies the payload structure
6. Endpoints (Physical Channels) - https://sap.company.com/orders specifies the transport location

Without Services, you'd have a gap: You'd know Systems communicate but not how they connect—which endpoints, which message formats, which direction. Services fill this critical gap.

Services Enable Key CMDB Capabilities

✅ Service Portfolio Management: See all Services across all Systems in one catalog
✅ Contract Validation: Verify Message Types and Endpoints are properly bound to Services
✅ Integration Design: Build Integrations by connecting Services between Systems
✅ Impact Analysis: When a Service changes, see all consuming Integrations
✅ Living Documentation: Services auto-populate from logged events (no manual entry needed)
✅ Operational Monitoring: Link Resources to Services showing real-time health in the landscape

This Services-centric architecture transforms integration documentation from static spreadsheets into a dynamic, queryable, operationally-integrated CMDB.

Custom Metadata

As with all entities in the Nodinite Repository Model, a Service can have any number of Custom Metadata fields assigned, supporting flexible documentation and governance.

Custom Fields

Similarly, a Service can have any number of Custom Fields assigned, enabling tailored information management for your integration landscape.

Resources

^{New 6.0}

The System Administrator can add one or more Resources from Monitoring and assign them to the Service. Doing so presents the Service with the Monitoring State (the most severe state is shown) in the Integration Landscape.

Sample screenshot of the Interactive Landscape feature.

To add a Resource, Edit the Service, then click Edit on the Resources panel.

Example of an empty configuration.

Next, select any number of Resources.

Example with a Resource tied to the Service.

With Nodinite 6.1, you can also add Custom Metadata to Resources.

Transport Contracts: The Heart of Service Definitions

Transport Contracts are where Services become actionable. A Transport Contract defines what gets logged where—combining Message Types (format identification) with Endpoints (physical transport channels) to create log points.

Understanding Log Points

Think of a log point as a specific, observable event in your integration landscape:

• Message Type answers: "What format is this message?" (XML invoice, JSON order, EDIFACT shipment)
• Endpoint answers: "Where is this message sent/received?" (HTTPS URL, file path, queue name)
• Together they answer: "What specific messages should appear in logs and be associated with this Service?"

Why this matters: Nodinite's Logging Service uses Transport Contracts to determine which Integration, System, and Service a logged message belongs to. Without Transport Contracts, logged events remain orphaned—visible but not associated with your documented architecture.

The power: When you view logs filtered by Service, you see only messages matching that Service's Transport Contracts. This enables precise troubleshooting and operational visibility.

Transport Contracts define one or more log points. A Transport Contract is always a combination of one or more Message Types and Endpoints.

Simple log point example

The most basic example is a single specific message (Message Type), such as an invoice, that is received or sent on a specific transport location (Endpoint).

Here, the Transport Contract is a single log point with one Message Type and one Endpoint.

When you create a New Service, the list of Transport Contracts is empty. You can create new Transport Contracts from the management page, or if you are a Nodinite administrator, you can more easily bind logged messages to the Service.

Shared Endpoint example

Suppose the actual endpoint in use is a shared endpoint, such as a shared mailbox (info@company.com). To separate different flows of information for end-users, you can create multiple Services with different sets of definitions for Transport Contracts, filtering on relevant combinations of Message Types and Endpoints.

Here, the Transport Contract is a single log point with two Message Types and one Endpoint.

Multiple Endpoints for the Same Message Type example

Now imagine the same message (Message Type) is distributed across many different Endpoints (for example, the old production environment and the new production environment).

Here, the Transport Contract is a single log point with one Message Type and two Endpoints.

Add, Edit, or Delete Transport Contracts.

Read more about managing Transport Contracts on this page.

Services in the Interactive Integration Landscape

The Integration Landscape is Nodinite's truly unique visual exploration feature—and Services are how you navigate from System to System. No competing product offers this capability:

Visual Service Navigation

• System View: Click a System in the landscape to see all its Services listed
• Service Details: Click a Service to see Transport Contracts, Message Types, Endpoints, and Custom Metadata
• Integration Flow: Services appear as connection points between Systems showing message flow direction
• Health Indicators: Services linked to Resources display real-time operational state (green/yellow/red)
• Click-Through to Logs: Click a Service and jump directly to log events for that Service's Transport Contracts

Living Service Documentation

The landscape makes Services come alive:

• Auto-Population: Services appear automatically when logged events include Context Options (no manual entry)
• Real-Time Updates: As messages flow, Services show traffic indicators and last-activity timestamps
• Design-First Option: Create Services before implementation, then watch them "light up" when logging begins
• Version Management: Maintain multiple Service versions (v1, v2, v3) showing migration progress

This visual, interactive approach transforms Services from abstract configuration into tangible, explorable integration architecture.

Services in Operational Systems

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

In Logging

When you view log events, Service information provides critical context:

• Filter by Service: "Show me all messages for Service SVC001-Receive-Orders"
• Transport Contract Matching: Logging Service compares Message Type + Endpoint to determine which Service logged the event
• Cross-Integration Search: Find all Services handling "Invoice" Message Types across all Systems
• Performance Analysis: Identify slow Services by analyzing log timestamps within Service boundaries

In Monitoring

Link Resources to Services to show operational health:

• A "SAP.Send-Orders" Service can link to CPU, memory, and network Resources monitoring the SAP server
• When viewing the Service in the Integration Landscape, see real-time health status
• Alerts include Service context: "Service SVC001 failed—linked Resource 'SAP-Database-CPU' at 98%"
• Monitor Views can filter by Services showing operational status of integration endpoints

In Business Process Monitoring (BPM)

^{New 6.0} Services bridge Repository entities to monitored Resources in BPM:

• A BPM step can reference a Service showing the integration activity that progresses the business process
• Services with linked Resources display operational state within the BPM diagram
• Business users see: "Order received via Service SVC001 (operational state: healthy)"
• Technical teams drill from BPM step → Service → Transport Contracts → Log Events for troubleshooting

In Alerting

Email and webhook alerts automatically include Service information:

• "Integration Order-to-Cash failed at Service BizTalk.SVC010-Receive-Orders"
• Custom Metadata attached to Services (owner, SLA, escalation contact) appears in alert body
• Recipients know exactly which Service failed without checking documentation
• Alert routing can target Service owners based on Custom Metadata

This operational integration means Services serve double duty: design-time architecture documentation AND runtime operational context.

Who Uses Services?

Different roles interact with Services for different purposes:

Integration Architects: Design service portfolios defining how Systems connect. Establish naming conventions and direction standards for enterprise-wide consistency.

Solution Designers: Map Integrations by connecting Services between Systems. Define Transport Contracts specifying which Message Types and Endpoints are valid for each Service.

Developers: Implement Services and ensure logging includes Context Options that populate Service information automatically. Configure Message Types and Endpoints in Transport Contracts for proper log correlation.

Operations Teams: Monitor Services showing operational health via linked Resources. Filter log events by Service to troubleshoot specific integration endpoints. Use Service-level alerts for targeted notifications.

SOA Governance Teams: Catalog all service endpoints across the enterprise. Identify redundant or underutilized Services for consolidation. Track Service versions and retirement schedules.

Business Analysts: Understand which Services enable business processes in BPM diagrams. See operational state of Services affecting critical business workflows.

Next Step

Add or manage Service
Add or manage System (Services belong to Systems)
Add or manage Endpoint (Endpoints are part of Transport Contracts)
Add or manage Message Types (Message Types are part of Transport Contracts)
Add or manage Integration (Integrations connect Services between Systems)
Integration Landscape (visualize Services connecting Systems)

Related Topics

Understanding Repository Model Entities

Repository Model (complete integration CMDB overview)
Systems (Services belong to Systems)
Integrations (root object connecting Services between Systems)
Message Types (format identification in Transport Contracts)
Endpoints (physical channels in Transport Contracts)
Endpoint Directions (understanding Send/Receive/Two-way patterns)

Managing Services

Custom Metadata (add business context to Services)
Custom Fields (legacy metadata approach)
Resources (link operational monitoring to Services)
Integration Landscape (visualize Services in interactive landscape)

Operational Features

Log Views (filter log events by Service)
Monitor Views (operational monitoring with Service context)
BPM (business process monitoring with Services)
Alarm Plugins (alerts include Service information)