- 0 minutes to read

Order-to-Cash (O2C) Process Demo - Complete Package

This demo showcases an Order-to-Cash (O2C) business process using Nodinite Log Events and the Log API. The scenario follows a complete order lifecycle from initial customer order through final invoice, demonstrating how to log business transactions across multiple domains, systems, and services using multiple message formats (JSON, XML, flat files).

A complete, production-ready package featuring 100 order interchanges following a probabilistic happy-path scenario, generating approximately 1,060 log events for analysis and visualization in Nodinite.

O2C - BPM
Example BPMs diagram illustrating the 7-step Order-to-Cash process across multiple systems and Domains.

Business Context

Order-to-Cash Process: A typical enterprise integration scenario where customer orders flow through multiple business Domains:

  • Sales Domain - Customer order reception and delivery confirmation
  • Planning Domain - ERP order entry and production scheduling
  • Logistics Domain - Order fulfillment and delivery
  • Finance Domain - Invoice generation and accounting

Each step generates events that create an audit trail, enable real-time monitoring, and populate the Repository Model with integration landscape metadata through Repository Binding context options.

🚀 CRITICAL: To enable automatic landscape creation from log events, the system parameter AllowRepositoryAutomapping must be set to true. This is the entire point of this demo - each log event carries a Repository Binding JSON structure that Nodinite uses to automatically build and maintain your integration landscape (systems, services, and service relations) without manual configuration.

O2C Process Milestones

The following table defines the seven key steps in the Order-to-Cash process. Each step represents a domain-specific action that generates a Log Event. The Message Type Name determines which Search Field Expressions are evaluated to extract business data.

Step # Milestone Domain Message Type Name System Service Direction
1 Order Received from Customer Sales O2C.Order.Received/1.0 Portal INT1337-RCV-Order-Incoming Receive
2 Order Entry in ERP Finished Planning O2C.Order.Entry/1.0 ERP INT1337-ENT-Order-Entry Send
3 Order Confirmation Delivered to Customer Sales O2C.Order.Confirmation/1.0 Portal INT1337-SND-Confirm-Outgoing Send
4 Order Planned Planning O2C.Order.Scheduled/1.0 ERP INT1337-PLN-Order-Scheduled Send
5 Order Completed for Transport Logistics O2C.Order.Ready/1.0 WMS INT1337-PKG-Order-Packed Send
6 Order Delivered Logistics O2C.Order.Shipped/1.0 WMS INT1337-RCV-Order-Delivered Receive
7 Order Invoiced Finance O2C.Order.Invoice/1.0 ERP-Finance INT1337-INV-Order-Invoiced Send

Demo Architecture

Systems

  • Portal: Customer-facing portal where orders are received
  • ERP: Enterprise Resource Planning system handling planning and finance
  • WMS: Warehouse Management System for logistics operations
  • ERP-Finance: Finance module within ERP for invoicing

Services Architecture

The demo includes 14 paired services (7 primary + 7 forwarders) organized as 7 complete business milestones. Each milestone generates 2 log events: a Receive event and a Send event, creating a full audit trail.

7 Primary Business Services - Execute actual O2C milestones with BPMs tracking:

  • INT1337-RCV-Order-Incoming (Portal, Receive) - Step 0
  • INT1337-ENT-Order-Entry (ERP, Send) - Step 1
  • INT1337-SND-Confirm-Outgoing (Portal, Send) - Step 2
  • INT1337-PLN-Order-Scheduled (ERP, Send) - Step 3
  • INT1337-PKG-Order-Packed (WMS, Send) - Step 4
  • INT1337-RCV-Order-Delivered (WMS, Receive) - Step 5
  • INT1337-INV-Order-Invoiced (ERP-Finance, Send) - Step 6

7 Forwarder Services - Bridge Receive-to-Send transitions (no BPM, architectural only):

  • INT1337-SND-Order-Incoming (Portal) - Step 0 forwarder
  • INT1337-RCV-Order-Entry (ERP) - Step 1 forwarder
  • INT1337-RCV-Confirm-Incoming (Portal) - Step 2 forwarder
  • INT1337-RCV-Planned-Incoming (ERP) - Step 3 forwarder
  • INT1337-RCV-Packing-Incoming (WMS) - Step 4 forwarder
  • INT1337-SND-Delivery-Outgoing (WMS) - Step 5 forwarder
  • INT1337-RCV-Invoice-Incoming (ERP-Finance) - Step 6 forwarder

