Connecter un logiciel d'IA à Oracle OPERA Cloud via OHIP est, mécaniquement, bien documenté. Oracle publie les spécifications de l'API, le flux d'authentification est OAuth 2.0 standard et la plupart des fournisseurs peuvent obtenir un appel sandbox renvoyant des données en une journée. Les problèmes qui font dérailler ces projets apparaissent rarement à ce stade. Ils arrivent deux à six semaines plus tard, une fois que les réservations sont réelles, les tarifs réels, et le personnel de réception réel est impliqué.
Cet article traite de ces problèmes : ceux qui se présentent après le travail de la démo, pas avant.
Champ d'application de fluage déguisé en une configuration technique
L'accès au PSSI n'est pas accordé comme autorisation générale. Oracle émet des droits par famille d'API, par propriété et souvent par cas d'utilisation décrit dans l'enregistrement de l'application. Un fournisseur peut demander l'accès aux données de réservation et de profil, obtenir l'approbation, construire l'intégration, puis découvrir à mi-projet qu'il a également besoin de données sur le statut du folio ou de la ménage pour fournir la fonctionnalité que l'hôtel a réellement demandée.
Chaque admissibilité supplémentaire peut signifier une autre révision de la certification, et les délais de certification sont mesurés en semaines, pas en jours. Les propriétés qui supposent "nous sommes déjà connectés, ajouter un champ de plus est trivial" sont généralement fausses. La solution est de cartographier chaque élément de données que la couche IA touchera avant de soumettre la demande d'autorisation, pas après. Si la couche de renseignement doit déclencher un flux de travail de récupération de service, cela implique l'état de la réservation, le profil des clients et parfois les données de facturation, et tous les trois devraient être examinés à l'avance.
Cartographie de données qui semble identique mais n'est pas
Deux établissements OPERA Cloud utilisant le même code de chaîne peuvent avoir des valeurs de statut de réservation, des classifications tarifaires et des codes de blocs ou de groupes différents. C’est particulièrement fréquent lorsque l’un d’eux a migré depuis un ancien PMS et conservé une configuration historique. Une intégration développée et testée avec les données d’un établissement peut donc dysfonctionner discrètement dans le suivant.
Exemples communs:
- Un statut « Due In » qui signifie quelque chose de légèrement différent une fois qu'une propriété permet des réservations de séjour partagé
- Les codes de taux qui codent les inclusions de paquets dans la chaîne de code elle-même, qu'une couche d'IA pourrait analyser littéralement au lieu de rechercher la définition du paquet lié.
- Logic de fusion du profil d'invité qui se comporte différemment selon que la correspondance de fidélité est activée sur cette propriété
Rien de tout ça n'est un bug dans le système de santé publique. C'est la variance de configuration que la couche d'intégration doit prendre en compte explicitement, propriété par propriété, plutôt que de supposer qu'un schéma unique s'applique partout. Les équipes qui construisent une couche de cartographie mince et spécifique à la propriété entre les données brutes du PMS et leur propre modèle interne ont tendance à éviter cela. Les équipes qui codent durement des hypothèses à partir de la première propriété qu'elles ont connectée ont tendance à le découvrir de la manière la plus difficile à la deuxième propriété.
Synchronisation et ce qui se passe lorsque le SPM est brièvement indisponible
L'OSPI prend en charge les avis basés sur les sondages et les notifications basées sur les événements, et le choix est plus important qu'il n'y paraît. Le sondage à intervalles fixes est simple mais introduit une fenêtre de décalage au cours de laquelle la couche IA agit sur des données obsolètes. Les notifications d'événements réduisent ce décalage, mais nécessitent l'intégration pour gérer la livraison hors-ordre, les événements en double et la logique de reconnexion après une connexion interrompue.
Le piège n'est pas de choisir le mauvais motif. Il ne prévoit pas que le PMS soit inaccessible, même brièvement, pendant une fenêtre de maintenance ou un blocage du réseau sur le côté de la propriété. Une demande d'invité acheminée à travers une couche d'IA qui suppose que le PMS est toujours accessible peut échouer silencieusement, être enregistrée comme non résolue ou pire, se dupliquer une fois la connectivité rétablie.
La question à poser à n'importe quel fournisseur avant de commencer à fonctionner n'est pas "se connecte-t-il", mais "que fait-il pendant les 90 secondes après qu'il ne peut pas".
C’est l’une des raisons pour lesquelles Hermes, la couche d’opérations hôtelières de GadgetMall, considère que chaque appel au PMS peut échouer. Les actions sont mises en file d’attente avec des clés d’idempotence, au lieu d’être envoyées une seule fois puis oubliées. Ce choix de conception peut sembler mineur, mais il fait la différence entre une demande client qui disparaît sans bruit et une demande relancée automatiquement dès que la connexion est rétablie.
Pas de propriétaire clair après le départ
Le dernier point commun de défaillance n'est pas du tout technique. Une fois l'intégration mise en ligne, qui est responsable lorsqu'une mapping tombe en panne après une mise à jour OPERA Cloud, ou quand Oracle déprécie une version d'API ? Souvent, la réponse est personne, parce que le contact informatique de l'hôtel a supposé que le fournisseur en était le propriétaire, et le fournisseur a supposé que l'administrateur du PMS de l'établissement signalerait les modifications de configuration.
Oracle fait des versions de ses endpoints OHIP et prévient les dépréciations, mais cette notification va à celui qui a enregistré l'application, et les groupes multi-propriétés perdent parfois la trace de qui c'est après le roulement du personnel. Une solution simple consiste à attribuer un propriétaire nommé aux deux côtés lors de la mise en ligne, à enregistrer chaque version d'API et de droits dans un document partagé et à le revisiter au renouvellement, pas seulement lorsque quelque chose se casse.
Le modèle sous tous ces
Chaque piège ci-dessus remonte à la même cause: traiter l'intégration comme une tâche technique ponctuelle plutôt que comme une relation opérationnelle continue entre deux systèmes qui changent constamment. Oracle met à jour OPERA Cloud. Les propriétés changent de configuration. Les fournisseurs ajoutent des fonctionnalités. Une intégration construite pour survivre à cette dérive, avec une portée explicite, une cartographie consciente des propriétés et un comportement de défaillance défini, a tendance à être ennuyeuse de la meilleure façon possible. Ceux qui sautent ces étapes ont tendance à fonctionner parfaitement dans la démo et provoquent un ticket de support trois semaines plus tard.