Collegare un software di IA a Oracle OPERA Cloud attraverso OHIP è, meccanicamente, ben documentato. Oracle pubblica le specifiche API, il flusso di autenticazione è standard OAuth 2.0, e la maggior parte dei fornitori può ottenere una chiamata sandbox che restituisce i dati entro un giorno. I problemi che effettivamente ostacolano questi progetti raramente si manifestano in quella fase. Si presentano da due a sei settimane dopo, una volta che ci sono vere prenotazioni, piani di tariffe veri e personale della reception.
Questo articolo riguarda quei problemi: quelli che si estendono dopo la demo funziona, non prima di esso.
L’ampliamento dell’ambito del progetto nascosto nella configurazione tecnica
L'accesso all'OIPS non è concesso come autorizzazione generale. Oracle rilascia diritti per famiglia di API, per proprietà e spesso per caso d'uso descritto nella registrazione dell'app. Un fornitore potrebbe richiedere l'accesso ai dati di prenotazione e profilo, ottenere l'approvazione, costruire l'integrazione, e poi scoprire a metà progetto che hanno anche bisogno di dati sullo stato del foglio o della pulizia per fornire la funzionalità che l'hotel ha effettivamente chiesto.
Ogni diritto aggiuntivo può significare un altro riesame della certificazione, e i tempi di certificazione sono misurati in settimane, non giorni. Le proprietà che presuppongono "siamo già connessi, aggiungere un altro campo è banale" sono di solito sbagliate. La soluzione è mappare ogni elemento di dati che il livello IA tocca prima di inviare la richiesta di diritto, non dopo. Se il livello di intelligence deve attivare un flusso di lavoro di ripristino del servizio, questo include lo stato della prenotazione, il profilo degli ospiti e talvolta i dati di fatturazione, e tutti e tre dovrebbero essere esaminati in anticipo.
Mappature dei dati apparentemente uguali, ma diverse
Due proprietà OPERA Cloud sullo stesso codice di catena possono utilizzare valori di stato di prenotazione diversi, tassonomie di codici tariffari diverse e codici di blocco o gruppo diversi, soprattutto se una proprietà è stata migrata da un PMS legacy ed ha ereditato la vecchia configurazione. Un'integrazione costruita e testata contro i dati di una proprietà può silenziosamente fallire nella successiva.
Esempi comuni:
- Uno stato "Due In" che significa qualcosa di leggermente diverso una volta che una proprietà consente prenotazioni split-stay
- Codici di tariffazione che codificano le inclusioni del pacchetto nella stringa di codice stessa, che un livello AI potrebbe analizzare letteralmente invece di cercare la definizione del pacchetto collegato
- Logic di fusione del profilo ospite che si comporta in modo diverso a seconda che la corrispondenza fedeltà sia abilitata in quella proprietà
Niente di tutto questo e' un bug nell'OHP. È la varianza di configurazione che il livello di integrazione deve tenere conto esplicitamente, proprietà per proprietà, piuttosto che assumere un unico schema applicabile ovunque. I team che costruiscono uno strato di mappatura sottile e specifico per le proprietà tra i dati PMS grezzi e il proprio modello interno tendono a evitarlo. Le squadre che codificano le ipotesi dalla prima proprietà che collegano tendono a scoprirlo nel modo più difficile alla proprietà due.
Tempi di sincronizzazione e gestione delle brevi indisponibilità del PMS
L'OIPS supporta sia le notifiche basate su sondaggi che sulle notifiche basate su eventi, e la scelta è più importante di quanto sembri. Il sondaggio su un intervallo fisso è semplice ma introduce una finestra di ritardo durante la quale lo strato AI agisce sui dati obsoleti. Le notifiche di eventi riducono questo ritardo, ma richiedono l'integrazione per gestire la consegna fuori ordine, gli eventi duplicati e la logica di riconnessione dopo una connessione interrotta.
La trappola non e' scegliere lo schema sbagliato. Non si sta pianificando che il PMS sia irraggiungibile, anche solo brevemente, durante una finestra di manutenzione o un problema di rete sul lato della proprietà. Una richiesta di invito indirizzata attraverso un livello di IA che presuppone che il PMS sia sempre raggiungibile può fallire silenziosamente, essere registrata come irrisolta o peggio, essere duplicata una volta che la connettività ritorna.
La domanda che vale la pena porre a qualsiasi fornitore prima di andare in onda non è "si connette", ma "cosa fa per i novanta secondi dopo che non può".
Questo è uno dei motivi per cui Hermes, il livello di gestione alberghiera di GadgetMall, tratta ogni chiamata PMS come qualcosa che può fallire e mette in coda le azioni con i tasti idempotency piuttosto che sparare una volta e andare avanti. E' una piccola scelta di design, ma e' la differenza tra una richiesta guest che scompare silenziosamente e quella che viene riprovata automaticamente una volta ripristinata la connessione.
Nessun responsabile definito dopo l’avvio
L'ultimo punto di guasto comune non è affatto tecnico. Una volta che un'integrazione è attiva, chi è responsabile quando una mappatura si interrompe dopo un aggiornamento di OPERA Cloud, o quando Oracle depreca una versione API? Spesso la risposta è nessuno, perché il contatto IT dell'hotel ha ipotizzato che il venditore lo possiede, e il venditore ha ipotizzato che l'amministratore PMS della struttura segnerà le modifiche di configurazione.
Oracle fa la versione dei propri endpoint OHIP e avvisa in anticipo di deprecazioni, ma quella notifica va a chiunque abbia registrato l'app, e i gruppi multi-proprietà a volte perdono la traccia di chi sia dopo il rotazione del personale. Una semplice mitigazione è assegnare un proprietario nominato su entrambi i lati al go-live, registrare ogni diritto e versione API in un documento condiviso e rivisitarlo al rinnovo, non solo quando qualcosa si rompe.
Il problema di fondo comune a tutti questi casi
Ogni trappola di cui sopra risale alla stessa causa: trattare l'integrazione come un compito tecnico una tantum piuttosto che come una relazione operativa continua tra due sistemi che cambiano continuamente. Oracle aggiorna OPERA Cloud. Le proprietà cambiano configurazione. I venditori aggiungono delle funzionalità. Un'integrazione costruita per sopravvivere a quella deriva, con una portata esplicita, una mappatura consapevole delle proprietà e un comportamento di fallimento definito, tende ad essere noiosa nel miglior modo possibile. Quelli che saltano questi passaggi tendono a funzionare perfettamente nella demo e causano un ticket di supporto tre settimane dopo.