Endpoints

System Integration Solutions typically communicate by sending messages over a physical transport medium as part of a conversation. Participants agree on the protocol and security policies to use. Information about these transport channels is managed in Nodinite as Endpoints.

Understanding Endpoints: The Physical Transport Layer

An Endpoint identifies the physical location and protocol where messages are sent from or received to. Think of Endpoints as the "where" and "how physically" in your integration architecture:

• Integrations document "what" (business scenarios like "Order-to-Cash")
• Systems identify "who" (participants like SAP, BizTalk, Dynamics 365)
• Services define "how logically" (connection mechanisms with direction and contracts)
• Message Types specify "format" (message structures like XML invoices, JSON orders)
• Endpoints pinpoint "where physically" and "how technically" (HTTPS URLs, file paths, queue names with their protocols)

Why Endpoints Matter

Endpoints capture the technical reality of your integration landscape:

✅ Compliance and Security: Document which protocols and transport channels handle sensitive data
✅ Troubleshooting: Identify exactly which URL, file path, or queue experienced issues
✅ Traffic Analysis: See which Endpoints handle the most messages using built-in statistics
✅ Change Management: When infrastructure changes (new URLs, moved file shares), identify affected Integrations
✅ Multi-Environment Management: Same Service across Dev/Test/Prod uses different Endpoints—track them all

Without Endpoints, you'd know Systems communicate but not where physically—making troubleshooting, compliance, and operational management nearly impossible.

Examples of Endpoints

• https://api.company.com/orders/v2 - REST API endpoint (HTTPS protocol)
• C:\Integrations\Outbound\Orders\*.xml - File system path (FILE protocol)
• msmq://localhost/private$/invoices - MSMQ queue (MSMQ protocol)
• sftp://vendor.com:22/inbound/ - SFTP server location (SFTP protocol)
• sb://company.servicebus.windows.net/orders - Azure Service Bus queue (Service Bus protocol)
• soap+https://sap.internal:8000/OrderService - SOAP web service (SOAP/HTTPS protocol)

Example list of Endpoints filtered by the Nodinite BizTalk Server Log Agent—showing Name, URI, Direction, Endpoint Type, and Last Activity.

All Nodinite Log Events include mandatory and essential information about the Endpoint. This is crucial for documentation and for understanding your Systems Integration Solutions within your service portfolio.

Tip

Notice the last column; it provides information about the last known logged event.

An Endpoint must have a user-friendly name and an address (URI). Endpoints are unique in their composition of the following fields:

• Name – The name of the Endpoint. This should be user-friendly.
• URI – The address of the Endpoint. This is the actual address used on the wire.
• Direction – The direction for the Endpoint. Is this an inbound or outbound message?
• Endpoint Type – The type of Endpoint. How is the information sent on the wire? Which protocol is used?
• Log Agent – Information about the source for this Endpoint. What is the ID?

Here's an example of a BizTalk Server Endpoint with additional tracking information provided.

How Endpoints Fit into the Integration CMDB

Endpoints represent the lowest, most granular layer in Nodinite's integration CMDB—the physical implementation details that make integrations real:

CMDB Hierarchy:

1. Integrations (Business Scenario) - "Order-to-Cash integration"
2. Systems (Participants) - "SAP sends to BizTalk which sends to Dynamics 365"
3. Services (Connection Points) - "SAP.SVC001-Send-Orders" has direction and contracts
4. Transport Contracts (Log Points) - Combination of Message Types + Endpoints
5. Message Types (Formats) - "SAP.Order.v2" identifies structure
6. Endpoints (Physical Channels) - https://sap.company.com:8000/orders specifies actual location

Endpoints in Transport Contracts: Half of the Log Point Definition

Endpoints are critical components of Transport Contracts within Services. A Transport Contract defines a log point—a specific, observable event in your integration landscape. Each log point requires TWO pieces:

• Message Type - "What format?" (XML invoice, JSON order, EDIFACT shipment)
• Endpoint - "Where physically?" (HTTPS URL, file path, queue name)

Together they form a complete log point:

• Message Type: http://SAP.Invoice/1.0 + Endpoint: https://sap.internal:8000/invoices = "SAP XML invoices sent via this HTTPS endpoint"
• Message Type: Orders/1.0#Order + Endpoint: C:\Integrations\Orders\*.xml = "Order XML files in this file system location"

Why this matters: When the Logging Service processes a logged event, it matches the Message Type + Endpoint combination against Transport Contracts to determine which Integration, System, and Service the message belongs to. Without accurate Endpoints, message correlation fails.