Why 14 events per order? Each of the 7 steps generates a paired Receive→Send event sequence. The primary service (with BPMs metadata) represents the business milestone. The forwarder service creates the architectural connection needed for proper service relations. See Integration-Landscape.md for complete service topology.

Log Agent Configuration

  • Log Agent Value Id: -5 (Custom logging agent for demo)
  • Endpoint Type Id: 60 (File-based endpoint for demo)
  • Endpoint Direction: 0 (Incoming for receive operations, 1 for send operations)

Demo Data

The demo uses realistic but minimal sample data to preserve clarity:

  • Order IDs: ORD-10001 through ORD-10100 (100 interchanges)
  • Customer: Single customer record reused across all orders
    • Customer ID: CUST-001
    • Name: Acme Corporation
    • Email: orders@acme.example.com
  • Product: Single SKU
    • SKU: SKU-DEMO-001
    • Description: Demo Widget
    • Unit Price: USD 99.95
    • Quantity: 1
  • Currency: USD

Happy Path Assumption

All demo data follows a happy path scenario where data values remain consistent across message types:

  • Customer ID, name, and email never change
  • Order amount remains constant (USD 99.95)
  • No error states or retry scenarios (all log statuses are 0 for success, except incomplete steps which receive -1337)

Log Event Structure in This Demo

Each Log Event follows the Nodinite JSON formatted Log Event structure with:

  1. Details (mandatory fields + optional context)

    • LogAgentValueId: -5
    • EndPointName: Domain-specific endpoint name
    • EndPointUri: File-based path
    • EndPointDirection: 0 (receive) or 1 (send)
    • EndPointTypeId: 60 (file)
    • OriginalMessageTypeName: Message type from the table above
    • LogDateTime: UTC with random increments between steps

  2. Payload (Body)

    • Base64-encoded message content
    • Alternates between JSON, XML, and flat-file formats
    • All messages preserve the same business data values

  3. Context Properties

    • CorrelationId: Unique per interchange
    • FileName: Order-specific file name
    • OrderNumber: Incrementing order number
    • CustomerID: Static customer reference
    • Future: Repository Binding context options for automatic landscape creation

Demo Execution Strategy

Data Generation

A PowerShell script generates 100 order interchanges with:

  1. Deterministic Happy Path: Each order starts at Step 0 (Order Received)
  2. Random Step Completion: Not all orders complete all 7 steps
    • Probability of progressing to next step: 90% per milestone
    • This simulates realistic business scenarios where some orders get stuck or are cancelled
  3. Incremental Order Numbers: Starting from ORD-10001, incrementing by 1
  4. Random DateTime Increments: Each event adds 30-300 seconds to simulate realistic processing time
  5. Incomplete Order Handling: The last recorded event for incomplete orders receives log status code -1337 (custom error code for this demo)
  6. Paired Events: Each step generates 2 events (Receive + Send) for complete audit trail
  7. SequenceNo: Starts at 1 (not 0) for easier progress tracking - ranges from 1-14 for complete orders

Log API Invocation

Each interchange step is sent to the Nodinite Log API with:

  • HTTP Header: x-ms-client-tracking-id = {PREFIX}-{DATEPART}-{SEQUENCE}
    • Example: PIC-20251022-0001, PIC-20251022-0002, etc. (when script runs on Oct 22, 2025)
    • {PREFIX} = Customer code (e.g., PIC)
    • {DATEPART} = Execution date in YYYYMMDD format (generated dynamically at runtime)
    • {SEQUENCE} = Order sequence number (e.g., 0001)
    • PIC = Process Interchange Correlation
  • Endpoint: REST POST to /api/v2/LogEvents
  • Authentication: API key (configured in script parameters)
  • Payload: Nodinite JSON Log Event (base64-encoded body + context)

Repository Binding Context Options (The Key to This Demo)

Each Log Event includes a Repository Binding JSON in the Context section that automatically creates the integration landscape. This is the mechanism that transforms raw log events into a documented, visualized integration landscape.

Context Key: ExtendedProperties/1.0#RepositoryBinding

Structure (for each step):

