Vodnik za integracijo podatkov na po meri izdelani LED-plošči in za odpornost proti napakam

A po meri izdelana LED prikazna plošča postane drugačna vrsta prikaza, ko se podatki na zaslonu izvirajo iz spreminjajočega se poslovnega sistema. Temperatura vremena lahko potuje. Številka v vrsti čakalnice se lahko premakne na drugo blagajno. Prevozna storitev se lahko zakasni. Cena se lahko spremeni, medtem ko ostane ozadje nespremenjeno. V teh projektih zaslon ne predvaja več le medijev, temveč prikazuje trenutno stanje drugega informacijskega sistema.

To spremeni inženirsko vprašanje. Težava redko leži v risanju okvirja za številko ali povezavi API-ja enkrat. Pomembnejše so odločitve o tem, od kod izvirajo posamezne vrednosti, kateri sloj določa, ali so še zanesljive, kako več živih območij deli isti platno in kaj se prikaže, ko vir preneha posodabljati. Ta priročnik se osredotoča na to mejo: zunanjih poslovnih podatkov, ki vstopajo v delovni tok vsebine, ter rezervnih logičnih pravilih, ki zagotavljajo, da ostane zaslon smiseln tudi, ko živi podatki niso na voljo.

Ista LED-zaslon lahko prikaže tri zelo različne vrste vsebine

An Prikazna plošča s LED diodami lahko prikaže slike kampanje, sledi časovno določenemu seznamu predvajanja in prikaže živo številko v čakalni vrsti na istem fizičnem platnu. Vizualno ti elementi morda izgledajo enako preprosto. Operativno pa se obnašajo zelo različno.

Pripravljena slika že obstaja pred začetkom predvajanja. Načrtovana scena že ve, kdaj naj se prikaže. Žive informacije so drugačne, saj vrednost morda še ne obstaja, dokler jo ne zagotovi drug sistem. Posledično živi podatki ustvarijo odvisnost, ki je pri statični vsebini odsotna.

Statična vsebina preživi, ker sredstvo že obstaja

Shranjena slika ali posnetek je predvsem medijski problem. Ko odobreni datoteki dosežejo lokalno shrambo za predvajanje, zaslon nadaljuje z njenim prikazovanjem, dokler jo kasnejše sredstvo ne nadomesti. Dostop do omrežja še vedno lahko pomaga pri oddaljenih nalaganjih, a vidna vsebina sama po sebi ne potrebuje drugega platforme, da bi odgovorila vsakič, ko se prikaže sličica.

Ta razlika je pomembna pri načrtovanju odpovedi. Če se omrežna povezava za kratek čas izgubi, lahko shranjena kampanjska scena še naprej normalno deluje. Številka vrste ali trenutno stanje prevoza morda ne bo.

Načrtovana vsebina je odvisna od časa, vendar ne vedno od zunanjih podatkov

Razpored dodaja še eno plast, brez da bi nujno uvedel zunanji vir. Vsebina za jutro se lahko glede na ure na predvajalniku preklopi na popoldansko sceno. Podobno lahko načrtovano obvestilo o storitvi začne in konča delovanje v določenih urah, medtem ko ostane vsa predstavnost shranjena lokalno.

V tem modelu je ključno vprašanje, ali sta razpored in ura pravilna. Živi podatki postavljajo težje vprašanje: ali prikazane informacije še vedno predstavljajo trenutno stanje vira.

Živa vrednost lahko izgleda zdrava tudi dolgo po tem, ko ni več aktualna

To je eden najlažjih tveganj, ki ga spregledamo.

Temperatura lahko ostane vidna, čeprav vir vremenskih podatkov ni več posodabljal že ure prej. Vrstica o prevozu lahko nadaljuje prikaz staro napovedo prihoda. Plošča z cenami lahko ohrani prejšnjo vrednost brez kakršnegakoli očitnega znaka, da je vir podatkov potekel. Zato mora oblikovanje živega prikaza vključevati koncept, ki ga statična medija redko potrebujejo: svežina .

Sledi podatkom od njihovega izvirnega vira do ene vidne regije

Žive informacije na zaslonu pogosto izgledajo zavajajoče majhne. Vremenski blok lahko vsebuje eno temperaturo in eno vremensko razmerje. Pri kazalniku vrste se lahko prikaže le številka in števec. Kljub temu lahko ti nekaj vidnih polj potuje skozi več sistemov, preden postanejo uporabna.

