Webhook ve polling: otel sistemleri bir değişikliği nasıl öğrenir?

Webhook, bir sistemin bir değişiklik olduğu anda diğerine gönderdiği kısa mesajdır; örneğin yeni bir rezervasyon. Polling bunun tersidir: bir sistem, birkaç dakikada bir, "bir değişiklik var mı" diye sorar. Webhook daha hızlıdır ama sessizce kaçabilir; polling daha yavaştır ama kontrol edebileceğiniz bir iz bırakır. Bu, webhook ile polling arasındaki otel entegrasyonu kararının özüdür.

Örneğin bir misafir saat 21:40'ta deniz manzaralı odaya geçiyor; resepsiyon bunu 21:52'de görüyor. Bu on iki dakikada eski oda üç kanalda satışta kaldı. Bir şey bozulmadı; iki sistem değişikliği farklı yollarla öğreniyor. Bu yazının sonunda bu iki yolu adlandırabilecek, birkaç dakikalık gecikmenin otelinize neye mal olduğunu değerlendirebilecek ve herhangi bir entegrasyon satıcısına hata davranışı hakkında somut sorular sorabileceksiniz.

Webhook ile polling arasındaki fark nedir?#

Webhook bir itme, polling bir çekmedir. Webhook'da gönderen sistem, değişiklik olduğu anda kısa bir mesaj teslim eder; polling'de alan sistem, zamanlayıcıyla bir soru sorar ve değişiklik olsun ya da olmasın bir yanıt alır.

Posta benzetmesi, kısaca#

Webhook, mektup geldiğinde kapınızı çalan kuryedir. Polling, on dakikada bir postaneye gidip "benim bir şey var mı" diye sormanızdır. İki modelde de sistemler ayrık kalır ve aralarında yalnızca küçük mesajlar geçer. Hiçbir model, otelin verisinin iş ortağının sisteminde yaşaması anlamına gelmez.

Polling sabit bir aralığa sahiptir, örneğin her beş dakika. Ortalama gecikme aralığın yarısı kadar, en kötü durum her seferinde ve öngörülebilir biçimde tam aralıktır. Webhook her şey yolundayken normalde bir saniyenin altında gelir; dikkat edilecek kelime "normalde": gecikme ortalama olarak kısadır ama bir şey bozulduğunda üst sınırı yoktur. Sistemlerin birbiriyle nasıl konuştuğunu sade bir dille görmek için PMS entegrasyonu nasıl çalışır? API'yi sade bir dille anlamak yazısına bakabilirsiniz.

İkisinin altında aynı olaylar#

İki modelin altında da aynı şey gerekir: tanımlı bir olay listesi, örneğin rezervasyon oluşturuldu, rezervasyon değişti, rezervasyon iptal edildi, oda değişti; ve her biri için üzerinde anlaşılmış bir anlam. İkisinden hiçbiri "modern olan" model değildir. İki model farklı sorunları çözer; bu yüzden olgun bir kurulum aynı bağlantıda ikisini birden kullanır.

Sorulacak soru hangisinin daha iyi olduğu değil, hangi hatayla yaşayabileceğinizdir: ölçebileceğiniz bir gecikme mi, göremeyeceğiniz bir kayıp mı.

Birkaç dakikalık gecikme bir rezervasyon için ne demek?#

Değişiklikle mesaj arasındaki boşlukta bir oda iki kez satılabilir ya da misafire yanlış fiyat verilebilir. Bu boşluğun büyüklüğü yalnızca teknik değil, ticari bir karardır.

Bir seyahat acentesinden yeni rezervasyon gelir. Otelin sistemi öğrenene kadar aynı oda, otelin kendi web sitesinde ve diğer tüm kanallarda satışta kalır. İptal bunun ayna görüntüsüdür: mesaj gelene kadar oda bloke ve satılmamış kalır; bu da yüksek sezonda sessizce kaybedilen paradır. Fiyat değişikliği bir teklif sorunudur: gecikme süresince misafire ya da acenteye dünün fiyatı sunulur; buna uyup uymamak otelin seçimidir. Oda değişikliği ise operasyon sorunudur: kat hizmetleri yanlış odaya gönderilir, misafir lobide bekler.

