Runbook: XML Splitting Enhancement for ARI Push to OTA Services

1. Overview

This document describes the new XML splitting mechanism implemented for ARI (Availability, Rate, and Inventory) synchronization to OTA services such as Booking.com, Traveloka, and other connected channels.

The primary objective of this enhancement is to prevent oversized XML payloads from exceeding the OTA Service limitation of 1 MB per request, while also improving synchronization reliability for exception rates.

2. Background

Previous Approach: Split by Rate Plan

Previously, large ARI XML requests were split based on rate plans.

For example:

Property has 25 rate plans.
Split configuration = 5 rate plans per request.
System generates multiple main requests.
Additional exception requests are generated for OTA-specific special rates.

Sample Main Request (Split by Rate Plan)

<?xml version="1.0" encoding="UTF-8"?>
<request>
    <propertyid>57</propertyid>
    <otaids>5,6,12,13,14,21,23</otaids>

    <daterange day="2025-10-22" rateplan_id="140001" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140002" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140003" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140004" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140005" price="700000000" />

    <daterange day="2025-10-23" rateplan_id="140001" price="700000000" />
    <daterange day="2025-10-23" rateplan_id="140002" price="700000000" />
    <daterange day="2025-10-23" rateplan_id="140003" price="700000000" />
    <daterange day="2025-10-23" rateplan_id="140004" price="700000000" />
    <daterange day="2025-10-23" rateplan_id="140005" price="700000000" />
</request>

Sample Exception Request

<?xml version="1.0" encoding="UTF-8"?>
<request>
    <propertyid>57</propertyid>
    <otaids>12</otaids>

    <daterange day="2025-10-22"
               rateplan_id="140001"
               price="500000012"
               stopsell="824640307440" />

    <daterange day="2025-10-22"
               rateplan_id="140007"
               price="500000012"
               stopsell="824640308016" />
</request>

Previous Processing Flow

Main Request 1
        ↓
Main Request 2
        ↓
Main Request 3
        ↓
Main Request 4
        ↓
Main Request 5
        ↓
Exception Request

Exception requests could only be executed after all main requests completed successfully.

3. Problem Statement

Dependency on Main Requests

Exception requests depend on the successful completion of all main requests.

High Failure Impact

Example:

Main Request 1 ✓
Main Request 2 ✗
Main Request 3 ✓
Main Request 4 ✓
Main Request 5 ✓

Exception Request → Not Executed

Consequences:

OTA receives standard ARI updates.
OTA does not receive exception rates.
OTA pricing becomes inconsistent with the Channel Manager.

Large Retry Scope

When one main request fails:

Failed request must be retried.
Exception requests must wait again for all prerequisite requests.

This increases synchronization time and operational complexity.

4. New Solution: Split by Date

The XML is now split based on date ranges instead of rate plans.

Each generated request contains:

All applicable rate plans
A subset of dates
A unique token

Sample Main Request (Split by Date)

<?xml version="1.0" encoding="UTF-8"?>
<request>
    <propertyid>57</propertyid>
    <otaids>5,6,12,13,14,21,23</otaids>

    <daterange day="2025-10-22" rateplan_id="140001" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140002" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140003" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140004" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140005" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140006" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140007" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140008" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140009" price="700000000" />
    <daterange day="2025-10-22" rateplan_id="140010" price="700000000" />

    <token>token_2025-10-22</token>
</request>

Sample Exception Request (Split by Date)

<?xml version="1.0" encoding="UTF-8"?>
<request>
    <propertyid>57</propertyid>
    <otaids>12</otaids>

    <daterange day="2025-10-22"
               rateplan_id="140001"
               price="500000012"
               stopsell="824640307440" />

    <daterange day="2025-10-22"
               rateplan_id="140007"
               price="500000012"
               stopsell="824640308016" />

    <token>token_2025-10-22</token>
</request>

5. Token-Based Pairing

Each main request is assigned a unique token.

Example:

<token>token_2025-10-22</token>

Any exception request generated for the same date range will use the same token.

Pairing Relationship

Main Request A
        ↕
Exception Request A

Main Request B
        ↕
Exception Request B

This creates an independent relationship between a main request and its related exception request.

6. Processing Flow

Successful Scenario

Main Request 1 ✓
Exception Request 1 ✓

Main Request 2 ✓
No Exception

Main Request 3 ✓
Exception Request 3 ✓

Main Request 4 ✓
No Exception

Main Request 5 ✓
Exception Request 5 ✓

Failure Scenario

Main Request 1 ✓
Exception Request 1 ✓

Main Request 2 ✗
Exception Request 2 Pending

Main Request 3 ✓
Exception Request 3 ✓

Main Request 4 ✓
Exception Request 4 ✓

Only the following pair needs to be retried:

Main Request 2
Exception Request 2

Other successful requests remain unaffected.

7. Retry Mechanism

Previous Mechanism

Retry Scope:
- Failed Main Request
- All dependent Exception Requests

New Mechanism

Retry Scope:
- Failed Main Request
- Exception Request with the same token

Benefits:

Smaller retry scope.
Faster recovery.
Reduced synchronization delays.
Lower risk of OTA price mismatches.

8. Benefits

Improved Reliability

Failures are isolated to a specific date range.

Better Exception Handling

Exception requests are directly linked to their corresponding main requests through token matching.

Faster Recovery

Only affected date segments need to be retried.

Reduced OTA Price Mismatch

Exception rates are no longer blocked by unrelated failures.

Payload Size Control

Splitting by date ensures each request remains below the OTA Service payload limit of 1 MB.

9. Comparison

Aspect	Split by Rate Plan	Split by Date
Split Strategy	Rate Plan Based	Date Range Based
Exception Dependency	All Main Requests	Matching Token Only
Failure Impact	Global	Localized
Retry Scope	Large	Small
Recovery Time	Longer	Faster
OTA Price Mismatch Risk	High	Low
Payload Size Control	Yes	Yes
Scalability	Moderate	Better

10. Conclusion

The XML splitting strategy has been redesigned from a rate-plan-based approach to a date-based approach with token-based request pairing.

This enhancement provides:

Better fault isolation
More reliable exception synchronization
Smaller retry scope
Faster recovery process
Reduced OTA pricing inconsistencies
Compliance with OTA Service payload limits (< 1 MB)

As a result, ARI synchronization becomes more resilient, scalable, and easier to recover from partial failures.

1. Overview​

2. Background​

Previous Approach: Split by Rate Plan​

Sample Main Request (Split by Rate Plan)​

Sample Exception Request​

Previous Processing Flow​

3. Problem Statement​

Dependency on Main Requests​

High Failure Impact​

Large Retry Scope​

4. New Solution: Split by Date​

Sample Main Request (Split by Date)​

Sample Exception Request (Split by Date)​

5. Token-Based Pairing​

Pairing Relationship​

6. Processing Flow​

Successful Scenario​

Failure Scenario​

7. Retry Mechanism​

Previous Mechanism​

New Mechanism​

8. Benefits​

Improved Reliability​

Better Exception Handling​

Faster Recovery​

Reduced OTA Price Mismatch​

Payload Size Control​

9. Comparison​

10. Conclusion​