Najlažji način razumevanja integracije je slediti eni vrednosti namesto, da bi hkrati pregledali celotni programski sklad. Razmisli o številki v vrsti. Platforma za vrste ustvari poslovno stanje. Vmesnik razkrije ustrezno zapisno enoto. Druga plast preveri in pripravi vrednost. Predvajalnik jo postavi v pravo regijo. Šele takrat končna vizualna platno doseže LED sistem.

Čas je dinamičen, vendar morda ne potrebuje zunanjega vira.

Ura se spreminja vsako sekundo, vendar jo pogosto lahko ustvarimo lokalno. V tem primeru se skrb premakne stran od zunanjega API-ja k sinhronizaciji ur, časovnem pasu, obliki datuma, obnašanju ob ponovnem zagonu in doslednosti med zasloni.

To je uporabno opomnik, da »živo« ne pomeni samodejno »internetni API«. Pravilna izvorna sredstva so odvisna od tega, kje že obstaja avtoritativna informacija.

Vreme potrebuje manj polj, kot jih verjetno ponuja storitev za vreme.

Storitev za vreme lahko razkriva veliko količino informacij. Zaslon morda potrebuje le lokacijo, trenutno temperaturo, vremensko razmerje, stanje ikone in časovni žig vira. Pridobivanje vseh razpoložljivih polj ustvari več odvisnosti brez izboljšanja vidnega rezultata.

Zato je boljša vprašanje ne »Ali se lahko poveže API za vreme?«, temveč »Katera polja vremenskih podatkov dejansko nastopijo in kako stara lahko postanejo, preden se spremeni stanje vremenskega območja?«

Podatki čakalne vrste predstavljajo stanje, ne le veliko številko

Informacije o čakalni vrsti lahko vključujejo poklicano številko, števec, kategorijo storitve, stanje in časovni žig. Samo številka ne pojasni, ali je bila številka ravno poklicana, ali še vedno ostaja aktivna, ali je bila že zaključena, ali pa spada med stare zapiske.

Tukaj je pomembno izvirno pomen. Prazna vrednost ne bi smela samodejno postati ničla. Enako tudi manjkajoče polje ne bi smelo samodejno pomeniti »brez čakalne vrste«. Ta stanja lahko predstavljajo zelo različne obratovalne pogoje.

Cene bi morale priti kot odobrene vrednosti, namesto da bi jih ponovno izračunali na zaslonu

Cenovne informacije lahko зависijo od valute, identifikatorja izdelka, lokacije, veljavnega obdobja, stanja promocije, enote in drugih pravil. Ta poslovna pravila pripadajo izvirni platformi, ki jih že upravlja.

Delovni tok prikazovanja se lahko nato osredotoči na predstavitev. Decimalna mesta, simboli valut, oznake enot, dolžina besedila in stanja, ko podatki niso na voljo, se lahko standardizirajo brez podvajanja same logike za določanje cen.

Podatki o prometu in prevozu pogosto zahtevajo prevod, še preden potrebujejo grafično obdelavo.

Platforme za prevoz lahko prikažejo identifikatorje poti, ocenjen čas prihoda, peron, stanje zamude, kodo storitve ali stanje incidenta. Surovi podatki so morda zasnovani za programske rešitve, ne pa za javno predstavitev.

Srednji sloj (middleware) lahko to zapletenost zmanjša tako, da notranje kode prevede v stabilen model za prikaz. Predvajalnik morda prejme le ciljno lokacijo, pričakovan čas in odobreno besedilno stanje. Če se vir kasneje spremeni, se lahko plast za predstavitev ostane v veliki meri nespremenjena.

Pred začetkom programskega dela odločite, kateri sloj je odgovoren za vsako odločitev.

Integracija postane težka, ko več sistemov tiho deli isto odgovornost. Vir aplikacije lahko oblikuje prikazno besedilo. Predvajalnik lahko začne razlagati poslovne statusne kode. Drug skript lahko vzdržuje ločen predpomnilnik. Rezultat še vedno deluje med predstavitvijo, vendar se odpravljanje napak znatno oteži, ko se karkoli spremeni.

Čistejša arhitektura ohrani meje razumljive. Vir lasti poslovni podatek. Posredniški sloj odloči, ali je podatek primeren za prikaz. Predvajalnik lasti vizualno prizorišče. Pot nadzora LED luči lasti fizični izhod.

To delitev omogoča tudi lažje razpravljanje o obsegu projekta. »Integracija API-ja« lahko sicer opisuje več popolnoma različnih nalog. Lahko pomeni pridobivanje zunanjega vira podatkov, izgradnjo posredniške programske opreme, preslikavo podatkov v predlogo predvajalnika ali usklajevanje več dinamičnih območij znotraj enega fizičnega zaslona.