Polling gecikmeyi sınırlar: önceden bilinen tek bir aralık. Webhook gecikmeyi genelde çok küçük, ara sıra sınırsız yapar; sınırsız durumun arkasında bir emniyet ağı gerekir. Mekanizmayı olay türüne göre belirleyin. Ağustosta oda boşaltan bir iptal, mevcut en hızlı yolu hak eder; haftalık bir fiyat planı hak etmez.

Örneğin 200 odalı bir otel, yüksek sezonda beş dakikada bir soruyorsa, iptal edilen bir odanın satışa açılması serbest kaldıktan sonra en fazla beş dakika gecikebilir. Bu bir seçimdir ve yazılı bir seçim olmalıdır. Bu gecikmelerin bir kanal yöneticisi bağlantısının içinde nasıl davrandığını görmek için Kanal yöneticisi entegrasyonu nasıl çalışır? İki yönlü bağlantı, gecikme ve hatalar yazısına bakabilirsiniz.

Bir mesaj kaçarsa ne olur?#

Görünür hiçbir şey olmaz. Gönderen sistem teslim ettiğine inanır, alan sistem mesajı hiç görmez ve biri karşılaştırana kadar iki sistem anlaşmaz kalır.

Nedenler genelde sıradandır: alan sistem yeniden başlıyordur, adres değişmiştir, bir ağ kuralı çağrıyı engellemiştir ya da mesaj kabul edilmiş ama işlenirken hata vermiştir. Tehlikeli olan kısım sessizliktir. İki ekranda da hata görünmez; resepsiyon durumu genelde kapıdaki misafirden öğrenir.

Gelip de işlenemeyen bir mesaj, hiç gelmeyenden daha kötüdür; çünkü gönderen işi bitmiş sayıp denemeyi bırakabilir. Polling farklı ve daha yumuşak biçimde bozulur: bir soru kaçarsa bu yalnızca gecikmiş bir sorudur, çünkü sonraki soru yeniden sorar ve güncel durumu alır.

Fark etmenin iki gereksinimi vardır: kanalın çalışır durumda olduğunu kanıtlayan küçük ve düzenli bir sinyal, yani nabız; ve iki rezervasyon listesinin periyodik tam karşılaştırması. Farkları kimin, ne sıklıkla okuyacağını yazılı hale getirin. Kimsenin açmadığı bir karşılaştırma raporu bir süstür.

Yeniden denemeler ve karşılaştırma kaçan olayları nasıl yakalar?#

Yeniden denemeler, başarısız bir teslimata genişleyen bir takvimle daha çok şans verir; karşılaştırma, iki sistemi sabit bir ritimle eşitleyip denemelerin kaçırdığını onarır. Biri olmadan diğeri yarım emniyet ağıdır.

Yeniden deneme düzeni basittir: kısa bir beklemeden sonra tekrar dene, sonra giderek uzayan bekleme süreleriyle, sonra belli bir sürenin sonunda dur. O sürenin ne olduğunu sorun; çünkü sonrasında mesaj yoktur. Yeniden denemeler ikinci kayıt yaratır: aynı rezervasyon mesajı iki kez gelebilir, bu yüzden alan sistem tekrarı tanımalı ve ikinci bir rezervasyon açmamalıdır. Mühendisler bu özelliğe idempotentlik derler: aynı mesajın iki kez uygulanması, bir kez uygulanmasıyla aynı sonucu verir.

Sıra da garanti değildir. "Rezervasyon değişti" mesajı "rezervasyon oluşturuldu"dan önce gelebilir; bu yüzden alan sistemin bir kuralı olmalıdır: elinde olmayan bir rezervasyona güncelleme gelirse, tahmin etmek yerine asıl kaydı istesin. Yeniden oynatma insan müdahalesinin kapısıdır: geçmişteki tek bir olayı, özgün zaman damgası korunarak, istendiğinde yeniden göndermek. Böylece kayıt doğru kalmaya devam eder.

Karşılaştırma, bazılarının mutabakat dediği adımdır: iki sistem arasındaki toplamları ve tek tek rezervasyonları günlük ya da saatlik eşitler ve bir insanın üzerinde işlem yapabileceği bir fark listesi üretir. Tekrar tekrar başarısız olan mesajların bir kişinin önüne bırakıldığı bir bekleme listesi de önemlidir; son denemeden sonra sessizce çöpe atılmamalıdırlar.

Alma adresi neden korunmak zorunda?#

Çünkü bir webhook adresi bir kapıdır. Adresi öğrenen herkes, tam bir rezervasyona benzeyen bir mesaj gönderebilir ve otelin sistemi buna göre hareket eder.

