Custom Connector: Log Event Content

The value of your Mule ESB logging depends on what each Log Event carries. This page is the field reference for the Nodinite Custom Connector: what goes into each JSON Log Event, and how to set Message Types, context properties, status codes, and correlation so business users can find their data.

• ✅ Know which fields are mandatory and which are recommended
• ✅ Plan Message Types before go-live; they can't be changed after logging
• ✅ Make errors, context, and correlation searchable

JSON Log Event Format

The Custom Connector formats Mule messages as JSON Log Events following the Nodinite schema. Understanding this format is critical for proper integration.

Mandatory Fields

The following fields are required for every logged event:

Field	Data Type	Description	Example Value
LogAgentValueId	number	ID of the Log Agent sending events	42
EndPointName	string	Name of Endpoint (transport description)	"INT101: Receive Invoices"
EndPointUri	string	URI/address of Endpoint	"file:///drop/invoices"
EndPointDirection	number	Direction: 0 (receive), 1 (send)	0
EndPointTypeId	number	Transport type ID	60 (File)
OriginalMessageTypeName	string	Message Type identifier	"Invoice#1.0"
LogDateTime	string	Timestamp in ISO 8601 UTC format	"2018-05-03T13:37:00.123Z"

Optional But Recommended Fields

Field	Data Type	Description	Example Value
Body	string	Message payload (base64-encoded if binary)	Full message content
CorrelationId	string	Correlation identifier for related events	GUID or business key
LogStatus	number	Status code: -1 (error), 0 (success), 1 (info)	0
LogText	string	Human-readable log message	"Invoice processed successfully"
ContextProperties	object	Key-value pairs for Context Options	{"orderId": "12345", "customer": "Contoso"}

See the JSON Log Event documentation for the complete schema and examples.

Message Types Configuration

Important

Message Types are mandatory and cannot be changed after logging. The OriginalMessageTypeName field determines which Search Field Expressions are applied to extract business data from logged events.

Why Message Types Matter

Many Nodinite features depend on well-defined Message Types:

1. Search Fields - Extract Order Numbers, Customer IDs, Invoice amounts, Transaction codes using Search Field Expressions bound to Message Types
2. Log Views - Filter and search logs by business identifiers (not just timestamps and correlation IDs)
3. Non-Events Monitoring - Track message volumes, detect missing messages, alert on pattern anomalies
4. Business Process Modeling (BPM) - Correlate transactions end-to-end across Mule flows and other integration platforms

Without proper Message Types

• Search Field extraction fails - no business data in search results
• Log Views can only filter by technical metadata
• Non-Events cannot detect missing invoices, orders, or payments
• BPM cannot correlate multi-step business processes

Naming Best Practices

Use consistent, meaningful Message Type names:

• Include domain and version: Invoice#1.0, Order#2.0
• Use PascalCase: CustomerUpdate#1.0 (not customer_update_v1)
• Version changes: Increment version when payload schema changes significantly
• Avoid generic names: Use SAPPurchaseOrder#1.0 instead of Message#1.0

Example: Setting Message Type in Mule flow

// Set Message Type in session variable before logging
sessionVars['nodiniteMessageTypeName'] = "Invoice#1.0";

Planning Message Types During Development

Message Types cannot be changed after events are logged. Plan your naming convention during development:

1. Identify message types in your integration flows (orders, invoices, confirmations, etc.)
2. Define naming convention for your organization
3. Create Search Field Expressions for each Message Type before go-live
4. Document Message Types in your integration design specifications

Context Options and Custom Properties

Context Options allow you to add custom key-value pairs to logged events for filtering, searching, and reporting.

Common Context Properties

Property	Purpose	Example Value
orderId	Business transaction identifier	"ORD-12345"
customerId	Customer/partner identifier	"CUST-98765"
fileName	Source file name	"invoices_2024-11-03.xml"
fileSize	File size in bytes	"524288"
invoiceAmount	Transaction amount	"1250.00"
currency	Currency code	"USD"
isGDPRData	Contains personal data flag	"true"

Example: Setting context properties in Groovy

sessionVars['nodiniteContextValues'] = [
    orderId: flowVars['orderId'],
    customerId: flowVars['customerId'],
    invoiceAmount: flowVars['amount'].toString(),
    currency: "USD",
    isGDPRData: "true"
];

Repair and Resubmit Properties

Use context properties to enable message repair and resubmission:

sessionVars['nodiniteContextValues'] = [
    orderId: flowVars['orderId'],
    // Repair/resubmit metadata
    originalEndpoint: "file:///drop/invoices",
    retryCount: flowVars['retryCount'].toString(),
    canResubmit: "true",
    resubmitEndpoint: "vm://reprocess-invoice"
];

Build your Mule flows to handle resubmitted messages (check retryCount, implement idempotency, etc.).

Exception Handling and Error Logging

Add the Custom Connector to exception handlers to log error conditions with appropriate Log Status Codes:

<flow name="invoice-processing-flow">
    <file:inbound-endpoint path="/drop/invoices" />
    
    <!-- Normal processing ... -->
    
    <catch-exception-strategy doc:name="Catch Exception Strategy">
        <scripting:component doc:name="Set Error Logging Variables">
            <scripting:script engine="Groovy"><![CDATA[
                sessionVars['nodiniteMessageTypeName'] = "Invoice#1.0";
                sessionVars['nodiniteLogText'] = "Processing failed: " + exception.getMessage();
                sessionVars['nodiniteLogStatus'] = -1; // Error status
                sessionVars['nodiniteEndPointDirection'] = 0;
                sessionVars['nodiniteContextValues'] = [
                    fileName: flowVars['originalFilename'],
                    errorType: exception.getClass().getSimpleName(),
                    errorMessage: exception.getMessage(),
                    stackTrace: exception.getStackTrace().toString()
                ];
                return payload;
            ]]></scripting:script>
        </scripting:component>
        <flow-ref name="nodinite-logging-subflow" doc:name="Log Error"/>
    </catch-exception-strategy>
</flow>

Log Status Code Guidelines

• -1 (Error) - Processing failure, message rejected, exception thrown
• 0 (Success) - Normal processing, message accepted
• 1 (Information) - Audit trail, milestone reached, no action required

Correlation

Correlation links related log events across flows, systems, and time. See the Mule ESB Correlation guide for detailed correlation strategies.

Basic correlation example

// Set correlation ID at flow entry
sessionVars['correlationId'] = message.id; // or flowVars['orderId']
message.correlationId = sessionVars['correlationId'];

// Use same correlation ID for all log events in this flow
sessionVars['nodiniteContextValues'] = [
    correlationId: sessionVars['correlationId']
];

Next Steps

Implement the Custom Connector
Complete Working Example
Add or manage Search Fields
Add or manage Log Views

Related Topics

Custom Connector for Mule ESB Logging
JSON Log Event
Message Types
Search Field Expressions
Context Options
Log Status Codes
Mule ESB Correlation
Endpoints
Endpoint Directions
Endpoint Types
Log Agents
Non-Events Monitoring
Business Process Modeling (BPM)