CMDB Capabilities Enabled by Endpoints

✅ Compliance Tracking: Document which URLs, file paths, and queues handle regulated data
✅ Change Management: When infrastructure changes (new IPs, moved file shares, renamed queues), identify all affected Services and Integrations
✅ Multi-Environment Management: Track Dev/Test/Prod variations of the same logical Service (different Endpoints)
✅ Protocol Governance: Verify approved protocols are used (enforce HTTPS over HTTP, SFTP over FTP)
✅ Traffic Analysis: See which physical channels handle the most messages using built-in statistics
✅ Troubleshooting: Pinpoint exact URLs or paths experiencing connectivity or permission issues

Repository

End-users with sufficient permissions manage the Nodinite Repository Model and assign relationships between Services and Contracts.

An example follows:

1. Service A in the source System creates a message (file) and writes it to the file system.
2. Service B in the destination System reads the message using the SFTP protocol.

Furthermore, an Endpoint can be part of a Transport Contract (log point) in Services and Contracts.

Custom Metadata

As with all entities in the Nodinite Repository Model, an Endpoint can have any number of Custom Metadata fields assigned.

Custom Fields

Similarly, an Endpoint can have any number of Custom Fields assigned.

Origin of Endpoints: Auto-Creation from Logging

One of Endpoints' most powerful features is automatic creation from logged events—you don't manually enter Endpoints; they populate themselves as integrations run. This is "living documentation" in action.

How Auto-Creation Works

1. Integration Runs: A message is sent via an endpoint (HTTPS URL, file path, queue, etc.)
2. Logging Occurs: Log Agents capture the event and send it to the Log API
3. Logging Service Processes: The Logging Service extracts Endpoint information (Name, URI, Direction, Endpoint Type, Log Agent)
4. Endpoint Auto-Created: If no matching Endpoint exists, Nodinite creates one automatically
5. Repository Populates: Endpoint appears in Endpoints Overview and becomes available for Transport Contracts

The benefit: Your Endpoint catalog builds itself from operational reality. No manual data entry. No stale documentation. The Repository reflects what's actually running in production.

Special BizTalk Server Support

Nodinite provides enhanced auto-creation capabilities for BizTalk Server:

• Passthru Pipeline Handling: When BizTalk uses Passthru pipelines (no XML validation), Nodinite queries BizTalkMgmtDB to determine Endpoint Type
• XML Namespace Extraction: For XML messages, extracts Target Namespace + root element to populate Message Type
• EDIFACT UNA Field: For EDI messages, extracts UNA field to determine Message Type
• JSON Schema Detection: For JSON payloads, identifies schema property for Message Type

This intelligent extraction ensures Endpoints and Message Types are accurately identified even when BizTalk's processing is format-agnostic.

Logging Sources

Endpoints originate from the process of logging. Sources include:

• Log Agents - Nodinite logging agents for various platforms (BizTalk, IBM Integration Bus, Azure Logic Apps, etc.)
• Log API - Direct API calls from custom applications and services
• Asynchronous Logging - High-volume, queue-based logging for performance-critical scenarios

All logged messages are processed by the Logging Service. During processing, the Endpoint is extracted, validated against existing Endpoints using the 5-field unique composition, and either matched or auto-created.

Info

Nodinite Messages (Log Event) must include information about the Endpoint (and the Message Type).

Built-In Traffic Statistics: Understanding Endpoint Usage

Nodinite provides persistent, built-in statistics about Endpoints—a powerful feature for understanding traffic patterns, identifying issues, and planning capacity. No additional configuration required; statistics are automatically collected as messages flow.

What Statistics Reveal

Message Type Distribution: All Message Types recorded on each Endpoint are listed with counts. This answers critical questions:

• "What formats does this Endpoint handle?" (XML invoices, JSON orders, EDIFACT shipments)
• "Is this Endpoint being used as designed?" (unexpected Message Types indicate misconfiguration)
• "Which format dominates traffic?" (plan schema optimization efforts)

Traffic Volume Analysis: See total message counts per Endpoint:

• Identify high-traffic Endpoints for performance optimization and capacity planning
• Detect low-traffic Endpoints that might be candidates for consolidation or retirement
• Spot unexpected spikes indicating integration issues or business changes

Multi-Format Endpoints: When one physical Endpoint handles multiple Message Types (common with shared mailboxes, multi-purpose APIs, or generic file shares), statistics show the format distribution—helping you understand whether consolidation is effective or creating complexity.