{
  "Name": "Step Description",
  "Service": {
    "Name": "INT1337-ServiceCode-Description",
    "Direction": "Receive|Send",
    "System": {
      "Name": "System Name"
    },
    "Integration": {
      "Name": "INT1337 - Order-to-Cash"
    },
    "BPMs": [
      {
        "Name": "INT1337 - Order-to-Cash Flow",
        "ArtifactRenaming": "Step Description",
        "Domain": {
          "Name": "Domain Name",
          "Index": 0
        },
        "Step": 0,
        "ServiceRelations": [
          {
            "Name": "INT1337-UpstreamService",
            "Direction": "Receive",
            "Step": -1,
            "Label": "From upstream",
            "ConnectorStyle": 1,
            "SourceAttachmentPoint": 2,
            "TargetAttachmentPoint": 0
          }
        ]
      }
    ]
  }
}

Key concepts:

  • Service: Defines this step's service (e.g., INT1337-RCV-Order-Incoming, INT1337-ENT-Order-Entry)
  • System: The system where the service runs (e.g., Portal, ERP, WMS)
  • Direction: Receive (data comes in) or Send (data goes out)
  • BPMs: Business Process Management array containing process flow metadata
  • Domain: The business domain and its index in the process flow (0=Sales, 1=Planning, 2=Logistics, 3=Finance)
  • Step: 0-based step number in the process (0 for first step, 1 for second, etc.) - displays as 1-based in UI
  • ServiceRelations: Links to upstream services showing data flow dependency
  • ArtifactRenaming: Display name for the milestone in the BPM matrix
  • ConnectorStyle: Arrow style (0=Arrow, 1=DottedArrow, 2=Line, 3=DottedLine, 4=StraightArrow, 5=StraightDottedArrow)

Processing:

When AllowRepositoryAutomapping is true, the Logging Service:

  1. Reads the Repository Binding JSON from each log event
  2. Creates or updates the Integration entity
  3. Creates or updates the Service entity with proper direction
  4. Creates or updates the System entity
  5. Creates the service relations (ServiceRelations) linking steps together based on step dependencies
  6. Assigns the Domain and step order for BPM visualization with proper connector styling

Without Repository Binding: You must manually create all systems, services, and relations in the UI
With Repository Binding: The landscape is automatically built from logging

Sample Message Formats

The following sections document sample messages for each O2C milestone. Each message uses consistent business data:

  • Customer ID: CUST-001
  • Customer Name: Acme Corporation
  • Order Amount: USD 99.95
  • Product SKU: SKU-DEMO-001

Message Format Rotation

To demonstrate Nodinite's format-agnostic capabilities:

Step Format File
1 - Order Received JSON 1-Order-Received.md
2 - Order Entry XML 2-Order-Entry.md
3 - Order Confirmation Flat File (CSV) 3-Order-Confirmation.md
4 - Order Planned JSON 4-Order-Planned.md
5 - Order Ready XML 5-Order-Ready.md
6 - Order Shipped Flat File (PSV) 6-Order-Shipped.md
7 - Order Invoiced JSON 7-Order-Invoiced.md

PowerShell Data Generation Script

A comprehensive PowerShell script automates the creation of 100 realistic orders:

  • Location: Generate-O2C-Demo-Data.ps1
  • Documentation: Generate-O2C-Demo-Data.md
  • Generates: ~1,060 log events (100 orders × ~10.6 events average per order)
    • Complete orders (all 7 steps): ~53 orders × 14 events = 742 events
    • Partial orders (1-6 steps): ~47 orders × variable events = ~318 events
  • Features:
    • Probabilistic step completion (90% progression rate)
    • Incremental order numbers (ORD-10001 through ORD-10100)
    • Random timestamp increments (30-300 seconds between events)
    • Multi-format payloads (JSON, XML, CSV, PSV)
    • Context properties for business analytics
    • Happy-path data values (consistent customer/product)
    • Paired Receive→Send events for each milestone
    • SequenceNo starts at 1 (not 0) for easier tracking

Key Features

7-Step Order Lifecycle

# Milestone Domain System Format Status
1 Order Received Sales Portal JSON Complete
2 Order Entry Planning ERP XML Complete
3 Confirmation Sales Portal CSV Complete
4 Order Planned Planning ERP JSON Complete
5 Order Ready Logistics WMS XML Complete
6 Order Shipped Logistics WMS PSV Complete
7 Order Invoiced Finance ERP-Finance JSON Complete

Realistic Data Generation

  • 100 orders generated with probabilistic step completion
  • 90% progression rate between steps (realistic failures)
  • ~53 orders complete all 7 steps (53% happy path)
  • ~47 orders stop at various stages (47% partial completion)
  • Incremental IDs: ORD-10001 through ORD-10100
  • Consistent data: Same customer, product, amounts across all orders
  • Forwarder events: Separate log events for 6 architectural forwarding services

