🇸🇮 Prva prava strojna poizvedba preko naše relejne postaje

CM Relay: prva prava cena je pristala pri OTA ponudniku

Pred dobrim mesecem smo v članku o CM Ekosistemu zapisali stavek, ki je takrat zvenel bolj kot vizija kot kot dejstvo: *"Relay lahko v prihodnosti skrbi za povezovanje z Booking.com in Airbnb."*

Ta teden je ta stavek prvič postal resničen — ne na papirju, ampak v pravem API klicu.

Kaj se je dejansko zgodilo: admin je v pravem CM adminu spremenil ceno enote. Ta sprememba je sama, brez ročnega posredovanja, potovala skozi lokalni CM Connector, prek CM Relaya, do Channexovega API-ja — enega od kanalov, ki povezuje Channel Managerje z Booking.com in Airbnb. Cena je pristala tam, kjer bi morala, in smo jo neodvisno preverili nazaj.

To je prvič, da je celotna pot — od pravega klika v adminu do zunanjega OTA sistema — dejansko delovala od začetka do konca.

Kako je to sploh zgrajeno

Arhitektura sledi istemu pravilu, ki smo ga zapisali že v prvem članku: lokalni CM ostaja lastnik svojih podatkov. CM Relay ni drug rezervacijski sistem — je prevajalna in usmerjevalna plast med lokalno namestitvijo in enim samim OTA računom.

Nekaj konkretnih odločitev, ki so danes že zgrajene in preverjene:

• Vsaka CM namestitev ima svoj varnostni žeton, brez skupne "glavne gesla" za vse.
• En sam OTA račun lahko servisira več neodvisnih namestitev hkrati, brez mešanja podatkov med njimi — to smo preverili na petih ločenih testnih namestitvah.
• Sistem spoštuje omejitev števila API klicev na minuto, ki jo OTA ponudnik postavlja za cel račun, ne za posamezno namestitev.
• Podatki se pošiljajo v paketih (več datumov v enem klicu), ne v zanki — enako, kot to zahtevajo resnične certifikacijske smernice OTA ponudnikov.

Kar (še) ne deluje — in zakaj to povemo na glas

V duhu, ki ga na tem Journalu gojimo od začetka — raje pošteno kot lepo — moramo povedati tudi to: zapiranje datuma pri OTA ponudniku deluje zanesljivo, odpiranje pa (še) ne. To nismo ugotovili na hitro, ampak z več izoliranimi testi na povsem svežih datumih. Gre za posebnost na strani zunanjega sistema, ne za napako v naši kodi — in smo jo že prijavili njihovi podpori.

Zakaj to sploh omenjamo v javnem članku? Ker je CM Ekosistem od začetka grajen na načelu, da mora ICS sinhronizacija ostati varnostna mreža, ne glede na to, kaj se dogaja z naprednejšo API povezavo. Ta primer je natanko razlog, zakaj to pravilo obstaja — API se lahko obnaša nepredvidljivo, tudi na strani velikih ponudnikov, in lokalni CM mora vseeno naprej delovati.

Preden gremo v pravo, plačljivo povezavo z OTA ponudnikom, čaka nas še nekaj korakov: sprejemanje rezervacij nazaj (ne samo pošiljanje cen ven), in odgovor podpore na zgornjo posebnost. Cenovni model za tiste, ki bi se kdaj pridružili prek istega Relaya, je že postavljen — po principu, da naj prihodek pokrije stroške in vzdrževanje, ne dobička na tuj račun.

Morda gradimo samo boljši most do Booking.com in Airbnb. Morda pa je to prvi pravi dokaz, da Relay dejansko drži, kar obljublja.