Ero on ensisijaisesti ajoituksessa
Toimituskunta julkaisee tarkistetun neuvontakeskuksen klo 10.14. Verkkosivuston on näytettävä uusi puhelinnumero välittömästi, portaalin hakukoneen on päivitettävä hakemistonsa ja ymmärrettävä kieliversio vaatii myöhemmin ammattilaisen tarkistuksen. Nämä seuraukset ovat osa samaa muutosta, mutta niitä kaikkia ei tarvitse käsitellä samanaikaisesti.
Webhook on viesti, jonka yksi järjestelmä lähettää toiselle välittömästi tapahtuman jälkeen. Esimerkiksi sisällönhallintajärjestelmä raportoi: "Tämä sivu on julkaistu." Vastaanottava järjestelmä voi sitten hakea ja käsitellä juuri tämän sisällön. Se ei odota seuraavaa yleistä julkaisua eikä se tarkista jatkuvasti uusia muutoksia.
Eräkäsittelyssä kerätään ja suoritetaan useita tehtäviä yhdessä. Esimerkiksi joka ilta kaikki sinä päivänä muuttuneet sivut voidaan tarkistaa raporttia varten. Tällainen suoritus ei ole välitön, mutta se on hyvin suunniteltu. Se voi käsitellä suuria määriä peräkkäin ja tarjota tulokseksi yhtenäisen yleiskatsauksen. Käsittelyllä on tunnettu alku ja määritelty loppu.
Webhookit sopivat tiettyihin, tärkeisiin tapahtumiin.
Webhookit ovat hyödyllisiä, kun oikea-aikainen reagointi tarjoaa selkeän hyödyn. Varoitusviestin julkaisemisen jälkeen sovelluksen tulisi saada sama päivitetty sisältö. Kun sivu on poistettu, sen tulisi poistua sisäisistä hakutuloksista. Viesti laukaistaan tietyllä toiminnolla ja se liittyy selkeästi määriteltyyn sisältöön.
Toimitustiimille tämä prosessi tuntuu välittömältä. He hyväksyvät julkaisun ja näkevät uuden version yhdistetyssä kanavassa lyhyen ajan kuluttua. Tätä nopeutta ei kuitenkaan pidä sekoittaa taattuun samanaikaisuuteen. Verkkovirheet, huolto tai kiireinen vastapuoli voivat viivästyttää käsittelyä. Järjestelmän on kestettävä tällaiset keskeytykset.
Kaikkien tallennettujen muutosten ei pitäisi laukaista webhookia. Automaattisesti tallennettu luonnos ei ole vielä relevantti julkisessa haussa. Merkitykselliset tapahtumat perustuvat niiden näkyvään merkitykseen: julkaistu, olennaisesti päivitetty, peruutettu tai poistettu. Tämä vähentää yhdistettyjen järjestelmien vastaanottamien ilmoitusten määrää ja antaa niille mahdollisuuden käsitellä tärkeitä tilamuutoksia selkeämmin. Sisäisiä kirjoitusvirheiden korjauksia voidaan tarvittaessa käsitellä eri tavalla kuin uusia tietoja.
Eräkäsittely sopii suurille volyymeille ja kiinteille aikatauluille.
Suurempi käsittelykerta sopii, kun useita sisältöjä käsitellään samojen sääntöjen mukaisesti. Organisaatio saattaa haluta tarkistaa kaikki julkaistut sivut puuttuvien tarkistuspäivämäärien varalta joka yö. Onko tulos saatavilla klo 2.00 vai 2.20, sillä ei ole juurikaan merkitystä lukijoille. Välittömän ilmoituksen lähettäminen jokaisen pienen muokkauksen jälkeen olisi tarpeettoman resursseja kuluttavaa.
Jopa täydellinen uudelleenrakentaminen voidaan suorittaa tarkoituksella erissä. Hakujärjestelmän muutoksen jälkeen jopa 80 000 sivua on ehkä skannattava uudelleen. Yksittäiset webhookit eivät kuvaisi luetteloa luotettavasti, koska myös muuttumaton sisältö vaikuttaisi. Eräajo alkaa tunnetulla määrällä sivuja ja dokumentteja, jotka on käsitelty onnistuneesti.
Kiinteä aika helpottaa lataussuunnittelua. Kuvaselitykset, käännösluonnokset tai laajat laatutarkastukset vaativat käsittelyaikaa ja ulkoisia palveluita. Yöllinen ajo voi rajoittaa tätä työmäärää hidastamatta julkaisua toimitusjärjestelmässä. Tämä tekee sen kestosta ennustettavamman sekä operaattorille että palveluntarjoajille. Kiireellinen sisältö tarvitsee edelleen nopeamman reitin, jos pitkä odotus johtaisi virheellisiin tietoihin.
Sallittu viive on ensisijainen huomioitava seikka.
Tärkein kysymys on: Kuinka kauan yhdistetty järjestelmä voi näyttää vanhentunutta versiota? Vakavan sään varoituksen tapauksessa minuutit voivat olla ratkaisevia. Kuukausittaisessa tekstinlaatuanalyysissä yksi päivä on yleensä ongelmaton. Selkeä aikataulu on hyödyllisempi kuin yleinen vaatimus, että jokaisen prosessin on oltava mahdollisimman nopea.
Seuraavaksi ratkaisevan tärkeää on tyypillisen muutoksen laajuus. Jos yleensä julkaistaan vain yksi sivu, webhook voi määrittää kyseisen sivun. Jos kokonaiset tietokannat muuttuvat säännöllisesti, ajoitettu suoritus on helpommin hallittavissa. Uusien, 4 000 merkintää sisältävien sivustojen tuonnin ei pitäisi kontrolloimatta laukaista 4 000 samanaikaista seurantaprosessia.
Myös epäonnistumisen seuraukset ovat osa päätöstä. Jos viesti katoaa, sovellukseen saattaa jäädä vanhentunut puhelinnumero. Jos yöllinen raportti epäonnistuu, toimituskunta voi käynnistää sen uudelleen aamulla. Hyväksyttävästä viiveestä tulisi sopia nimenomaisesti kullekin yhdistetylle kanavalle. Mitä suurempi välitön vahinko on, sitä tärkeämpiä ovat nopeat toistot, näkyvät varoitukset ja koko arkiston lisätarkistus.
Webhook-viesti pysyy pienenä ja yksiselitteisenä.
Hyvä viesti kertoo, mitä tapahtui, mitä sisältöä se koskee ja milloin tapahtuma tapahtui. Se sisältää myös yksilöllisen tapahtumanumeron ja viestimuodon version. Vastaanottava järjestelmä voi sitten hakea täydelliset, ajantasaiset tiedot suojatun rajapinnan kautta. Tämä pitää viestin hallittavana ja välttää koko artikkelin tarpeettoman sisällyttämisen.
Tämä lähestymistapa estää myös viivästyneen viestin levittämästä vanhentunutta tekstiä. Oletetaan, että toimituskunta korjaa saman puhelinnumeron kahdesti peräkkäin. Ensimmäinen viesti saapuu myöhemmin kuin toinen teknisen ongelman vuoksi. Jos vastaanottava puoli tarkistaa uusimman version, se saa silti viimeksi hyväksytyn version eikä viivästyneen viestin sisältöä.
Henkilökohtaisia tai luottamuksellisia tietoja ei tule sisällyttää viesteihin, ellei se ole ehdottoman välttämätöntä. Lokit, virheraportit ja hallintaliittymät tallentavat usein webhook-tietoja pitkiä aikoja. Monissa tapauksissa sisällön tunniste ja tapahtuman tyyppi riittävät. Valtuutettu vastaanottaja hakee lisätietoja vain, kun sen todella on käsiteltävä niitä. Tämä pitää myös tekniset virheraportit vapaina tarpeettomista teknisistä yksityiskohdista.
Toistuvat viestit ovat normaalia.
Jos vastaanottava puoli ei kuittaa viestin vastaanottamista, lähettävä järjestelmä lähettää sen uudelleen. Ensimmäinen viesti on saattanut jo käsitellä, mutta sen kuittaus on kadonnut. Siksi vastaanottavan osapuolen on kyettävä hyväksymään sama tapahtuma useita kertoja julkaisematta viestiä kahdesti tai tilaamatta samaa käännöstä kahdesti.
Yksilöllinen tapahtumanumero auttaa tässä. Jos tämä numero on jo käsitelty onnistuneesti, järjestelmä voi kuitata ja ohittaa toiston. Tämä on luotettavampaa kuin aikojen tai otsikoiden vertaaminen. Kaksi eri muutosta voi tapahtua lähes samanaikaisesti, ja otsikko voi muuttua, vaikka sisältö pysyy samana.
Järjestyskään ei ole aina luotettava. Ilmoitus julkaisusta saattaa saapua myöhemmästä korjauksesta tehdyn ilmoituksen jälkeen. Versionumerot tai sisällön nykyinen käyttöpäivämäärä estävät vanhemman version etusijalle asettamisen. Toimituksellisille tiimeille tämä tarkoittaa: Näkyvän version on oltava oikea, vaikka tekniset viestit kulkisivatkin hieman epäsäännöllisesti. Siksi pelkästään vastaanottopäivämäärän ei pitäisi määrittää oikeaa versiota.
Vastaanottajan on varmistettava alkuperä.
Julkisesti saatavilla olevaan webhook-osoitteeseen voivat periaatteessa päästä käsiksi myös luvattomat osapuolet. Vastaanottavan pään ei siis pitäisi luottaa viestiin vain siksi, että se saapuu odotettuun polkuun. Digitaalinen allekirjoitus, joka lasketaan sisällöstä ja jaetusta salaisesta avaimesta, on vakiokäytäntö. Vastaanottaja laskee sen uudelleen ja vertaa kahta arvoa.
Lähetys tapahtuu HTTPS:n kautta sisällön ja käyttötietojen suojaamiseksi siirron aikana. Salainen avain ei kuulu lähdekoodiin, julkiseen dokumentaatioon tai viestin runkoon. Se tallennetaan turvallisesti, siihen pääsevät käsiksi vain tarvittavat palvelut ja se uusitaan säännöllisesti. Vanhat avaimet on mitätöitävä hallitun siirtymän jälkeen.
Aikaleima rajoittaa entisestään sitä, kuinka kauan oikein allekirjoitettu viesti hyväksytään. Tämä estää tallennetun pyynnön toistamisen mielivaltaisesti myöhemmin. Virhevastausten ei tulisi paljastaa sisäisiä tietoja hyökkääjille. Tietoa säilytetään kuitenkin riittävästi, jotta tiimi voi tutkia hylättyä allekirjoitusta tai vanhentunutta viestimuotoa. Epäilyttävät käyttöyritykset rajoitetaan ja kirjataan jäljitettävällä tavalla tietoturvatarkastuksia varten. Asianmukaisia ja selkeästi dokumentoituja säilytysaikoja sovelletaan.
Suuri eräajo vaatii jäljitettävyyden.
20 000 sivun eräajo on harvoin täysin onnistunut tai epäonnistunut. Osa sisällöstä voi sisältää virheellisiä tietoja, kun taas loput käsitellään oikein. Prosessin tulisi siksi tallentaa jokaiselle merkinnälle, mikä onnistui ja mitä on yritettävä uudelleen. Yksittäinen viallinen sivu ei saa estää kaikkia seuraavia sivuja.
Ulkoisten palveluiden rajoitukset on otettava huomioon. Rajapinta saattaa sallia vain tietyn määrän pyyntöjä minuutissa. Prosessi jakaa sitten taltion hallittaviin osiin ja jatkaa tauon jälkeen. Se tallentaa edistymisensä, jotta uudelleenkäynnistys ei ala alusta ensimmäiseltä sivulta ja toista tarpeettomasti jo maksettua työtä.
Toimitustiimille selkeä ja ymmärrettävä tulos on tärkeämpi kuin pitkä tekninen lokitiedosto. Heidän on voitava nähdä, mihin suoritukseen ongelma vaikuttaa, kuinka paljon sisältöä on valmis ja mitkä sivut tarvitsevat teknistä apua. Viesti, kuten "37 virhettä", ei riitä. Virheen liittäminen sivun otsikkoon, osoitteeseen ja tiettyyn syyhyn tekee siitä hallittavan tehtävän. Onnistuneet toistot katoavat sitten avoimesta toimitusnäkymästä.
Usein ajoitettu suoritus täydentää webhookeja.
Webhookit ja eräajokäsittely eivät ole toisensa poissulkevia. Uutisportaali voi välittömästi ilmoittaa uusista artikkeleista hakutoimintoonsa ja synkronoida koko arkiston yön aikana. Tämä nopea lähestymistapa pitää tärkeät muutokset ajan tasalla. Ajoitettu suoritus löytää tapahtumat, jotka puuttuvat toimintahäiriön, virheellisen asetuksen tai tilapäisesti offline-tilassa olevan palvelimen vuoksi.
Selkeä ja ytimekäs kirjallinen versio voi myös vaatia molempia lähestymistapoja. Jos erikoissivua muokataan, webhook luo välittömästi tehtävän vastaavalle toimituskunnalle. Vahvistettua versiota ei korvata automaattisesti. Päivittäinen raportti näyttää lisäksi kaikki avoimet tehtävät, niiden määräajat ja sisällön, jolta puuttuu yhteys lähdesivuun.
Selkeä lähde kelvolliselle tilalle on ratkaisevan tärkeää. Webhook raportoi muutoksesta, ja säännöllinen synkronointi vahvistaa nykyisen tilan. Jos molemmat antavat eri tietoja, viimeksi suoritettu prosessi ei saa vahingossa olla etusijalla. Julkaisujärjestelmä pysyy auktoritatiivisena, ja yhdistetyt järjestelmät synkronoivat tilansa sen kanssa. Tämän säännön on pysyttävä selkeästi dokumentoituna myös järjestelmämuutoksen jälkeen.
Toiminnan on pysyttävä ymmärrettävänä ihmisille.
Tekninen luotettavuus osoitetaan näkyvillä tiedoilla. Tiimien tulisi tietää, kuinka kauan lähetys tyypillisesti kestää ja milloin viiveestä ilmoitetaan. Varoitus määrittää kyseessä olevan kanavan ja sisällön, ei vain sisäisen prosessin nimen. Näin toimituskunta voi arvioida, katsovatko kävijät parhaillaan vanhentunutta versiota.
Jokainen prosessi vaatii vastuullisen osapuolen. Tämä osapuoli voi lähettää jumiutuneen viestin uudelleen, jatkaa eräajoa tai pysäyttää virheellisen julkaisun. Samalla on oltava selvää, milloin tekninen vastuu vaaditaan. Tekninen tiimi voi siirtää tiedoston, mutta ei voi päättää, onko muuttunut vaatimusehto selitetty oikein.
Sopiva ratkaisu seuraa siis sisällöstä, ajasta ja mahdollisista vahingoista. Webhookit reagoivat nopeasti yksittäisiin tapahtumiin. Eräajot käsittelevät ennustettavia määriä ja täsmäävät inventaariot. Yhdessä ne kattavat nykyiset muutokset ja inventaarion täydellisyyden. Jos toistot, turvallisuus ja ymmärrettävät viestit otetaan huomioon alusta alkaen, yhdistetyt verkkosivustot ja palvelut pysyvät ajan tasalla kuormittamatta toimituskunnan päivittäistä työtä tarpeettomalla teknologialla.