Ko arhitektura informacij vpliva na geometrijo zaslona, projekt LED zaslon po meri lahko uskladi ti dve strani skupaj. Stalni blok vrste čakanja, trak z vremenskimi podatki, seznam prevoznih sredstev ali večzonsko informacijsko platno morda zahtevajo, da se fizične mere in programska območja obravnavajo hkrati.

Stalna oblika informacijskega zaslona

Ohišje je fizična končna točka. Število območij, hierarhija informacij in dostop do storitev morajo še naprej ustrezati končni geometriji zaslona.

Oglejte si LED zaslon 960 × 960

Modularno informacijsko platno

Modularna strojna oprema lahko tvori različne skupne velikosti, medtem ko ostanejo podatkovna območja in vedenje pri izpadu določena na ravni sistema za vsebino.

Oglejte si LED zaslon 500 × 500

Določite pomen vsakega vidnega polja pred izgradnjo končnega postavitve

izraz »poveži vremensko API« ali »prikaži podatke o vrsti« se zdi jasen že v zgodnjih razpravah. V praksi pa oba izkaza pustita odprta večino pomembnih odločitev o integraciji.

Uporabnejša začetna točka je majhna pogodba o podatkih. Poveže en vidni element z enim določenim poljem vira ter zabeleži dovolj konteksta, da se odločimo, ali se ta vrednost lahko varno prikaže.

Ime polja samo po sebi redko pojasni poslovni pomen

Lastnost z imenom statusbi lahko pomenila razpoložljivost storitve, zdravje API-ja, veljavnost zapisa, stanje vrste ali stanje poti. Lastnost z imenom wait_timeše vedno potrebuje enoto in opredelitev.

Zato mora opredelitev polja zajeti tako pomen kot sintakso. Ta majhen korak prepreči tehnično pravilno integracijo, ki prikazuje napačno razlago.

Ničla, prazno in nedosegljivo naj ostanejo različna stanja

Število v čakalni vrsti, ki znaša nič, lahko predstavlja legitimno poslovno vrednost. Prazno polje lahko pomeni, da ni aktivnega zapisa. Manjkajoč ključ lahko kaže na nepopolna podatka. Neuspešen zahtevek pa pomeni nekaj popolnoma drugega.

Združevanje teh stanj ustvarja zavajajoč izhod. Prikladna predstavitev podatkov naj ohrani razliko med njimi, dokler odobrena pravila za prikaz ne določijo, kako naj izgleda vsako stanje.

Dolžina besedila spada v razpravo o podatkih

Dinamični postavitvi pogosto vizualno odpovedeta še pred tem, da bi tehnično odpovedali. Ime cilja, ki se ujema med testiranjem, lahko v običajnem delovanju postane veliko daljše. Sporočilo o storitvi se lahko prelomi v drugo območje. Velika cena lahko zahteva več števk, kot jih je dovolil prvotni maketni prikaz.

Zato polja, ki vsebujejo veliko besedila, potrebujejo znano vizualno pravilo. Projekt lahko uporabi odobreno okrajšavo, prelom besedila, skrajšanje, drugo stanje predloge ali drugačno širino območja. Tiho zmanjševanje velikosti besedila, dokler ne postane neberljivo, redko predstavlja dobro rezervno rešitev.

izraz »v resnem času« je preveč nejasen, dokler se osveževanje in svežina ne ločita.

Ena najlažjih napak pri RFQ je zapisati le »osveževanje v resnem času«. Ta izraz sicer zveni natančno, vendar lahko opisuje popolnoma različne operativne pričakovanja.

Dogodek v vrsti čakanja se morda mora pojaviti hitro, saj informacije spremenijo takojšnji potek storitve. Podatki o vremenu lahko sledijo počasnejšemu ciklu objavljanja. Promocijska cena se lahko ohrani nespremenjena, dokler se ne zgodi odobren komercialni dogodek. Ti podatkovni tokovi ne potrebujejo enakega obnašanja pri osveževanju le zato, ker so prikazani na istem zaslonu.

Interval osveževanja vpraša, kako pogosto sistem išče nekaj novega.

Ponovno poiskanje (polling) lahko preveri API v določenem intervalu. Spletni kavelj (webhook) lahko dostavi spremembo ob nastopu dogodka. Drug vir na mestu lahko objavi datoteko ali sporočilo le, ko obstaja nov zapis.

