Webhook'lar ve Polling: Gerçek Zamanlı Sevkiyat Olay Pipeline'ları Oluşturmak

Taşıyıcı ağlarıyla kutudan çıkan ERP entegrasyonları genellikle aynı kalıbı izler: takip numarası sipariş karşılamada kaydedilir ve o andan itibaren durum güncellemeleri ya taşıyıcının web sitesine manuel bir tıklamayla ya da sabit aralıklarla taşıyıcı API'sini sorgulayan zamanlanmış bir toplu işlemle alınabilir. Her iki yaklaşım da aynı temel sınırlamayı paylaşır — sistem bir sevkiyat olayından sonradan haberdar olur ve olay ile bilgi arasındaki gecikme saniyeler değil saatler olarak ölçülebilir.

Bu gecikmenin operasyonel maliyeti, bir nakliyecinin tüm portföyüne yayılarak bileşik hale gelir. Sabah 9'da otomatik bir yanıt tetikleyebilecek istisnalar, gece yarısı toplu işlemi çalışana kadar tespit edilemez kalır. Müşteri sorguları, iç ekipler müşterinin aradığı olaydan haberdar olmadan önce gelir. Taşıyıcı SLA anlaşmazlıklarını takip etmek, zaman damgası kanıtı sizin sisteminiz yerine taşıyıcının sisteminde yaşadığında zorlaşır.

Neden Polling Yanlış Varsayılan Yaklaşımdır

Taşıyıcı API'lerini polling ile sorgulamak bir istek göndermek, yanıt almak ve hiçbir şey değişmediyse atmak — sonra entegrasyonun hangi aralıkla yapılandırıldığına göre döngüyü tekrarlamak anlamına gelir. Orta ölçekte bu yönetilebilir bir durumdur. Orta büyüklükteki bir lojistik operasyonun ölçeğinde ise polling, son derece düşük sinyal-gürültü oranıyla önemli miktarda API çağrısı üretir. Yanıtların büyük çoğunluğu değişiklik olmadığını bildirecektir.

Sorun yapısaldır; aralığı ayarlamak meselesi değil. Daha sık polling, olay ile tespit arasındaki gecikmeyi azaltır; ancak API çağrısı tüketimi ve işlem yükü pahasına. Daha az sık polling daha ucuzdur; fakat tespit penceresini genişletir. Hiçbir ayar, operasyon ekiplerinin gerçekten istediğini üretmez: bir şey olduğunda anında bildirim.

Taşıyıcı API hız limitleri ek bir kısıt oluşturur. Birden fazla taşıyıcıya karşı eş zamanlı yüksek frekanslı polling, yoğun polling göz önünde bulundurularak tasarlanmamış taşıyıcı başına limitleriyle çarpışır. Geliştirme ortamında basit görünen mimari, üretim ölçeğinde operasyonel olarak kırılgan hale gelir.

Olay Güdümlü Alternatif

Webhook'lar veri akışını tersine çevirir. Tüketen sistemin "bir şey değişti mi?" diye sorması yerine, taşıyıcı veya takip platformu bir olay kaydedildiği anda bildirim gönderir. Tüketen sistem yalnızca işlenecek veri olduğunda veri işler.

Özellikle sevkiyat takibi açısından bu, teslimat onayının, istisna bayrağının veya gecikme bildiriminin taşıyıcının bunu kaydetmesinden saniyeler veya dakikalar içinde ERP'ye veya görünürlük platformuna ulaşması anlamına gelir — bir sonraki zamanlanmış toplu aralıkta değil. Müşteri hizmetleri ekipleri, sistematik olarak müşterilerden sonra değil, onlardan önce veya aynı anda bilgiye erişir.

Kaynak açısından fark anlamlıdır. Olay güdümlü bir mimari, API bant genişliğini polling frekansı yerine gerçek olay hacmiyle orantılı biçimde tüketir. Sessiz bir gün, yoğun bir sevkiyat gününden daha az bildirim üretir ve sistem gerçek aktiviteyle doğal olarak ölçeklenir.