Multi-Format Support

Demonstrates Nodinite's format-agnostic capabilities:

  • JSON (Orders 1, 4, 7 - 42% of events)
  • XML (Orders 2, 5 - 29% of events)
  • Flat Files: CSV (Order 3), PSV (Order 6 - 29% of events)

Rich Context Properties

  • Correlation ID: {PREFIX}-{DATEPART}-{SEQUENCE} (stored as ApplicationInterchangeId, dynamically generated based on execution date)
    • Example: PIC-20251022-0001 when script runs on Oct 22, 2025
  • LogText: Milestone name only (e.g., "Order Received from Customer") - no order ID to avoid clutter
  • Order and customer data in Context properties
  • Business metrics for Search Field extraction
  • Repository Binding context options with complete BPM structure for automatic integration landscape creation

Domain Transitions

The O2C process traverses 4 distinct business domains sequentially:

Sales → Planning → Logistics → Finance 

SALES DOMAIN (Index 0)
├─ Step 1: Portal receives orders (Receive)
├─ Step 3: Portal confirms orders (Send)
└─ Customer notifications

    ↓ (transition via order confirmation)

PLANNING DOMAIN (Index 1)
├─ Step 2: ERP enters orders (Send)
├─ Step 4: ERP schedules production (Send)
└─ Resource allocation

    ↓ (transition via schedule)

LOGISTICS DOMAIN (Index 2)
├─ Step 5: WMS packs orders (Send)
├─ Step 6: WMS delivers orders (Receive)
└─ Shipment tracking

    ↓ (transition via delivery proof)

FINANCE DOMAIN (Index 3)
└─ Step 7: Finance invoices orders (Send)
   Payment terms, revenue recognition

Search Field Extraction

The BPM enables Search Field extraction from each step's message:

Step Message Type SearchFields Available Example
1 O2C.Order.Received/1.0 OrderId, CustomerId, Amount, OrderDate ORD-10001
2 O2C.Order.Entry/1.0 OrderId, ERPOrderNumber, EntryTime ORD-10001-ERP
3 O2C.Order.Confirmation/1.0 OrderId, ConfirmationNumber, SentTo CONF-10001-C
4 O2C.Order.Scheduled/1.0 OrderId, ScheduleDate, ProductionLine LINE-A
5 O2C.Order.Ready/1.0 OrderId, TrackingNumber, WarehouseLocation BIN-A-247
6 O2C.Order.Shipped/1.0 OrderId, DeliveryDate, CarrierName, ProofOfDelivery POD-10001
7 O2C.Order.Invoice/1.0 OrderId, InvoiceNumber, TotalAmount, DueDate INV-10001-2025

Demo Package Structure 

Log API/Troubleshooting/Demo/
├── Overview.md                          ← Complete guide (all-in-one)
├── Integration-Landscape.md             ← Systems, services, relations
├── BPM-Expected-Layout.md              ← Visual BPM diagram
├── Generate-O2C-Demo-Data.ps1          ← PowerShell script (generates 1000 orders)
├── Generate-O2C-Demo-Data.md           ← Script usage guide
│
└── Step Examples (7 complete steps):
    ├── 1-Order-Received.md             (JSON format, Sales domain, Portal system)
    ├── 2-Order-Entry.md                (XML format, Planning domain, ERP system)
    ├── 3-Order-Confirmation.md         (CSV format, Sales domain, Portal system)
    ├── 4-Order-Planned.md              (JSON format, Planning domain, ERP system)
    ├── 5-Order-Ready.md                (XML format, Logistics domain, WMS system)
    ├── 6-Order-Shipped.md              (PSV format, Logistics domain, WMS system)
    └── 7-Order-Invoiced.md             (JSON format, Finance domain, ERP-Finance system)

Learning Objectives

By completing this demo, you will understand:

  • ✅ JSON Log Event structure (mandatory + optional fields)
  • ✅ Multi-format message handling (JSON, XML, flat files)
  • ✅ Base64 payload encoding
  • ✅ Context property usage
  • ✅ Correlation ID patterns
  • ✅ DateTime timezone handling
  • ✅ Log Status codes
  • ✅ HTTP request structure to Log API
  • ✅ Repository Binding automation
  • ✅ BPM workflow visualization
  • ✅ End-to-end process tracing
  • ✅ Business metrics extraction

Important Implementation Details