Mehanizem posodobitve naj sledi obstoječemu viru. Ponovno zahtevanje istega vremenskega končnega točke ne zagotovi novejših vremenskih podatkov, če ponudnik še ni objavil nove meritve.

Svežina določa, kako star lahko postane zadnji sprejet podatek.

To vprašanje je običajno bolj uporabno. Povezava lahko ostane zdrava, medtem ko vir nadaljuje z vračanjem starega zapisa. Zato mora imeti zaslon ločeno pravilo za starost poslovnih informacij same.

Ko ta starost preseže dogovorjeno mejo, sistem preneha prikazovati vrednost kot trenutno. To je točka, kjer logika predpomnjenja in rezervnih rešitev postane del oblikovanja vsebine, ne le IT-skrb.

Varnostna vsebina naj sporočilo postopoma zmanjša njegovo učinkovitost, ne da bi skrila napako

Žive informacije potrebujejo smiselno vizualno stanje tudi, ko vir izgine. Brez njega se zaslon lahko zamrzne na starejših podatkih, prikaže prazno besedilno polje, prikaže napako aplikacije ali preprosto pusti veliko prazno površino.

Najmočnejša rezervna rešitev redko predstavlja en sam izreden zaslon. Boljši dizajn omogoča postopno degradacijo informacij. Kratke prekinitve lahko ohranijo zadnji sprejet zapis. Starejši podatki lahko preidejo v stanje »zastaranih«. Končno lahko nevtralna lokalna scena nadomesti informacije, ki jih več ni smiselno prikazovati kot trenutne.

Shrani zadnji dober zapis, ne le zadnjega odgovora

Nepravilno oblikovan odgovor ne sme prepisati edinega zanesljivega lokalnega zapisa. Namesto tega lahko nova podatkovna vsebina opravi preverjanje pred tem, da nadomesti predpomnilnik.

Zaporedje je načeloma preprosto: prejmi nov zapis, ga preveri, normaliziraj, sprejmi in nato posodobi shranjeno zadnje znano dobro stanje. Ko nov odgovor ne uspe pri teh preverjanjih, ostane veljaven predpomnilnik na voljo, dokler ne potekne njegova odobrena starost.

Ena neuspešna vir podatkov ne mora uničiti celotnega platna

Zaslon z mešanimi informacijami lahko vsebuje vreme, čas, podatke o vrsti in načrtovano medijevno vsebino. Če vir za vreme odpove, platforma za vrsto še vedno lahko deluje pravilno in lokalna medija še vedno lahko ostanejo na voljo.

Vzvratna možnost na podlagi regije lahko ohrani uporabne dele zaslona. Vremenska cona spremeni stanje, medtem ko se regija za vrsto nadaljuje z osveževanjem. To daje bolj nadzorovan rezultat kot zamenjava celotnega zaslona zaradi nedostopnosti enega zunanjega vira.

Verodostojna nadomestna vsebina lahko je še slabša od sporočila o nedostopnosti

Privzete informacije ne smejo izmišljati verjetne vrednosti. Izmišljena temperatura je še vedno napačna. Nič naj ne nadomesti nedostopnega stanja vrste, razen če ima nič resnično to poslovno pomen. Stara cena naj ne ostane neskončno dolgo le zato, ker še vedno ustreza postavitvi.

Nevtralna rezervna vsebina je običajno varnejša. Glede na uporabo lahko regija prikaže splošne informacije o storitvi, statični lokacijski panel, odobreno stanje »nedosegljivo« ali drugo lokalno prizorišče, ki ostane veljavno tudi brez zunanjega vira podatkov.

Obnovitev zasluži lastno pravilo

Ko se vir znova prikazuje, naj prvi odziv ne izbriše samodejno rezervnega stanja, preden se izvedejo običajne preveritve. Nov zapis še naprej mora izpolnjevati ista pravila glede polj in svežine kot katera koli druga živa posodobitev.

To postane še posebej uporabno, kadar je nadrejena storitev nestabilna. Sicer se vidna regija lahko večkrat zaporedoma preklopi med rezervno in živo vsebino, medtem ko se povezava z virom nihajoče spreminja.

Boljši RFQ opisuje tok informacij, ne le velikost zaslona

Širina in višina zaslona ter namestitveni pogoji ostajajo bistveni. Vendar ne morejo pojasniti, ali končna površina vsebuje eno uro ali šest neodvisnih živih pretokov.

