NDC Offer/Order Lifecycle: Search'ten Servicing'e

NDC Offer/Order lifecycle'ını search, offer, revalidation, order create, payment, ticketing, servicing ve reconciliation state'leriyle modelleyin.

Editoryal bilgi
Advertisement

NDC'de Offer ile Order aynı entity değildir. Offer shopping anındaki airline retail proposition'ıdır; Order ise booking sonrası transaction/servicing state'idir. İki lifecycle'ı tek DTO'ya sıkıştırmak stale price, duplicate booking ve servicing hatası üretir.

Canonical state machine

NDC Offer to Order to Ticket lifecycleNDC Offer to Order to Ticket lifecycle

Mermaid source (.mmd)

Offer identity

Offer fingerprint dedup için kullanılabilir ama provider offer/reference yerine geçmez.

Tutulması gerekenler:

  • source/carrier,
  • offer ID/reference,
  • observedAt,
  • expiry,
  • itinerary,
  • fare family,
  • baggage,
  • ancillaries,
  • total/components,
  • penalties.

Revalidation

Offer select edildikten sonra stale state riski büyür. Provider destekliyorsa revalidation/refresh sonucu explicit state üretmelidir.

text
same -> continue
price changed -> user reconfirm
expired/unavailable -> re-shop

Order create ve unknown state

Network timeout sonrası “failed” demek tehlikelidir.

text
create sent
  -> response confirmed
  -> response rejected
  -> no definitive response = UNKNOWN

UNKNOWN durumda retrieve/reconcile yapılmadan ikinci create gönderilmemelidir.

Ticketing != Order

Order confirmed olması ticket/document issuance tamamlandı demek değildir. Booking/order, payment ve ticket/document state ayrı saklanmalıdır.

Schedule change / servicing

Post-booking lifecycle:

  • involuntary schedule change,
  • voluntary change,
  • exchange,
  • cancel,
  • refund,
  • ancillary change

provider/carrier capability'lerine göre farklı olabilir.

Observability

  • offer age,
  • reprice-change rate,
  • create unknown rate,
  • order-to-ticket latency,
  • schedule-change lag,
  • servicing failure,
  • refund reconciliation.

Anti-patterns

  • itinerary == offer varsaymak,
  • offer == order varsaymak,
  • PNR == ticket varsaymak,
  • timeout == failure varsaymak,
  • source lineage'i normalization sırasında silmek.

Failure modes

  • stale offer ile order create,
  • order confirmed fakat ticket issuance başarısız,
  • duplicate order create,
  • ancillary/fare family bilgisinin normalization sırasında kaybı,
  • schedule change event'inin local state'e geç yansıması,
  • servicing capability'nin provider bazında yanlış varsayılması.

Production checklist

  • Offer ve Order ayrı entity,
  • revalidation explicit,
  • UNKNOWN order state,
  • ticket/document state ayrı,
  • provider/carrier capability map,
  • servicing/reconciliation path,
  • source lineage korunması,
  • end-to-end correlation IDs.
Teknik danışmanlık

Benzer bir entegrasyon mu planlıyorsunuz?

Gereksinim, feed/API tasarımı ve production yaklaşımını birlikte değerlendirebiliriz.

Projenizi konuşalım →

Kaynaklar

İlgili içerikler