Adres uzun, rastgele ve tahmin edilemez olmalı ve bir parola gibi ele alınmalıdır: ortak belgelere, ekran görüntülerine ya da destek kayıtlarına yapıştırılmamalıdır. Alıcı, arayanın kim olduğunu denetlemelidir. Bu, mesajda taşınan ortak bir gizli anahtar ya da yalnızca iki tarafın üretebileceği, mesaj içeriği üzerinden hesaplanan bir imza demektir. Mesaj şifreli bir bağlantı üzerinden yol almalıdır; böylece içerik yolda okunamaz ve değiştirilemez.

Eski mesajlar iki kez kabul edilmemelidir. Geçen haftadan doğru imzalı bir mesaj, yeniden gönderilirse hâlâ bir saldırıdır; bu yüzden alıcı zaman damgasına bakar ve yalnızca kısa bir pencereyi kabul eder. Mesajı küçük tutun: misafirin tüm kişisel verisi değil, rezervasyon numarası ve değişiklik. Mesajın her kopyası kişisel verinin yaşadığı yeni bir yerdir; kişisel veri ise kişisel verilerin korunması kanunu (KVKK) kapsamında yükümlülük getirir. Gelen her mesajı zamanıyla ve sonucuyla kayda geçirin; iş ortağı "gönderdik" dediğinde kayıt tartışmayı bitirir.

Hangi işler webhook'a, hangileri polling'e uyar?#

Hızla bilinmesi gereken olaylar için webhook, kaybolmaması gereken her şey için polling, bir hatanın odaya mal olduğu küçük olay kümesi için ikisi birden kullanılır.

Webhook öncelikli: yeni rezervasyon, iptal, değişiklik, ödeme durumu ve konaklama sırasındaki oda durumu değişiklikleri. Polling öncelikli: kanallara fiyat ve müsaitlik eşitleme, sabit bir ritmin kabul edilebilir olduğu ve bütün tablonun andan daha önemli olduğu yer. İkisi birden: yüksek sezondaki iptaller, grup bloğu açılımları ve envanteri boşaltan her şey; çünkü bunlarda kayıp da pahalıdır, gecikme de. Hiçbiri günlük karşılaştırmanın yerini tutmaz; o, iki modelin de altındaki yedek mekanizmadır.

Maliyet gerçektir. Polling, hiçbir şey değişmemişken bile sorar; geniş bir envanterde kısa aralık iki tarafı da yorar ve sağlayıcılar ne sıklıkla sorabileceğinizi sınırlar. Mekanizmanın belgelenmiş ve sınanabilir olup olmadığını imzadan önce sorun. Sessiz bir haftada sınayamadığınız bir entegrasyonu, Ağustos'ta sınayacaksınız. Bu dünyanın eski ve sözleşme ağırlıklı tarafı için Otel XML entegrasyonu nedir? Tur operatörü ve bedbank bağlantıları, satıcıların kullandığı güvenlik kavramları için Sürümlü ve OAuth ile korunan rezervasyon API'si: her kelime otel için ne anlama gelir? yazısına bakabilirsiniz.

Bir otel entegrasyon satıcısına ne sormalı?#

Özellik listesini değil, hata davranışını sorun: bir mesaj geciktiğinde, kaybolduğunda, ikileştiğinde ya da reddedildiğinde ne olur. Bu soruları yanıtlayabilen satıcı, resepsiyonu düşünmüş demektir.

Yanıtlar güven verici değil, somut ve yazılı olmalıdır. "Her zaman çalışır" aşağıdaki hiçbir sorunun yanıtı değildir. Deneme süresinde karşılaştırma raporunu bir kez isteyin ve ön büro yöneticinizle birlikte okuyun. Gece 02:00'te kimi arayacağınızı ve kararlaştırılan müdahale süresini sorun; bunu satış sunumuna değil sözleşmeye yazdırın.

Şimdi ne yapmalı#

Bir entegrasyonu imzalamadan önce satıcıdan, baştan sona tek bir kayıp mesajı size anlatmasını isteyin: nasıl fark edilir, nasıl yeniden gönderilir ve gün sonunda iki sistemi kim karşılaştırır. İtme ve çekme yalnızca taşımadır; sakin bir resepsiyon ile çift rezervasyon arasındaki fark, arkasındaki yeniden denemelerde, tekrar denetiminde ve günlük karşılaştırmadadır.