Kratka navodila za integracijo postanejo veliko jasnejša, ko odgovorijo na tri praktična vprašanja: kakšne informacije vstopajo, kako hitro se lahko spremenijo in koliko delov zaslona od njih je odvisnih.

Začnite z viri, ne z imeni programske opreme

Vsak tip žive informacije naj ima znani vir. To lahko je platforma za vrste čakanja, ponudnik vremenskih podatkov, notranja baza cen, prometna storitev, transportni sistem ali druga odobrena poslovna aplikacija.

V zgodnjih navodilih se lahko navede, ali dokumentacija vmesnika že obstaja, ter ali je na voljo pot REST API, spletne kljukice (webhook), lokalna storitev, tok sporočil, strukturirana datoteka ali druga potrjena metoda. Če metode še ni znano, je bolje to polje pustiti odprto kot ugibati.

Majhen vzorec podatkovnega paketa lahko hkrati odgovori na več vprašanj

Očiščen vzorec lahko prikaže imena polj, podatkovne tipe, časovne žige in strukturo stanja, ne da bi razkril proizvodne poverilnice ali zaupne zapise. To pogosto razkrije več uporabnih informacij kot dolgo splošno opis platforme.

Na primer, obremenitev vrste čakanja, ki vsebuje kodo storitve, številko vrste čakanja, števec, stanje in časovno žigo posodobitve, takoj kaže, katera polja morda potrebujejo preslikavo in katere vrednosti vplivajo na vizualno stanje.

Število regij spreminja obseg integracije

Celozaslonska vremenska scena je sorazmerno preprosta, ker večino spreminjajočega se vsebine nadzoruje en vir. Mešana prikazna površina pa lahko predstavlja drugačen izziv. Čas se lahko izvaja lokalno, vreme prihaja od zunanjega ponudnika, informacije o vrsti čakanja iz notranje platforme, načrtovani mediji pa zasedajo preostali prostor.

Zato število neodvisno nadzorovanih regij spada v zahtevek za ponudbo (RFQ). Vsako regijo se nato lahko poveže z lastnim virom, obnašanjem pri posodobitvi, rezervnim stanjem in vizualno prioriteto.

Preizkusite neprijetna stanja podatkov pred tem, ko se zaslon prikaže

Popolni vzorčni podatki dokazujejo, da se izgled lahko izriše. Ne dokazujejo pa, da se informacijski sistem lahko varno sesuje.

Integracijsko testiranje postane bolj vredno, kadar namerno razbije predpostavke za običajno sceno. Obvezno polje lahko izgine. Vrednost stanja lahko postane nepričakovana. API lahko ostane dosegljiv, hkrati pa se njegov časovni žig preneha spreminjati. Vir podatkov lahko izgine dovolj dolgo, da se predhodno predpomnjeni podatki zastarijo.

Dolgi, a veljavni tekst spada tudi v testiranje. Cilj z več znaki, višjo ceno ali daljšim statusnim sporočilom lahko razkrije vizualne težave, ki jih kratke razvojne vrednosti nikoli ne razkrijejo. Ti testi so preprosti, a pogosto preprečijo bolj vidne napake kot še en krog posnetkov z normalnimi podatki.

Pogosto zastavljena vprašanja

Najboljši zaslon za žive podatke ohranja poslovno logiko nadzorni in predstavitev jasno.

Platforma vrste čakalne vrste naj naprej odloča o stanju vrste čakalne vrste. Platforma za določanje cen naj naprej lasti cene. Transportna aplikacija naj naprej lasti transportne informacije. Prikaže se ne postane zanesljivejši s kopiranjem teh poslovnih pravil v vsakega predvajalnika.

Namesto tega lahko integracija izlušči le podatke, potrebne za prikaz, odloči, ali je vsak zapis še vedno primeren za prikaz, ter posreduje čist model za prikaz naprej. Ta ločitev omogoča tudi lažje kasnejše spremembe, saj razporeditev zaslona ne potrebuje razumevanja vseh podrobnosti nadrejenega sistema.

Pred pripravo ponudbe tri odločitve zagotovijo najjasnejšo izhodiščno točko:

• Opredelite žive regije. Zabeležite, kateri vir in katera polja določajo vsako vidno območje.
• Določite starost ter hitrost posodobitve. Uspešna povezava ne pomeni, da so prikazani podatki še vedno aktualni.
• Načrtujte rezervno rešitev že pred povezavo živega vira. Trajanje predpomnjenja, stanje zastarelih podatkov, nevtralna vsebina in obnovitev ne smejo biti izumljene šele po uvedbi.