Bir yapay zeka yazılımı parçasını Oracle OPERA Cloud'a OHIP aracılığıyla bağlamak, mekanik olarak iyi bir şekilde belgelenmiştir. Oracle, API spesifikasyonlarını yayınlar, kimlik doğrulama akışı standart OAuth 2.0'dır ve çoğu satıcı, verileri bir gün içinde döndüren bir korumalı alan çağrısı alabilir. Bu projeleri raydan çıkaran sorunlar nadiren bu aşamada ortaya çıkar. Gerçek rezervasyonlar, gerçek fiyat planları ve gerçek ön büro personeli işin içine girdiğinde, iki ila altı hafta sonra ortaya çıkarlar.
Bu makale bu sorunlarla ilgilidir: demo çalışmadan önce değil, demo çalıştıktan sonra ortaya çıkan sorunlar.
Teknik bir kurulum olarak gizlenen kapsam kayması
OHIP erişimi genel izin olarak verilmemektedir. Oracle, yetkileri API ailesi başına, mülk başına ve genellikle uygulama kaydında açıklanan kullanım senaryosuna göre verir. Bir satıcı, rezervasyon ve profil verilerine erişim talep edebilir, onay alabilir, entegrasyonu oluşturabilir ve ardından projenin ortasında, otelin gerçekte istediği özelliği sunmak için folio veya kat hizmetleri durum verilerine de ihtiyaç duyduğunu keşfedebilir.
Her ek yetki, başka bir sertifikasyon incelemesi anlamına gelebilir ve sertifikasyon zaman çizelgeleri günlerle değil haftalarla ölçülür. "Zaten bağlıyız, bir alan daha eklemenin önemsiz olduğunu" varsayan özellikler genellikle yanlıştır. Çözüm, yapay zeka katmanının dokunacağı her veri öğesini, yetkilendirme talebini göndermeden önce değil, haritalandırmaktır. İstihbarat katmanının, rezervasyon durumunu, misafir profilini ve bazen faturalandırma verilerini içeren bir hizmet kurtarma iş akışını tetiklemesi gerekiyorsa, bu üçünün de kapsamı önceden belirlenmelidir.
Aynı görünen ancak aynı olmayan veri eşleme
Aynı zincir kodundaki iki OPERA Cloud mülkü, özellikle bir mülk eski bir PMS'den taşınmışsa ve eski konfigürasyonu devralmışsa, farklı rezervasyon durumu değerleri, farklı ücret kodu sınıflandırmaları ve farklı blok veya grup kodları kullanabilir. Bir mülkün verilerine göre oluşturulan ve test edilen bir entegrasyon, bir sonraki mülkte sessizce başarısızlığa neden olabilir.
Yaygın örnekler:
- Bir tesisin bölünmüş konaklama rezervasyonlarını etkinleştirmesinden sonra biraz farklı bir anlama gelen "Son Teslim Tarihi" durumu
- Bir AI katmanının bağlantılı paket tanımına bakmak yerine kelimenin tam anlamıyla ayrıştırabileceği, kod dizesinin kendisindeki paket içeriklerini kodlayan hız kodları
- Söz konusu tesiste sadakat eşleştirmenin etkin olup olmadığına bağlı olarak farklı davranan konuk profili birleştirme mantığı
Bunların hiçbiri OHIP'te bir hata değildir. Tek bir şemanın her yerde geçerli olduğunu varsaymak yerine, entegrasyon katmanının, özellik bazında açıkça hesaba katması gereken şey, konfigürasyon varyansıdır. Ham PMS verileri ile kendi dahili modelleri arasında ince, özelliğe özgü bir haritalama katmanı oluşturan ekipler genellikle bundan kaçınır. Bağlandıkları ilk özellikten varsayımları sabit kodlayan ekipler, ikinci özellikte zor yolu bulma eğilimindedir.
Senkronizasyon zamanlaması ve PMS kısa süreliğine kullanılamadığında ne olur?
OHIP hem yoklamayı hem de olaya dayalı bildirimleri destekler ve seçim göründüğünden daha önemlidir. Sabit bir aralıkta yoklama basittir ancak yapay zeka katmanının eski veriler üzerinde hareket ettiği bir gecikme penceresi ortaya çıkarır. Olay bildirimleri bu gecikmeyi azaltır ancak sıra dışı teslimatı, yinelenen olayları ve bağlantı kesildikten sonra yeniden bağlanma mantığını ele almak için entegrasyon gerektirir.
Buradaki tuzak yanlış modeli seçmek değil. Bir bakım penceresi veya mülk tarafında bir ağ kesintisi sırasında PMS'nin kısa süreliğine bile olsa erişilemez olmasını planlamıyor. PMS'nin her zaman erişilebilir olduğunu varsayan bir yapay zeka katmanı üzerinden yönlendirilen bir misafir isteği, sessizce başarısız olabilir, çözümlenmemiş olarak günlüğe kaydedilebilir veya daha kötüsü, bağlantı geri geldiğinde kopyalanabilir.
Canlı yayına geçmeden önce herhangi bir satıcıya sorulmaya değer soru "bağlanıyor mu" değil, "bağlanamadığı doksan saniye boyunca ne yapıyor?"
GadgetMall'ın otel operasyonları katmanı olan Hermes'in, her PMS çağrısını başarısız olabilecek bir şey olarak ele almasının ve bir kez tetiklenip devam etmek yerine eylemleri kimlik anahtarlarıyla sıraya koymasının nedenlerinden biri de budur. Bu küçük bir tasarım seçeneğidir, ancak misafir isteğinin sessizce kaybolması ile bağlantı yeniden kurulduğunda otomatik olarak yeniden denenmesi arasındaki farktır.
Canlı yayına geçtikten sonra net bir sahip yok
Son yaygın başarısızlık noktası hiç de teknik değildir. Entegrasyon yayına girdikten sonra, OPERA Bulut güncellemesinden sonra eşleme bozulduğunda veya Oracle bir API sürümünü kullanımdan kaldırdığında kim sorumlu olur? Çoğu zaman cevap hiç kimsedir, çünkü otelin BT sorumlusu otelin sahibi olduğunu varsayıyordu ve satıcı da mülkün PMS yöneticisinin yapılandırma değişikliklerini işaretleyeceğini varsayıyordu.
Oracle, OHIP uç noktalarının sürümlerini hazırlıyor ve kullanımdan kaldırılmalara ilişkin önceden bildirimde bulunuyor ancak bu bildirim, uygulamayı kaydeden kişiye gider ve çok mülklü gruplar bazen personel değişiminden sonra bu kişinin kim olduğunun izini kaybeder. Bu durumu hafifletmenin basit bir yolu, canlı yayına geçiş sırasında her iki tarafa da adlandırılmış bir sahip atamak, her yetkilendirmeyi ve API sürümünü paylaşılan bir belgeye kaydetmek ve yalnızca bir sorun olduğunda değil, yenileme sırasında da belgeyi yeniden ziyaret etmektir.
Bütün bunların altındaki desen
Yukarıdaki her tuzak aynı temel nedene dayanmaktadır: Entegrasyonu, her ikisi de değişmeye devam eden iki sistem arasında devam eden operasyonel bir ilişki olarak değil, tek seferlik bir teknik görev olarak ele almak. Oracle, OPERA Cloud'u güncelliyor. Özellikler yapılandırmayı değiştirir. Satıcılar özellikler ekler. Bu sürüklenmeden kurtulmak için açık kapsam, özelliğe duyarlı haritalama ve tanımlanmış arıza davranışı ile inşa edilen bir entegrasyon, mümkün olan en iyi şekilde sıkıcı olma eğilimindedir. Bu adımları atlayanlar genellikle demoda mükemmel şekilde çalışır ve üç hafta sonra bir destek bildirimine neden olurlar.