Traffic statistics showing Message Type distribution for a selected Endpoint—revealing format variety and message volumes.

Business Value of Endpoint Statistics

✅ Capacity Planning: Identify Endpoints nearing limits before outages occur
✅ Cost Optimization: Find underutilized Endpoints for consolidation
✅ Integration Health: Detect format mismatches or unexpected message types
✅ Compliance Reporting: Document traffic volumes for auditors
✅ Change Impact: Before modifying an Endpoint, understand usage patterns

These statistics are always current, reflecting real operational data—not manual estimates or outdated capacity plans.

Endpoints in Operational Systems

Endpoints aren't just technical documentation—they're embedded throughout Nodinite's operational features providing context and enabling precise filtering:

In Logging

Filter log events by Endpoint to troubleshoot specific transport channels:

• "Show me all messages sent to https://api.vendor.com/orders"
• "Which Endpoints had connection failures in the last hour?"
• "Compare message volumes: Endpoint A vs Endpoint B this month"
• Endpoint context appears in every log event enabling precise troubleshooting

In Transport Contracts

Endpoints combine with Message Types in Services to define log points:

• Transport Contract: "XML invoices on HTTPS Endpoint X" = specific, filterable log point
• Same Service can have multiple Transport Contracts for different Endpoint/format combinations
• Changing an Endpoint in a Transport Contract automatically updates which messages correlate to that Service

In the Interactive Integration Landscape

While Endpoints don't appear directly in the visual landscape (Services and Systems do), their impact is everywhere:

• Services with Transport Contracts show traffic indicators driven by Endpoint statistics
• Clicking a Service reveals its Transport Contracts including Endpoints
• Endpoint health affects Service health which affects System health in the landscape hierarchy

In Alerting

Email and webhook alerts can include Endpoint context when errors occur:

• "Message failed at Endpoint sftp://vendor.com:22/inbound/—connection timeout"
• Custom Metadata attached to Endpoints (owner, criticality, escalation contact) can appear in alerts
• Alert routing can target Endpoint-specific contacts for infrastructure issues

This operational integration means Endpoints bridge physical infrastructure (URLs, paths, queues) to business context (Integrations, Services, Systems).

Who Uses Endpoints?

Different roles interact with Endpoints for different purposes:

Integration Architects: Design transport channel standards and protocols. Establish governance policies (HTTPS required, no FTP, approved URL patterns).

Solution Designers: Specify Endpoints in Transport Contracts within Services. Document which URLs, file paths, or queues are used for each integration scenario.

Developers: Configure logging to include accurate Endpoint information in Context Options. Ensure Endpoint Name, URI, Direction, and Endpoint Type are correctly populated for auto-creation.

Operations Teams: Monitor Endpoint health and connectivity. Use Endpoint statistics to identify traffic patterns and capacity issues. Troubleshoot transport-level failures (connection timeouts, permission errors, DNS issues).

Infrastructure Teams: Manage physical resources (web servers, file shares, message queues) represented by Endpoints. Coordinate changes to URLs, IPs, or paths with Integration teams using Endpoint documentation.

Security Teams: Audit which Endpoints handle sensitive data. Verify approved protocols are used. Track Endpoint changes for compliance reporting.

Network Teams: Troubleshoot connectivity issues identified through Endpoint monitoring. Verify firewall rules, DNS resolution, and routing for Endpoint URIs.

Next Step

Add or manage Endpoint (manage Endpoint catalog)
Endpoints Overview (view all Endpoints with statistics)
Learn about Services (Endpoints are part of Transport Contracts in Services)
Learn about Message Types (combine with Endpoints to form Transport Contracts)
Logging Service (processes messages and auto-creates Endpoints)

Related Topics

Understanding Repository Model Entities

Repository Model (complete integration CMDB overview)
Integrations (business scenarios using Endpoints)
Systems (participants owning Services with Endpoints)
Services (contain Transport Contracts combining Message Types + Endpoints)
Message Types (combine with Endpoints in Transport Contracts)

Managing Endpoints

Custom Metadata (add business context to Endpoints)
Custom Fields (legacy metadata approach)
Endpoint Direction (understanding inbound/outbound)
EndpointTypes (protocols: HTTP, FILE, MSMQ, SFTP, etc.)

Logging and Operational Features

Log API (send log events with Endpoint information)
Logging Service (processes events and auto-creates Endpoints)
Log Agents (logging sources providing Endpoint data)
Log Views (filter log events by Endpoint)
Asynchronous Logging (high-volume logging approach)