Intégration XML — tout PMS

Bridg_ expose un modèle d'intégration XML on-premise : le dialecte XML Fidelio. Il n'est pas réservé à Oracle OPERA (OXI) — c'est le cas le plus courant, mais tout PMS ou CRS capable d'émettre et de lire ce dialecte peut se connecter. Le principe est le même pour tous : toutes les connexions partent de votre système. Bridg_ n'appelle jamais votre PMS ; votre PMS pousse ses messages vers Bridg_ et vient chercher ceux de Bridg_. Aucune adresse publique ni ouverture de pare-feu n'est nécessaire de votre côté.

Cette page est l'entrée vendor : onboarding, topologie, authentification, enveloppe et types de message. Le format détaillé de chaque message (champs, exemples, codes d'erreur) est décrit dans les pages de référence liées en bas.

Se connecter en 3 étapes

1. Obtenir une connexion. Bridg_ vous fournit l'URL de base {base}, un connectionId et un secret (le secret n'est affiché qu'une seule fois, comme une clé d'API). La connexion reste en statut PENDING pendant toute l'intégration : elle accepte et traite vos messages entrants, sans rien émettre en retour tant qu'elle n'est pas activée.
2. Mapper vos codes. Associez vos codes de types de chambre (UNIT_TYPE) et de plans tarifaires (RATE_PLAN) aux identifiants Bridg_. Bridg_ ne crée jamais de référentiel à partir d'un message : un code non mappé est refusé, l'item par item, avec le code fautif dans le journal.
3. Échanger. Vous poussez vos messages en POST et venez chercher les nôtres en GET, sur une seule URL (ci-dessous). Vous êtes toujours le client.

Topologie

                         POST …/messages?key=<secret>   (vous envoyez : ARI, réservations, RESULT)
   Votre PMS / CRS ──────────────────────────────────────▶  Bridg_
   Votre PMS / CRS ◀──────────────────────────────────────  Bridg_
                         GET  …/messages?key=<secret>    (vous venez chercher : réservations, RESULT)

Une seule URL à configurer, pour l'envoi comme pour la réception :

{base}/api/pms/v1/connections/{connectionId}/messages

Authentification

Deux schémas sont acceptés sur chaque appel ; le premier est recommandé pour les systèmes dont le client HTTP ne permet pas d'ajouter d'en-têtes personnalisés.

• Si key est présent dans l'URL, il est seul évalué.
• Un système peut ajouter ses propres paramètres de query (par ex. &propertyName=<code>&zipData=N) ; ils sont acceptés et ignorés.
• 401 UNAUTHORIZED si la clé, l'identifiant ou le mot de passe est faux ; 404 si le connectionId est inconnu ; 403 CONNECTION_INACTIVE si la connexion est en pause.

L'enveloppe <?Label ?>

Tout message, dans les deux sens, commence par la déclaration XML puis l'instruction de traitement Label, qui sert au routage :

<?xml version="1.0" encoding="UTF-8"?>
<?Label HOTEL1|RTAV|2841178|NEW?>

Types de message

Un message d'un type non supporté est acquitté par un RESULT d'échec (réponse HTTP 200), jamais par un 4xx : votre file n'est pas bloquée, et le refus apparaît dans le journal.

Envoyer un message

Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<?Label HOTEL1|RTAV|2841178|NEW?>
<RtavMessage xmlns="rtav.fidelio.4.0">
  <HotelReference hotelCode="HOTEL1"/>
  <DailyInventories>
    <DailyInventory datum="2026-10-10">
      <RoomTypeInventories>
        <RoomTypeInventory roomType="DLX" available="12"/>
      </RoomTypeInventories>
    </DailyInventory>
  </DailyInventories>
</RtavMessage>

La réponse HTTP n'accuse que la réception (200). Le verdict de traitement est un RESULT asynchrone, mis en file et récupéré par GET. Un 500 signale un échec transitoire : conservez le message et réémettez-le après un délai.

Récupérer le prochain message

Vous venez chercher, un message par appel, en FIFO : réservations et accusés RESULT des messages que vous avez envoyés.

• Message en attente → 200, corps XML, en-tête HTTP title reprenant l'enveloppe (routage sans parser le corps).
• Rien en attente → 200 avec un corps vide et Content-Length: 0 (jamais un 204).
• Rythme conseillé : interroger toutes les 30 à 120 s ; après un message servi, ré-interroger immédiatement jusqu'à obtenir un corps vide.

Conventions de dates

Détail des messages

Le format complet de chaque message — champs requis, traduction, exemples XML et codes d'erreur — est décrit dans les pages de référence du modèle XML :

• API Reference XML — enveloppe, envoi et récupération, accusés RESULT, codes d'erreur.
• Messages ARI — RTAV (disponibilité), RATE (prix), RAVL et RESTRICTION (restrictions).
• Réservations et accusés — RESERVATION dans les deux sens, RESULT, MESSAGEREQUEST.

Limites connues

Refusées volontairement plutôt que traduites à moitié — un item refusé est toujours journalisé, jamais perdu en silence.

• Tarifs par durée de séjour (tiered) et prix week-end : refusés.
• Restrictions par classe de chambre, catégorie de tarif, hôtel entier ou bloc : refusées.
• RAVR (restriction par type de chambre sans tarif) : refusé — passez par RAVL ou RESTRICTION.
• Prix : seule l'occupation double est distribuée aujourd'hui.