Data Generation Options

  • DryRun mode: Generates first 2 orders only (preview)
  • ExportToFile: Saves to JSON file (no API calls)
  • Production mode: (Future enhancement) Direct Log API calls
  • Repeatability: Same random seed = same results (configurable)

Log Status Handling

  • Log Status 0: Success (all completed steps)
  • Log Status -1337: Failed/incomplete (last step of partial orders)
  • Semantic meaning: Allows you to track where orders stop in the pipeline

Correlation ID Format

  • Format: {PREFIX}-{DATEPART}-{HHMM}-{SEQUENCE}
  • Components:
    • {PREFIX} = Customer code (e.g., PIC)
    • {DATEPART} = Execution date in YYYYMMDD format (generated dynamically when script runs)
    • {HHMM} = Hour and minute of execution (e.g., 0915 for 09:15 AM)
    • {SEQUENCE} = Order sequence number (e.g., 0001)
  • Example: PIC-20251023-0915-0001, PIC-20251023-0915-0042, etc. (when executed on Oct 23, 2025 at 09:15 AM)
  • Example: PIC-20251024-1430-0001, PIC-20251024-1430-0002, etc. (if executed on Oct 24, 2025 at 14:30 PM)
  • Scope: All steps of an order share the same correlation ID
  • Purpose: End-to-end tracing and grouping
  • Benefit: Script is reusable on any date and time without code changes

Log Event Reference (Condensed)

All steps create Nodinite Log Events following the JSON formatted Log Event structure:

{
  "LogAgentValueId": -5,
  "EndPointName": "Portal-OrderReceived-Drop",
  "EndPointUri": "C:\\Integration\\Portal\\Orders\\In",
  "EndPointDirection": 0,
  "EndPointTypeId": 60,
  "OriginalMessageTypeName": "O2C.Order.Received/1.0",
  "LogDateTime": "2025-10-14T09:15:30.123Z",
  "SequenceNo": 0,
  "LogText": "Order Received from Customer",
  "ApplicationInterchangeId": "PIC-20251022-0001",
  "LogStatus": 0,
  "Body": "eyJiYXRjaElkIjoiYmF0Y2gtMjAyNS0x...",
  "Context": {
    "OrderNumber": "ORD-10001",
    "CustomerId": "CUST-001",
    "ExtendedProperties/1.0#RepositoryBinding": "{...}"
  }
}

Key Fields:

  • OriginalMessageTypeName: Determines Search Field Expressions (critical)
  • ApplicationInterchangeId: Correlation ID linking all 7 steps of one order
  • LogStatus: 0 (success) or -1337 (incomplete)
  • EndPointDirection: 0 (Receive) or 1 (Send)
  • Body: Base64-encoded message (JSON, XML, or flat file)
  • ExtendedProperties/1.0#RepositoryBinding: Automatic landscape creation (requires AllowRepositoryAutomapping = true)

Correlation ID Pattern: {PREFIX}-{DATEPART}-{SEQUENCE} (e.g., PIC-20251022-0001)

Message Files (Steps 1-7)

Each step is documented in a dedicated file showing the actual message format for that step. The following table shows what each file covers:

File Step # Domain System Format Focus
1-Order-Received.md 1 Sales Portal JSON Entry point - customer order reception
2-Order-Entry.md 2 Planning ERP XML Order validation and entry into ERP
3-Order-Confirmation.md 3 Sales Portal CSV Confirmation back to customer
4-Order-Planned.md 4 Planning ERP JSON Production scheduling and resource allocation
5-Order-Ready.md 5 Logistics WMS XML Warehouse packing completion
6-Order-Shipped.md 6 Logistics WMS PSV Delivery confirmation with proof
7-Order-Invoiced.md 7 Finance ERP-Finance JSON Invoice generation and revenue recognition

Each message file includes:

  • Step-specific message sample (format example)
  • Business data for that step
  • Key points unique to that step's domain/system transition
  • How the Repository Binding links this step to upstream steps

To learn the general Log Event structure, refer to the sections above. Each message file focuses on format-specific content without repeating common explanations.

Next Steps

  1. Understand Integration Landscape - Review Integration-Landscape.md for systems, services, and service relations
  2. Review Sample Messages - Examine each message format in Steps 1-7 to understand the business data structure
  3. Run the PowerShell Generator Script - Follow Generate-O2C-Demo-Data.md to create 1000 realistic O2C interchanges
  4. Analyze Results in Nodinite UI - Observe BPM visualization, Service relations, and Search Field extraction