Event Audit Trail

The event audit trail provides a complete, immutable record of everything that happens to an order. This is essential for troubleshooting issues, compliance auditing, and understanding order history.

Accessing Events

From the order details page:

1. Navigate to the Events tab
2. View all events for this order

Events are displayed in reverse chronological order (newest first).

Event Display

Each event shows:

Color Coding

• Green: Normal operation events
• Red: Error events (ORDER_ENCOUNTERED_ERROR)

Viewing Event Data

Click the view action on any event to see its full data payload.

Event data is JSON format and contains details specific to the event type.

Example: ORDER_CREATED

{
  "flightReservationInformation": {
    "origin": "BGW",
    "destination": "DXB",
    "departureDate": "2024-06-15",
    "returnDate": "2024-06-20",
    "cabinClass": "ECONOMY"
  }
}

Example: ORDER_RESERVATION_CREATED

{
  "reservationId": "12345678"
}

Example: ORDER_ENCOUNTERED_ERROR

{
  "message": "Creating reservation for order failed.",
  "reservationInformation": {
    "searchResultKey": "abc123def456",
    "supplier": "IRIX"
  }
}

Using Events for Troubleshooting

Diagnosing Failed Orders

When an order has failed:

1. Find the error event: Look for ORDER_ENCOUNTERED_ERROR (red)
2. Check the message: Read the error description
3. Examine context: Review the reservation information
4. Trace the sequence: What happened before the error?

Common Error Patterns

Reservation Creation Failed

Event: ORDER_ENCOUNTERED_ERROR
Data: { "message": "Creating reservation for order failed." }

Cause: IRIX rejected the booking request Action: Check availability, retry, or refund

Ticket Issuance Failed

Event: ORDER_ENCOUNTERED_ERROR  
Data: { "message": "Issuing reservation ticket for order failed." }

Cause: Supplier couldn't issue ticket Action: Check with supplier, manual ticketing, or refund

Payment Verification Failed

No ORDER_PAYMENT_VERIFIED_TO_BE_PAID event after ORDER_CREATED Cause: Payment not completed or declined Action: Contact customer, verify with payment provider

Successful Order Verification

A healthy order should show this event sequence:

1. ORDER_CREATED — Order initiated
2. ORDER_PAYMENT_VERIFIED_TO_BE_PAID — Payment confirmed
3. ORDER_RESERVATION_CREATED — For each reservation
4. ORDER_RESERVATION_TICKET_ISSUED — For each flight (if applicable)

If the sequence is incomplete, investigate the missing steps.

Event Types Reference

Order Lifecycle Events

Payment Events

Reservation Events

Manual Intervention Events

Error Events

Compliance and Auditing

Audit Requirements

The event trail supports common audit needs:

• Who: Event timestamps + user context from order
• What: Event type describes the action
• When: Precise timestamps for each event
• Result: Event data shows outcomes

Generating Audit Reports

For formal audits:

1. Locate the order(s) in question
2. Export event data (via API or database)
3. Format into required report structure
4. Include relevant event data payloads

Data Retention

Events are:

• Immutable: Cannot be modified or deleted
• Permanent: Retained for the life of the order
• Timestamped: Accurate to milliseconds

Advanced Event Analysis

Cross-Order Analysis

To find patterns across orders:

1. Use the Events resource directly (not via order)
2. Filter by event type
3. Analyze across time periods

Use Cases:

• Find all failed orders in a time range
• Identify supplier-specific error patterns
• Track payment provider issues

API Access

Events can be queried via API:

GET /admin/events?entityId={orderId}
GET /admin/events?eventType=ORDER_ENCOUNTERED_ERROR

Integration with Monitoring

Error events (ORDER_ENCOUNTERED_ERROR) are also sent to:

• Error monitoring service (urgent alerts)
• Application logs

This enables proactive issue detection beyond the dashboard.

Best Practices

Regular Review

1. Check failed orders daily: Review error events
2. Monitor patterns: Look for recurring issues
3. Track resolutions: Verify manual resolutions are logged

Documentation

When manually resolving orders:

1. Include detailed information in the resolution
2. Reference external tickets or communications
3. Document what action was taken

Escalation

If you see:

• Multiple errors for same supplier → Escalate to supplier
• Payment provider errors → Check provider status
• System errors → Contact technical support