EN
A mukautettu LED-näyttöpaneeli muuttuu erilaiseksi näyttöksi, kun ruudulla näkyvä tieto tulee muuttuvasta liiketoimintajärjestelmästä. Sääennusteen lämpötila voi vanhentua. Jononumero voi siirtyä toiseen kassaan. Liikennepalvelu voi myöhästyä. Hinta voi muuttua, vaikka taustakuvan teos pysyisi täsmälleen samana. Näissä projekteissa näyttö ei enää pelkästään toista mediaa. Se esittää toisen tietojärjestelmän nykyistä tilaa.
Tämä muuttaa suunnittelukysymystä. Vaikein osa on harvoin vain numeroa ympäröivän laatikon piirtäminen tai API:n yhdistäminen kerran. Tärkeimmät päätökset koskevat sen sijaan, mistä jokainen arvo saadaan, mikä kerros päättää, onko arvo edelleen luotettava, miten useat elävät alueet jakavat yhteisen kuvan ja mitä näytetään, kun lähde lakkaa päivittämästä tietoja. Tämä opas keskittyy juuri tälle rajalle: ulkoisten liiketoimintatietojen saattaminen sisältötyönkulkuun sekä varalogiikan toteuttaminen, joka pitää näytön merkityksellisenä, kun elävää tietoa ei ole saatavilla.
Sama LED-näyttö voi näyttää kolmea erilaista sisältötyyppiä
Automaattinen LED-näyttöpaneeli se voi näyttää kampanjakuvan, seurata aikataulutettua soittolistaan ja esittää elävän jononumeron samalla fyysisellä näyttöalueella. Visuaalisesti nämä elementit voivat näyttää yhtä yksinkertaisilta. Toiminnallisesti ne kuitenkin käyttäytyvät hyvin eri tavoin.
Valmiiksi valmistettu kuva on olemassa jo ennen toistotauon alkua. Aikataulutettu näyttökohta tietää jo etukäteen, milloin sen pitäisi ilmestyä. Elävä tieto on erilaista, koska sen arvoa ei ehkä ole olemassa ennen kuin toinen järjestelmä toimittaa sen. Tämän vuoksi elävä data luo riippuvuuden, jota staattisella medialla ei ole.
Staattinen sisältö säilyy, koska resurssi on jo olemassa
Tallennettu kuva tai video on pääasiassa mediatiedosto-ongelma. Kun hyväksytty tiedosto saavuttaa paikallisesti toistettavan tallennustilan, näyttö voi jatkaa sen näyttämistä, kunnes myöhempäksi ajoitettu resurssi korvaa sen. Verkkoyhteys voi edelleen olla tärkeä etäyhteyden kautta tapahtuviin latauksiin, mutta näkyvä sisältö itsessään ei tarvitse toista alustaa vastaamaan joka kerta, kun kehys ilmestyy.
Tämä ero on tärkeä vikaantumissuunnittelussa. Jos verkkoyhteys katkeaa lyhyeksi ajaksi, tallennettu kampanjakohtaus voi edelleen toimia normaalisti. Jononumero tai nykyinen kuljetustilanne eivät välttämättä toimi.
Aikataulutettu sisältö riippuu ajasta, mutta ei aina ulkoisista tiedoista
Aikataululla lisätään toinen kerros ilman, että ulkoista tietovirtaa välttämättä otetaan käyttöön. Aamupäivän sisältö voi vaihtua iltapäivän kohtaukseen pelaajan kellon mukaan. Samoin suunniteltu palvelu-ilmoitus voi alkaa ja loppua määritellyissä ajassa, kun kaikki media säilyy paikallisesti tallennettuna.
Tässä mallissa keskeinen kysymys on, ovatko aikataulu ja kello oikein. Liven tiedot tuovat vaikeamman kysymyksen: esitetty tieto edustaaako edelleen lähteen nykyistä tilaa.
Liven arvo voi näyttää terveeltä pitkän ajan jälkeen sen pysähtymisestä
Tämä on yksi helpoimmista riskeistä huomata väärin. Yhteysvirhe näyttää usein ilmeiseltä, koska pyyntö palauttaa virheen. Vanhentunut tieto on vaarallisempi, koska se voi edelleen näyttää täysin normaalilta.
Lämpötila voi pysyä näkyvissä, vaikka säälähteen päivitykset olisivat loppuneet tuntia aikaisemmin. Liikennetietue voi jatkaa vanhan saapumisarvion näyttämistä. Hinnanpaneeli voi säilyttää aiemman arvon ilman mitään ilmeistä merkkiä siitä, että sen ylävirtalähde on vanhentunut. Siksi elävän näytön suunnittelussa tarvitaan käsitettä, jota staattiset medioilla harvoin tarvitaan: mehun tuoreutta .
Kuva tai video on jo olemassa. Tallennus ja toisto määrittävät sen, näkyykö se.
Valmisteltu media muuttuu kellon, kalenterin, tapahtumavälitilan tai muun aikataulun mukaan.
Arvo tulee toisesta tietojärjestelmästä, joten sen ikä, voimassaolo ja virhetilanteiden käyttäytyminen ovat tärkeitä.
Hyödyllinen suunnittelulyhenne: luokittele jokainen näkyvissä oleva alue ennen ohjelmistokeskustelua. Pysyvä logo voi pysyä staattisena. Markkinointimateriaali voi noudattaa aikataulua. Jononumero voi pysyä elossa. Hyväksytty palveluviesti voi ohittaa kaikki kolme. Tämä yksinkertainen ero pitää integraatiokeskustelun keskitettynä.
Seuraa tietoa sen alkuperäisestä lähteestä yhteen näkyvään alueeseen
Elävät tiedot näyttävät usein ruudulla harhaanjohtavasti pieniltä. Säälohko saattaa sisältää vain yhden lämpötilan ja yhden säätilan. Jononäyttö saattaa näyttää vain numeron ja laskurin. Siitä huolimatta muutamat näkyvissä olevat kentät voivat kulkea useiden järjestelmien läpi ennen kuin ne muuttuvat käytettäviksi.
Integraation ymmärtäminen on helpointa seuraamalla yhtä arvoa kerrallaan eikä katsomalla koko ohjelmistopinoa yhdessä. Tarkastellaan esimerkiksi jononumeroa. Jonopalvelu luo liiketoimintatilan. Rajapinta paljastaa asianmukaisen tietueen. Toinen kerros tarkistaa ja valmistaa arvon. Soittaja sijoittaa sen oikeaan alueeseen. Vasta sitten lopullinen visuaalinen kanvas saavuttaa LED-järjestelmän.
Aika on dynaaminen, mutta siihen ei ehkä tarvita ulkoista syötettä
Kello muuttuu joka sekunti, mutta sen voi usein generoida paikallisesti. Tässä tapauksessa huolenaihe siirtyy ulkoisesta API:sta kellojen synkronointiin, aikavyöhykkeeseen, päivämäärän muotoon, käynnistyskäyttäytymiseen ja näyttöjen väliseen yhtenäisyyteen.
Tämä on hyvä muistutus siitä, että ’elävä’ ei automaattisesti tarkoita ’internet-API:a’. Oikea lähde riippuu siitä, missä virallinen tieto jo olemassa on.
Sää vaatii vähemmän kenttiä kuin sääpalvelu todennäköisesti tarjoaa
Sääpalvelu voi tarjota suuren määrän tietoja. Näyttö saattaa tarvita vain sijainnin, nykyisen lämpötilan, säätilan, ikonin tilan ja lähteen aikaleiman. Kaikkien saatavilla olevien kenttien hakeminen lisää riippuvuuksia ilman, että näkyvää tulosta parannetaan.
Siksi parempi kysymys ei ole: »Voiko säätietojen API:tä yhdistää?« vaan: »Mitkä säätiedot todella näkyvät ja kuinka vanhoja ne voivat olla ennen kuin säälue muuttaa tilaansa?«
Jonotieto on tila, ei pelkkä suuri luku
Jonotiedot voivat sisältää kutsuttavan numeron, lipunumeron, palveluluokan, tilan ja aikaleiman. Pelkkä numero ei kerro, onko se juuri kutsuttu, onko se edelleen aktiivinen, onko se valmis vai kuuluuko se vanhaan tietueeseen.
Tässä merkitys lähteestä on ratkaisevan tärkeä. Tyhjä arvo ei automaattisesti tule muuttua nollaksi. Samoin puuttuva kenttä ei automaattisesti tarkoita »ei jonoa«. Nämä tilat voivat edustaa hyvin erilaisia toimintatiloja.
Hinnat tulisi saada hyväksytyinä arvoina eikä niitä tulisi uudelleenlasketa näytöllä
Hintatiedot voivat riippua valuutasta, tuotetunnisteesta, sijainnista, voimassaoloajasta, kampanjatilasta, yksiköstä ja muista säännöistä. Nämä kaupalliset säännöt kuuluvat lähtöalustalle, joka jo hallinnoi niitä.
Näyttötyönkulku voi sitten keskittyä esitykseen. Desimaalipaikat, valuuttamerkit, yksikkötunnisteet, tekstin pituus ja saatavuudeton tila voidaan standardoida ilman, että hinnoittelulogiikkaa toistetaan.
Liikenne- ja kuljetustiedot tarvitsevat usein käännöstä ennen kuin niitä tarvitaan grafiikassa.
Kuljetusalustat voivat paljastaa reittitunnisteita, arvioidun saapumisajan, laitoksen, viiveen tilan, palvelukoodin tai tapahtuman tilan. Raakarvot voivat olla suunniteltu ohjelmistokäyttöön eikä julkiseen esitykseen.
Välitaso voi vähentää tätä monimutkaisuutta kääntämällä sisäiset koodit vakiona pysyväksi näyttömalleiksi. Toistin saattaa vastaanottaa vain kohteen, odotetun ajan ja hyväksytyn tilan tekstin. Jos lähde muuttuu myöhemmin, esitystaso voi pysyä suurelta osin muuttumattomana.
Päätä, mikä kerros omistaa kunkin päätöksen ennen ohjelmistotyön aloittamista
Integrointi vaikeutuu, kun useat järjestelmät jakavat hiljaa saman vastuun. Lähdeohjelma voi muotoilla näyttötekstiä. Toistin saattaa alkaa tulkita liiketoimintatilakoodien merkitystä. Toinen skripti saattaa pitää erillistä välimuistia. Tulos voi silti toimia esittelyssä, mutta virheenkorjaus vaikeutuu huomattavasti, kun mikään muuttuu.
Siistimpi arkkitehtuuri pitää rajat ymmärrettävinä. Lähde omistaa liiketoimintatiedon. Välitason ohjelmisto päättää, sopiiko tieto esittämiseen. Toistin omistaa visuaalisen näytön. LED-ohjauspolku omistaa fyysisen tulostuksen.
Julkaise hyväksytyt tallenteet, lähteen aikaleimat, tunnisteet ja lähteen puolen tilat.
Vahvista, kartoita, normalisoi, välimuistaa, tarkista ikä ja valitse sopiva tila.
Sijoita hyväksytyt arvot alueisiin, yhdistä ne mediatiedostojen kanssa ja renderöi visuaalinen näyttö.
Käsittele lopullinen näyttöulos, älä tulkkaa jonotus-, sää- tai hinnoittelusemantiiikkaa.
Tämä jakaminen tekee myös projektin laajuuden keskustelusta helpompaa. "API-integraatio" voi muuten kuvata useita täysin erilaisia tehtäviä. Se voi tarkoittaa ulkoisen syötteen noutamista, välipalvelimen rakentamista, datan kartoittamista pelaajapohjaan tai useiden dynaamisten alueiden koordinointia yhdessä fyysisessä näytössä.
Kun informaatioarkkitehtuuri vaikuttaa näytön geometriaan, Mukautettu led-näyttö projekti voi koordinoida nämä kaksi puolta yhdessä. Pysyvä jonoalue, sääpalkki, liikenneluettelo tai monialueinen informaatiokangas saattavat vaatia sekä fyysisiä mittoja että ohjelmallisesti määritettyjä alueita samassa vaiheessa.
Kiinteä informaationäyttömuoto
Kaappi on fyysinen päätepiste. Alueiden lukumäärä, informaatiohierarkia ja palvelukäyttö edellyttävät edelleen sopeutumista lopulliseen näyttögeometriaan.
Katso 960×960 LED-näyttö
Modulaarinen informaatiokangas
Modulaarinen laitteisto voi muodostaa eri kokonaiskokoisia järjestelmiä, kun taas datavyöhykkeet ja varalla toiminta pysyvät määriteltyinä sisältöjärjestelmän tasolla.
Näytä 500 × 500 LED-näyttöMääritä, mitä kukin näkyvä kenttä tarkoittaa ennen lopullisen asettelun rakentamista
"Yhdistä säätietojen API" tai "näytä jonotiedot" kuulostaa selkeältä varhaisessa keskustelussa. Käytännössä molemmat ilmaukset jättävät suurimman osan tärkeistä integraatiopäätöksistä avoimiksi.
Hyödyllisempi lähtökohta on pieni datasopimus. Se yhdistää yhden näkyvän elementin yhteen määriteltyyn lähdekenttään ja tallentaa riittävästi kontekstia, jotta voidaan päätellä, voidaanko kyseinen arvo turvallisesti näyttää.
Kentän nimi yksinään harvoin selittää liiketoiminnallista merkitystä
Ominaisuuden nimi statusvoi tarkoittaa palvelun saatavuutta, API:n toimintakykyä, tietueen voimassaoloa, jonon tilaa tai reitin ehtoa. Kentän nimi wait_timeedellyttää edelleen yksikköä ja määritelmää.
Siksi kentän määritelmän tulisi kuvata sekä merkitys että syntaksi. Tämä pieni askel estää teknisesti oikean integraation esittämästä väärää tulkintaa.
Nolla, tyhjä ja saatavilla olematon tila tulee säilyttää eri tiloina
Jonan lukumääräksi nolla voi olla täysin kelvollinen liiketoimintatieto. Tyhjä kenttä voi tarkoittaa, että aktiivista tietuetta ei ole. Puuttuva avain voi viitata puutteelliseen dataan. Epäonnistunut pyyntö taas tarkoittaa jotain muuta.
Näiden tilojen yhdistäminen johtaa harhaanjohtavaan tulosteeseen. Näyttömalli tulee säilyttää erot, kunnes hyväksytty esityssääntö määrittelee, miltä kukin tila näyttää.
Tekstin pituus kuuluu datakeskusteluun
Dynaamiset asetteluvariaatiot usein epäonnistuvat visuaalisesti ennen kuin ne epäonnistuvat teknisesti. Testauksen aikana sopiva kohdenimi voi olla huomattavasti pidempi normaalikäytössä. Palveluviesti voi rivittyä toiseen alueeseen. Suuri hinta voi vaatia enemmän numeroita kuin alkuperäinen malli salli.
Siksi tekstimäisiin kenttiin tarvitaan tunnettu visuaalinen sääntö. Projekti voi käyttää hyväksyttyä lyhennettä, rivitystä, katkaisua, toista mallitilaa tai eri alueen leveyttä. Tekstin hiljainen pienentäminen, kunnes se muuttuu luettavuudeltaan huonoksi, on harvoin hyvä vararatkaisu.
| Kentän kysymys | Mitä integraation täytyy tietää |
|---|---|
| Mistä se tulee? | Virallinen sovellus, palvelu, paikallinen järjestelmä tai hyväksytty lähde. |
| Mitä se tarkoittaa? | Liiketoiminnallinen merkitys, yksikkö, aikaleiman merkitys ja sallitut tilat. |
| Onko se pakollinen? | Voiko alue edelleen olla voimassa, kun tätä kenttää ei ole annettu. |
| Kuinka tuore se on? | Lähteen aikaleima ja suurin hyväksytty ikä nykyiselle esitykselle. |
| Mitä voi rikkoa sen? | Puuttuva arvo, virheellinen muoto, tuntematon tila, vanha aikaleima tai saatavilla olematon lähde. |
| Missä se näkyy? | Tarkan näytöalueen, muotoilusäännön ja odotetun tekstin pituuden määrittely. |
| Mikä sen korvaa? | Viimeisin hyväksytty arvo, neutraali viesti, paikallinen media, piilotettu alue tai muu hyväksytty varavaihtoehto. |
"Todellisaikainen" on liian epämääräinen ilmaisu, kunnes päivitys ja ajantasaisuus erotellaan toisistaan
Yksi helpoimmista RFQ-virheistä on kirjoittaa vain "todellisaikainen päivitys". Ilmaisu kuulostaa tarkalta, mutta se voi kuvata täysin erilaisia toimintavaatimuksia.
Jonotapahtuman täytyy ehkä näkyä nopeasti, koska tiedot muuttavat välittömästi palveluvirtaa. Säädata voi noudattaa hitaampaa julkaisukulkua. Edistysmyynnin hinta voi pysyä muuttumattomana, kunnes hyväksytty kaupallinen tapahtuma tapahtuu. Nämä tiedonvirrat eivät tarvitse identtistä päivityskäyttäytymistä pelkästään siksi, että ne jakavat yhteisen näytön.
Päivitysväli kysyy, kuinka usein järjestelmä etsii uutta tietoa
Kysely voi tarkistaa API:ta määritellyn välin päässä. Webhook voi toimittaa muutoksen tapahtuman sattuessa. Toinen paikallinen lähde voi julkaista tiedoston tai viestin vain silloin, kun uusi tietue on olemassa.
Päivitysmekanismi tulisi noudattaa jo olemassa olevaa lähdettä. Samaa säätietopistettä pyytämällä toistuvasti ei saada tuoreempaa säätietoa, jos tarjoaja ei ole julkaissut uutta havaintoa.
Tuoreus kysyy, kuinka vanhaksi viimeinen hyväksytty arvo saa muodostua.
Tämä kysymys on yleensä hyödyllisempi. Yhteys voi pysyä terveenä, vaikka lähde jatkaisi vanhan tiedon palauttamista. Siksi näytön tulee sisältää erillinen sääntö liiketoimintatiedon ikästä itsessään.
Kun tämä ikä ylittää sovitun kynnysarvon, järjestelmä voi lopettaa arvon esittämisen nykyisenä. Tässä vaiheessa välimuistin ja varatietojen logiikka muodostuu osaksi sisältösuunnittelua eikä ainoastaan TI:n huolenaiheeksi.
Kuinka usein integraatio pyytää, vastaanottaa tai tarkistaa uutta tietuetta?
Kuinka vanhaksi viimeinen hyväksytty tietue saa muodostua ennen kuin näyttö pitäisi lopettaa sen käsittelyn nykyisenä?
Varmuusvarainen sisältö tulisi heikentää viestiä sujuvasti, ei piilottaa vikaa
Elävän tiedon visualisoinnin on säilyttävä merkityksellisenä, vaikka lähtetieto katoaisi. Ilman tätä näyttö voi jäätyä vanhaan tietoon, paljastaa tyhjän tekstikentän, näyttää sovellusvirheen tai jättää suuren tyhjän alueen.
Tehokkain varatila ei ole yleensä yksittäinen hätätilanne-näyttö. Parempi suunnittelu mahdollistaa tiedon vaiheittaisen heikkenemisen. Lyhyet katkokset voivat säilyttää viimeisimmän hyväksytyn tiedon. Vanhemmat tiedot voivat siirtyä vanhentuneeseen tilaan. Lopuksi neutraali paikallinen näkymä voi korvata tiedon, jota ei enää pitäisi esittää ajantasaisena.
Välimuistiin tallennetaan viimeisin hyväksi tunnettu tietue, ei pelkästään viimeinen vastaus
Virheellinen vastaus ei saa korvata ainoaa luotettavaa paikallista tietuetta. Uusi tieto voi kuitenkin läpäistä vahvistuksen ennen kuin se korvaa välimuistin.
Järjestys on periaatteessa yksinkertainen: vastaanota uusi tietue, tarkista se, normalisoi se, hyväksy se ja päivitä sitten tallennettu viimeisin hyväksi tunnettu tila. Kun uusi vastaus ei läpäise näitä tarkistuksia, kelvollinen välimuisti pysyy käytettävissä, kunnes sen hyväksytty ikä vanhenee.
Yhden epäonnistuneen syötteen epäonnistuminen ei välttämättä tuhoa koko näyttöä
Sekalainen informaationäyttö voi sisältää säätietoja, aikaa, jonotustietoja ja aikataulutettua mediaa. Jos säätiedot eivät saada päivitystä, jonotuspalvelu voi silti toimia normaalisti ja paikallinen media voi olla edelleen käytettävissä.
Alueellinen varasuoja voi säilyttää näytön hyödylliset osat. Säätiedot muuttavat tilaansa, kun taas jonotusalue jatkaa päivityksiään. Tämä tuottaa hallitumman tuloksen kuin koko näytön korvaaminen, koska yksi ulkoinen lähde on tullut käyttökelvottomaksi.
Uskottava korvaus voi olla huonompi kuin tiedon saatavuuden puutteesta ilmoittava viesti
Oletustiedon ei pitäisi keksiä uskottavaa arvoa. Keksitty lämpötila on edelleen väärin. Nollaa ei pitäisi käyttää jonotustilan korvaamiseen, ellei nolla todella merkitse sitä liiketoiminnallisessa mielessä. Vanhaa hintaa ei pitäisi säilyttää ikuisesti vain siksi, että se sopii edelleen asettelun mukaiseen paikkaan.
Neutraali varatilanne on yleensä turvallisempi. Sovelluksesta riippuen alue voi näyttää yleistä palvelutietoa, staattisen sijaintipaneelin, hyväksytyn ei-saatavilla -tilan tai muun paikallisesti kelvollisen näkymän, joka säilyy voimassa ilman ulkoista tietovirtaa.
Palautuminen ansaitsee oman sääntönsä
Kun lähde palaa, ensimmäinen vastaus ei saa automaattisesti poistaa varatilannetta ennen kuin normaalit tarkistukset suoritetaan. Uuden tiedon on edelleen täytettävä samat kenttä- ja ajantasaisuusvaatimukset kuin muissakin elävissä päivityksissä.
Tämä tulee erityisen hyödylliseksi, kun ylävirtapalvelu on epävakaa. Muuten näkyvä alue voi vaihdella toistuvasti varatilanteen ja elävän sisällön välillä, kun lähdeyhteys heilahtelee.
Parannettu RFQ kuvaa tietovirtaa, ei vain näytön kokoa
Näytön leveys, korkeus ja asennusehdot pysyvät olennaisina. Ne eivät kuitenkaan selitä, sisältääkö valmis kuvakenttä yhden kellon vai kuusi riippumatonta elävää tietovirtaa.
Integrointikuvauksesta tulee paljon selkeämpi, kun se vastaa kolmeen käytännölliseen kysymykseen: mikä tieto tulee sisään, kuinka nopeasti se voi muuttua ja kuinka monta näytön osaa riippuu siitä.
Aloita lähteestä, ei ohjelmistomerkistä
Jokaisella elävässä ajassa päivittyvällä tietotyypillä pitää olla tunnettu lähde. Lähde voi olla jonoplattforma, sääpalvelu, sisäinen hintatietokanta, liikennepalvelu, kuljetusjärjestelmä tai muu hyväksytty liiketoimintasovellus.
Varhainen kuvaus voi sitten ilmoittaa, onko rajapintadokumentaatio jo olemassa ja onko käytettävissä REST-rajapinta, webhook, paikallinen palvelu, viestivirta, rakennettu tiedosto tai muu vahvistettu menetelmä. Jos menetelmää ei vielä tiedetä, on parempi pitää kyseinen kohta avoinna kuin arvata.
Pieni esimerkkipayload voi vastata useisiin kysymyksiin yhtä aikaa
Siivottu näyte voi näyttää kenttien nimet, tietotyypit, aikaleimat ja tilarakenteen ilman tuotantosalasanojen tai luottamuksellisten tietueiden paljastamista. Tämä paljastaa usein hyödyllisempää tietoa kuin pitkä yleiskuvaus alustasta.
Esimerkiksi jonopaketti, joka sisältää palvelukoodin, jononumeron, laskurin, tilan ja päivityksen aikaleiman, osoittaa välittömästi, mitkä kentät saattavat vaatia kuvauksen ja mitkä arvot vaikuttavat visuaaliseen tilaan.
Alueiden määrä muuttaa integraation laajuutta
Koko näytön säätapaus on suhteellisen yksinkertainen, koska yksi lähde hallinnoi suurinta osaa muuttuvasta sisällöstä. Sekoitettu näyttö voi olla erilainen. Aika voi olla paikallinen, säätiedot voivat tulla ulkoiselta tarjoajalta, jonotietoja voi tulla sisäiseltä alustalta ja aikataulutettu media voi täyttää jäljelle jääneen tilan.
Siksi itsenäisesti ohjattavien alueiden lukumäärä kuuluu pyyntöön tarjouksesta (RFQ). Jokainen alue voidaan sen jälkeen yhdistää omaan lähteeseensä, päivityskäyttäytymiseensä, varatilaansa ja visuaaliseen prioriteettiinsä.
RFQ ei vaadi ohjelmistospesifikaatiota. Siihen tarvitaan nämä päätökset.
Testaa epämukavat tietotilanteet ennen kuin näyttö menee käyttöön
Täydelliset esimerkkitiedot osoittavat, että asettelu voidaan renderöidä. Ne eivät kuitenkaan osoita, että tietojärjestelmä kykenee epäonnistumaan turvallisesti.
Integrointitestaus kasvattaa arvoaan, kun se tahallisesti rikkoo normaalin tilanteen taustalla olevia oletuksia. Pakollinen kenttä voi kadota. Tilakoodi voi muuttua odottamattomaksi. API voi pysyä saavutettavana, vaikka sen aikaleima ei enää muuttuisikaan. Tiedonsyöte voi kadota niin kauan, että välimuistissa olevat tiedot vanhenevat.
Pitkä, mutta kelvollinen teksti kuuluu myös testaukseen. Kohde, jossa on enemmän merkkejä, suurempi hinta tai pidempi tilaviesti, voi paljastaa visuaalisia ongelmia, joita lyhyet kehitysarvot eivät koskaan näytä. Nämä testit ovat yksinkertaisia, mutta ne estävät usein näkyvämpiä vikoja useampaa normaalien arvojen ruutukuvien ottamista.
Usein kysytyt kysymykset
Mikä on todellinen ero elävän datan LED-näytön ja tavallisen aikataulutetun toiston välillä?
Aikataulutettu toisto valitsee yleensä valmiita medioita ajan mukaan. Liven tiedot riippuvat muualla luoduista arvoista, joten näyttötyönkulun on myös päätettävä, ovatko kyseiset arvot voimassa ja ajantasaisia. Pääero ei ole visuaalisessa animaatiossa, vaan ulkoisen tiedon tilaan perustuvassa riippuvuudessa.
Mitä API:n, välitaso-ohjelmiston, toistimen ja LED-ohjausjärjestelmän pitäisi tehdä kunkin osalta?
Lähde tai API:n tulisi tarjota virallista tietoa. Välitaso-ohjelmisto voi varmistaa tietojen oikeellisuuden, normalisoida niitä, välimuistittaa ja arvioida niiden ajantasaisuutta. Toistin muuntaa hyväksytyt arvot visuaaliseksi asetteluksi. LED-ohjauspolku lähettää valmiin visuaalisen tulosteen näyttölaitteelle. Joissakin alustoissa useita toimintoja yhdistetään, joten lopullinen rajaus edellyttää edelleen projektikohtaista vahvistusta.
Milloin päivitystaajuus tulisi vahvistaa sää-, jonotus-, hinta- tai liikennevirtoihin?
Päätös tulisi tehdä ennen kuin integraation laajuus ja hyväksyntätestaus on viimeistelty. Lähteen päivityskäyttäytymistä ja suurinta hyväksyttävää tietojen ikää tulisi käsitellä erikseen, koska ne ratkaisevat eri ongelmia. Samalla näytöllä olevilla eri alueilla voi myös olla erilaisia päivityspolitiikoita.
Mitä tapahtuu, kun ulkoinen tietolähde lopettaa päivittämisen?
Viimeisin hyväksytty tietue voi säilyä vain niin kauan kuin se on hyväksytyn tureshuuden aikarajassa. Tämän jälkeen vaikutettu alue voi siirtyä neutraaliin varatietoon. Muut toimivat alueet voivat jatkaa normaalisti. Kun tureshet tietoja saadaan uudelleen, niiden tulee läpäistä normaali validointi ennen kuin elävä näyttö palaa käyttöön.
Mikä tieto on kaikista hyödyllisintä lainausvaiheessa?
Vahvin aloitustiivistelmä määrittelee jokaisen lähteen, tunnetun rajapintamenetelmän, vaadittavat kentät, odotetun päivityskäyttäytymisen, hyväksyttävän tiedon iän, dynaamisten alueiden määrän, varatilavaatimuksen ja saatavilla olevan esimerkkipayloadin. Verkkosijainti ja testipääsyn tila voivat myös auttaa määrittämään integraation rajat ennen yksityiskohtaista ohjelmistotyötä.
Paras reaaliaikaisen datan näyttö pitää liiketoimintalogiikan ylävirtassa ja esityksen selkeänä
Jonotusalusta tulisi edelleen päättää jonotilasta. Hinnoittelualusta tulisi edelleen omistaa hinnat. Kuljetussovelluksen tulisi edelleen omistaa kuljetustiedot. Näyttö ei tule luotettavammaksi kopioimalla kyseisiä liiketoimintasääntöjä jokaiseen toistimeen.
Sen sijaan integraatio voi poimia vain esitykseen vaadittavan tiedon, päättää, onko kunkin tietueen edelleen sopivaa näyttää, ja välittää siistin näyttömallin eteenpäin. Tämä erottelu tekee myös myöhempät muutokset helpommiksi, koska näytön asettelu ei tarvitse ymmärtää ylävirran järjestelmän jokaista yksityiskohtaa.
Ennen tarjouksen laatimista kolme päätöstä luo selkeimmän lähtökohdan:
- Kartoita toiminnallisesti aktiiviset alueet. Merkitse, mikä lähde ja mitkä kentät ohjaavat kutakin näkyvää aluetta.
- Määritä sekä tiedon ikä että päivitysnopeus. Toimiva yhteys ei takaa, että näytetty tieto on edelleen ajantasalla.
- Suunnittele vararatkaisu ennen kuin live-syöte kytketään. Välimuistin kesto, vanhentunut tila, neutraali sisältö ja palautuminen eivät saa jäädä improvisoiduiksi käyttöönoton jälkeen.
Valmista tietolähteen kuvaus ennen integraation tarkistusta.
Toimita tietolähteen tyyppi, saatavilla oleva API- tai rajapintadokumentaatio, vaaditut kentät, odotettu päivitystiheys, hyväksyttävä tiedon ikä ja itsenäisesti ohjattavien näyttöalueiden lukumäärä.
Jos saatavilla, lisää siivottu esimerkkipayload, aluekarttaus, verkkosijainti, välimuistivaatimus, varaskenaariotilanne ja palautussääntö. Nämä tiedot mahdollistavat tarkistuksen mukautettu LED-näyttöpaneeli tietojärjestelmän päätepisteenä eikä hoida projektia yleisenä pyynnönä API-yhteydestä.
Lähetä tietojen integrointivaatimukset