Güvenilir Bir Webhook Pipeline'ı Tasarlamak

Webhook güvenilirliği kendi mühendislik gereksinimlerini beraberinde getirir. Taşıyıcı tarafından gönderilen olaylar eş zamansız ve garantili sıralama olmadan gelir. Alıcı tarafta geçici bir ağ arızasından sonra taşıyıcının yeniden deneme mantığı devreye girirse aynı olay birden fazla kez gelebilir. Tüketen sistemin her iki koşulu da ele alması gerekir.

Idempotency temel tasarım ilkesidir. Her gelen olay benzersiz bir tanımlayıcı taşımalı ve alıcı sistem üzerinde harekete geçmeden önce bu tanımlayıcının zaten işlenip işlenmediğini kontrol etmelidir. Yinelenen olaylar yinelenen kayıtlar oluşturmak yerine sessizce atılmalıdır.

Sıralama varsayılamaz. Ağ koşullarına ve yeniden deneme davranışına bağlı olarak "teslim edildi" olayı mesaj kuyruğuna kendisinden önce gelen "teslimatta" olayından önce gelebilir. Veri modeli sıra dışı gelişleri barındırabilmelidir — olayları varış zaman damgalarıyla değil taşıyıcının bildirdiği zaman damgalarıyla kaydederek ve görüntüleme katmanının olayları doğru kronolojik sırayla sıralayabilmesine izin vererek.

Birinci Sınıf Kullanım Senaryosu Olarak İstisna Yönetimi

Gerçek zamanlı webhook entegrasyonunun operasyonel açıdan en değerli uygulaması istisna yönetimidir. Teslimat istisnaları, adres doğrulama hataları, gümrük beklemeleri ve hava koşullarından kaynaklanan gecikmeler — bunların tümü, erken bildirimin anlamlı operasyonel bir yanıt mümkün kıldığı koşulları temsil eder: yeniden sevkiyat başlatma, müşteri iletişimi, taşıyıcı eskalasyonu. Bunların saatler sonra keşfedilmesi ya imkânsız ya da pahalı hale gelir.

Proaktif istisna bildirimi, müşteri deneyimini asimetrik biçimde dönüştürür. Paketi geç fark etmeden önce gecikmeyi açıklayan otomatik bir mesaj alan müşteri, acentenin aynı anda ilk kez öğrendiği bilgiyi almak için müşteri hizmetleri hattını arayan müşteriden temelden farklı bir deneyim yaşar.

Kontrol Kulesi Perspektifi

Birden fazla taşıyıcı ve mod genelinde sevkiyatları yöneten operasyon ekipleri için mimari soru, tek bir taşıyıcı entegrasyonu için polling'i webhook'larla değiştirmekten ibaret değildir. Farklı kaynaklardan — taşıyıcı webhook'ları, takip platformu bildirimleri, gümrük durum API'leri — gelen olayları tutarlı bir iç temsile alabilecek, normalleştirebilecek ve yönlendirebilecek bir olay alım katmanı oluşturmakla ilgilidir.

Normalleştirme adımı, çok taşıyıcılı görünürlük platformlarının kalıcı değer kattığı yerdir. Taşıyıcı olay şemaları, bir taşıyıcının "teslim edildi" olayının farklı alan adları, zaman damgası biçimleri ve durum kodlarıyla geldiği ölçüde farklılık gösterir. Bunları ERP'ye veya müşteriye yönelik arayüze ulaşmadan önce tutarlı bir kilometre taşı modeline normalleştirmek, olay güdümlü mimariyi yalnızca daha hızlı değil gerçekten kullanışlı kılar. Taşıyıcı başına manuel yorum gerektiren gerçek zamanlı veri, amacın büyük bölümünü ortadan kaldırır.

Kaynak: Houseblend