API, webhook i iCal: što se prenosi i kako otkriti pogrešku

Problem iz poslovanja

Na zaslonu piše da su sustavi povezani, ali otkaz nije oslobodio termin ili je ista rezervacija unesena dvaput. Vlasnik ne zna razlikovati problem prijenosa od pogrešnog preslikavanja, niti može dobavljaču dati dovoljno precizan zapis za rješavanje.

Nakon lekcije moći ćete

• Razumjeti razliku između kalendarskog prijenosa i drugih integracijskih mehanizama.
• Prepoznati ponovljeni, zakašnjeli ili nedostajući događaj.
• Definirati usklađivanje i eskalaciju bez samostalnog rizičnog programiranja.

Način povezivanja nije obećanje o opsegu

API je dogovoreni način kojim sustavi razmjenjuju zahtjeve i odgovore. Webhook je obavijest koju sustav šalje drugome kada nastane određeni događaj, ako proizvod takav mehanizam podržava. iCal je kalendarski format i veza se često koristi za prijenos blokiranih razdoblja. Nijedan naziv sam ne govori prenose li se cijene, broj gostiju, status plaćanja ili sve izmjene. Tražite popis podržanih polja, smjerove, ograničenja, očekivano osvježavanje i postupak pri prekidu. Nemojte iCal tretirati kao potpunu zamjenu za svaku integraciju.

Ponovljena poruka ne smije stvoriti novi boravak

Sustavi ponekad ponovno šalju ili dohvaćaju isti događaj. Obrada treba prepoznati da je događaj već evidentiran i ne stvoriti drugu rezervaciju. To se u tehničkoj komunikaciji naziva idempotentnim ponašanjem: ponavljanje iste radnje s istom oznakom ne smije nekontrolirano ponoviti poslovni učinak. Vlasnik ne mora pisati kod, ali treba zahtijevati dokaz takvog testa. Bookingova dokumentacija za određeni OTA XML tijek izričito upozorava na ponovljeno vraćanje nepotvrđenih rezervacija. Ne prenosite tu točnu tehničku izvedbu na svaki drugi proizvod.

Odvojite slanje, primitak i poslovnu potvrdu

U evidenciji razlikujte vrijeme nastanka događaja, slanja, prihvata i vidljivog poslovnog ishoda. Prihvaćena mrežna poruka ne dokazuje da je cijena ispravno primijenjena na odgovarajući objekt. Za izmjene pratite jedinstvenu oznaku rezervacije i inačicu ili vrijeme izmjene kada su dostupni. Zatražite da dobavljač objasni kako rješava zakašnjelu staru poruku nakon novije izmjene. Cilj je spriječiti da stari datum ponovno prepiše potvrđeni novi boravak. Upozorenje mora stići osobi koja može poduzeti radnju, ne samo ostati u tehničkom dnevniku.

Usklađivanje je zaseban poslovni postupak

Periodično usporedite mjerodavne rezervacije s odredišnim sustavom prema dogovorenom opsegu, osobito nakon prekida veze. Za razliku zapišite objekt, oznaku rezervacije bez nepotrebnih osobnih podataka, izvorni status, očekivani status i vremena. Tim provjerava stanje u službenom računu prije ručnog otvaranja termina. Ako postoji rizik dvostruke prodaje, odgovorna osoba primjenjuje unaprijed dogovorenu privremenu mjeru u podržanom sustavu. Ručna intervencija mora biti zabilježena kako je kasnije automatsko ponovno slanje ne bi poništilo ili dupliciralo.

Postupak rješavanja

1. Za svaku vezu popišite podatke, smjer, očekivano osvježavanje, vlasnika i službeni kontakt podrške.

2. S dobavljačem isprobajte novi događaj, izmjenu, otkaz, duplikat i povrat nakon prekida u podržanom testnom postupku.

3. Dogovorite jedinstvene oznake i evidenciju vremena koje tim može dostaviti podršci.

4. Uvedite usporedbu stanja nakon prekida te zapis svake ručne korekcije i naknadne potvrde.

Primjena prema vrsti poslovanja

Pogreške koje treba izbjeći

• Obećavati trenutačno osvježavanje bez potvrđene tehničke i poslovne osnove.
• Ručno unositi rezervaciju bez provjere postoji li već pod drugom oznakom.
• Zatvoriti incident prije usporedbe konačnog stanja u oba sustava.

Vaš praktični zadatak

Izradite karticu jedne stvarne veze. Na izmišljenom primjeru opišite kako biste otkrili duplikat i što biste provjerili prije ručnog oslobađanja termina. Zapišite podatke koje trebate od podrške, bez lozinki i podataka kartice gosta.