- 5 minutes to read

Custom Connector for Mule ESB Logging

The Nodinite Custom Connector gives your Mule ESB 3.6–3.9 flows centralized, structured logging. It replaces the standard Logger and Business Events components with one reusable logging subflow that writes JSON Log Events, with the full message body, to a queue, a table, or a folder. The Pickup Service then brings them to Nodinite, where business users search them in Log Views.

  • ✅ Logs the full message body and structured context, not only text lines
  • ✅ One logging subflow: change it once, and every flow follows
  • ✅ Same approach on-premise and in the cloud, without code changes
  • ✅ Retention per Message Type, and business data you can search

Understanding Mule ESB Logging with Nodinite

Mule ESB has built-in logging options (Logger, Business Events), but they have significant limitations for enterprise integration:

Feature Logger Business Events Nodinite Custom Connector
Cost ✅ Free (built-in) ❌ Requires Enterprise Edition ✅ Free template, requires Nodinite license
Payload Logging ⚠️ Limited to log level filtering ❌ Cannot log message body ✅ Always logs full message body
Context Properties ⚠️ Manual implementation ⚠️ Key/value pairs only (no payload) ✅ Structured context with full payload
On-Premise/Cloud ❌ Different configurations required ❌ Different configurations required ✅ Unified approach - no code changes when migrating
Data Visibility ❌ File-based logs, 12+ hour delays in cloud ⚠️ Real-time tracking UI ✅ Async pickup, fast visibility (minutes)
Consistency ❌ Inconsistent quality across flows ⚠️ Limited metadata ✅ Enforced structure via JSON schema
Maintenance ❌ Requires log rotation/management ⚠️ Requires data retention policies ✅ Centralized log database management
Replacement Effort ❌ Hardcoded, difficult to change ❌ Hardcoded, difficult to change ✅ Single subflow change updates all flows
Retention Control ❌ File/folder-based deletion only ❌ Global retention policies ✅ Message Type-based retention - fine-tune by business data type

Architecture: How the Custom Connector Works

graph LR subgraph Mule ESB Server subgraph Integration Flows roFlow1(fa:fa-sitemap INT001: Invoices) roFlow2(fa:fa-sitemap INT002: Exchange rates) end subgraph Logging Subflow roFlow1 --> roLogSink roFlow2 --> roLogSink roLogSink("fa:fa-bolt Nodinite Custom Connector") --> roDest["fa:fa-list ActiveMQ Queue
fa:fa-database PostgreSQL Table
fa:fa-folder File Folder"] end end subgraph Nodinite Server roLogAPI(fa:fa-cloud-arrow-down Log API) roPS(fa:fa-truck-pickup Pickup Service)--> roLogAPI roDest -.->|"Async pickup"| roPS end

Architecture: Mule ESB flows invoke the Custom Connector subflow, which formats JSON Log Events and posts them to a configured destination (queue, database, or folder). The Pickup Service asynchronously fetches the events and forwards them to the Log API.

Key Components

Component Role Technology Options
Custom Connector Formats Mule message as JSON Log Event JAR package (Anypoint Studio 6/7)
Logging Subflow Centralizes logging logic for reuse Single Mule subflow invoked by all flows
Destination Temporary storage for async pickup ActiveMQ (recommended), PostgreSQL, File, AnypointMQ, Log API (dev only)
Pickup Service Fetches events and forwards to Log API Pickup Log Events Service Logging Agent
Log API Persists events to Log Database Nodinite Core Services component

Why Asynchronous Logging?

Asynchronous logging (via queue or database) is strongly recommended for production environments because:

  • Non-blocking: Flow execution continues without waiting for log persistence
  • Resilience: Destination outages don't block integration flows
  • Scalability: Queue-based pickup handles high-volume bursts
  • Performance: No synchronous HTTP calls from Mule flows

Destination Options

Destination Pros Cons Recommendation
Log API (Synchronous) Simple setup, no middleware required Not highly available, blocks flows, doesn't scale ⚠️ Development/POC only - avoid in production
ActiveMQ Free (Open Source), scales well, supports clustering, fail-over capability Requires ActiveMQ installation and configuration ✅ Recommended for production
PostgreSQL Scales well, uses existing database infrastructure Requires table creation and polling configuration ✅ Good alternative if ActiveMQ unavailable
AnypointMQ Cloud-native, highly available, scales automatically Requires MuleSoft Enterprise subscription, higher cost ❌ Contact support - not yet supported by Pickup Service
File Folder Simple for single-server scenarios No fail-over, requires file system monitoring ⚠️ Small deployments only

Implementation Guide

The implementation is split into three pages:

Page What it covers
Implement the Custom Connector Prerequisites, then six steps: download the connector, add it to Anypoint Studio 6 or 7, create the logging subflow, invoke it from your flows, configure the Pickup Service, and verify the logging
Complete Working Example One Mule configuration with the connector, the ActiveMQ connection, the logging subflow, and a flow that logs at receive, success, and error
Log Event Content The mandatory and optional JSON Log Event fields, Message Types and their naming, Context Options, repair and resubmit properties, exception handling with Log Status Codes, and correlation

Mule ESB flow with logging at receive, before processing, and after processing
A Mule ESB flow that calls the logging subflow at each milestone; see Implement the Custom Connector.

Log Views and Self-Service

Create role-based Log Views to empower business users:

  1. Finance Team - search by invoiceNumber, customerId, invoiceAmount
  2. Operations Team - search by orderId, shipmentId, warehouse
  3. Support Team - search by errorType, customerComplaint, ticketNumber

This reduces incidents by enabling self-service troubleshooting. The values become searchable through Search Fields bound to your Message Types.

Best Practices Summary

  • Start small - implement in 2-3 flows before rolling out organization-wide
  • Use ActiveMQ for production (best scalability and fail-over)
  • Plan Message Types during development - they cannot be changed after logging; see Log Event Content
  • Create Search Field Expressions for each Message Type before go-live
  • Log at key milestones - receive, transform, send, error
  • Use meaningful Log Text - help users understand what happened
  • Add context properties - enable business-level searching and filtering
  • Implement correlation - link related events across flows and systems; see Mule ESB Correlation
  • Test pickup service - verify events reach Nodinite Web Client
  • Create Log Views - empower business users with self-service access

Next Steps

Implement the Custom Connector
Complete Working Example
Log Event Content
Add or manage Search Fields
Add or manage Log Views
Pickup Log Events Service

Logging
Log Events
Message Types
Search Fields
Log Views
JSON Log Event
Log API
Asynchronous Logging
Mule ESB Correlation
Logger
Business Events