EN
A egyedi LED kijelző panel egy másfajta megjelenítővé válik, ha a képernyőn látható információ egy változó üzleti rendszerből származik. Egy időjárás-hőmérséklet lejártával elavulhat. Egy sorban álló szám átkerülhet egy másik pult elé. Egy közlekedési szolgáltatás késésbe kerülhet. Egy ár megváltozhat, miközben a háttérkép pontosan ugyanolyan marad. Ezekben a projektekben a képernyő nem csupán médiafájlokat játszik le. Hanem egy másik információs rendszer jelenlegi állapotát mutatja be.
Ez megváltoztatja a műszaki kérdést. A nehézség ritkán abban rejlik, hogy egy szám köré dobozt rajzolunk vagy egyszer összekötünk egy API-t. Ehelyett a fontos döntések azok, hogy mindegyik érték honnan származik, melyik réteg dönti el, hogy továbbra is megbízható-e, hogyan osztják meg egymással a különböző élő régiók ugyanazt a vásznat, és mi jelenik meg, ha az adatforrás frissítése megszűnik. Ez az útmutató e határvonalon marad: külső üzleti adatok belépése a tartalomfolyamatba, valamint a visszatérési logika, amely biztosítja, hogy a képernyő akkor is értelmes maradjon, ha az élő adatok nem érhetők el.
Ugyanazt az LED-képernyőt három nagyon különböző típusú tartalommal is lehet működtetni
Egy LED képernyő tábla megjeleníthet egy kampányképet, követhet egy időzített lejátszási listát, és ugyanazon a fizikai felületen mutathatja a valós idejű sorban állók számát. Látványilag ezek az elemek egyformán egyszerűnek tűnhetnek. Működési szempontból azonban nagyon eltérően viselkednek.
A előkészített kép már létezik a lejátszás megkezdése előtt. A ütemezett jelenet már tudja, mikor kell megjelennie. A valós idejű információ más, mert az érték akár csak akkor jöhet létre, amikor egy másik rendszer szolgáltatja. Ennélfogva a valós idejű adatok függőséget hoznak létre, amelyet a statikus média nem igényel.
A statikus tartalom azért marad fenn, mert a médiaelem már létezik
Egy tárolt kép vagy videó elsősorban egy média-probléma. Amint az elfogadott fájl eléri a helyi lejátszási tárhelyet, a képernyő továbbra is mutathatja, amíg egy későbbi médiaelem felül nem írja. A hálózati kapcsolat továbbra is fontos lehet a távoli feltöltésekhez, de a látható tartalom maga nem igényel minden egyes képkocka megjelenítésekor egy másik platform válaszát.
Ez a különbség fontos a hibakezelési terv elkészítésekor. Ha egy hálózati kapcsolat rövid ideig megszűnik, egy tárolt kampányjelenet továbbra is normálisan működhet. Ezzel szemben egy sorban álló szám vagy a jelenlegi szállítási állapot esetleg nem.
A ütemezett tartalom az időtől függ, de nem feltétlenül külső adatoktól
Egy menetrend egy további réteget ad hozzá anélkül, hogy feltétlenül külső adatforrást vezetne be. A reggeli tartalom a lejátszó órája szerint átkapcsolhat délutáni jelenetre. Hasonlóképpen egy ütemezett szolgáltatási értesítés meghatározott időpontokban indítható és állítható le, miközben minden média helyileg marad tárolva.
Ebben a modellben a kulcskérdés az, hogy a menetrend és az óra pontosak-e. A valós idejű adatok nehezebb kérdést vetnek fel: az éppen megjelenített információ továbbra is tükrözi-e a forrás jelenlegi állapotát.
Egy valós idejű érték hosszú ideig egészségesnek tűnhet, még akkor is, ha már rég nem friss
Ez az egyik legegyszerűbben elmulasztott kockázat. Egy kapcsolódási hiba gyakran nyilvánvalónak tűnik, mert egy kérés hibát ad vissza. A elavult információ veszélyesebb, mert továbbra is teljesen normálisnak tűnhet.
Egy hőmérséklet érték továbbra is látható maradhat, még akkor is, ha az időjárásforrás órákkal korábban állt le a frissítéssel. Egy közlekedési sor továbbra is megjelenítheti egy régi érkezési becslést. Egy árpanel megtarthat egy korábbi értéket anélkül, hogy bármilyen nyilvánvaló jelet mutatna arra, hogy a felsőbb szintű rekordja lejárt. Ezért a valós idejű megjelenítés tervezésének szüksége van egy fogalomra, amelyre a statikus médiának ritkán van szüksége: frissesség .
A kép vagy videó már létezik. A tárolás és a lejátszás dönti el, hogy megjelenik-e.
Az előkészített média egy óra, naptár, eseményablak vagy más időbeosztás alapján változik.
Az érték egy másik információs rendszerből származik, ezért fontos a kor, az érvényesség és a hibaműködés.
Egy hasznos tervezési rövidítés: osztályozza el minden látható régiót, mielőtt a szoftverről beszélne. Egy állandó logó statikusan maradhat. A promóciós média követheti egy ütemtervet. Egy sorban álló szám élőként maradhat. Egy jóváhagyott szolgáltatási üzenet felülírhatja mindhármat. Ez az egyszerű megkülönböztetés összpontosítja az integrációs megbeszélést.
Kövesse az adatot az eredeti forrásától egészen egy látható régióig
Az élő információ gyakran megtévesztően kicsi méretűnek tűnik a képernyőn. Egy időjárásblokk egy hőmérsékletet és egy időjárási feltételt tartalmazhat. Egy sorban álló kijelző csak egy számot és egy számlálót jeleníthet meg. Ennek ellenére ezek a kevés látható mező több rendszeren is áthaladhat, mielőtt használhatóvá válnak.
A legegyszerűbb módja annak, hogy megértsük az integrációt, ha egy értéket követünk, ahelyett, hogy egyszerre az egész szoftververmet vizsgálnánk. Vegyük példaként egy sorban álló számot. A sorkezelő platform létrehozza a üzleti állapotot. Egy interfész teszi elérhetővé a megfelelő rekordot. Egy másik réteg ellenőrzi és előkészíti az értéket. A lejátszó a megfelelő régióba helyezi. Csak ekkor éri el a végső vizuális vászon az LED-rendszert.
Az idő dinamikus, de esetleg nem igényel külső forrást
Egy óra minden másodpercben változik, mégis gyakran helyileg is generálható. Ebben az esetben a figyelem a külső API-ról az óra szinkronizációjára, az időzónára, a dátumformátumra, az újraindítási viselkedésre és a kijelzők közötti konzisztenciára terelődik.
Ez hasznos emlékeztető arra, hogy a „valós idejű” nem jelent automatikusan „internetes API-t”. A megfelelő forrás attól függ, hol létezik már a hiteles információ.
Az időjárás-információhoz kevesebb mezőre van szükség, mint amennyit az időjárás-szolgáltatás valószínűleg biztosít
Egy időjárás-szolgáltatás nagy mennyiségű adatot tud megjeleníteni. A kijelzőnek talán csak a hely, a jelenlegi hőmérséklet, az időjárási állapot, az ikon állapota és a forrás időbélyege szükséges. Az összes elérhető mező lekérése több függőséget teremt anélkül, hogy javítana a látható eredményen.
Ezért a jobb kérdés nem az, hogy „Csatlakoztatható-e a időjárás-API?”, hanem az, hogy „Mely időjárás-mezők jelennek meg valójában, és mennyire lehetnek régiek ezek a mezők, mielőtt az időjárásrégió állapota megváltozik?”
A soradatok egy állapotot jelentenek, nem csupán egy nagy számot
A sorinformáció tartalmazhat hívott számot, pultot, szolgáltatási kategóriát, állapotot és időbélyeget. A szám önmagában nem magyarázza meg, hogy épp most hívták-e, továbbra is aktív-e, befejeződött-e, vagy egy régi rekordhoz tartozik-e.
Itt lényeges a forrás jelentése. Egy üres érték nem válik automatikusan nullává. Hasonlóképpen egy hiányzó mező nem jelent automatikusan „nincs sor”. Ezek az állapotok nagyon különböző működési feltételeket tükrözhetnek.
Az árak jóváhagyott értékként érkezzenek, ne pedig a képernyőn újraszámítva
Az árinformáció függhet a pénznemtől, termékazonosítótól, helytől, hatályos időszaktól, akciós állapottól, egységtől és egyéb szabályoktól. Ezeket a kereskedelmi szabályokat a forrásplatformnak kell kezelnie, amely már birtokolja őket.
Ezután a megjelenítési munkafolyamat kizárólag a bemutatásra összpontosíthat. A tizedesjegyek, a pénznemjelek, az egységcímkek, a szöveghossz és az elérhetetlen állapotok szabványosíthatók anélkül, hogy a díjképzési logikát magát duplikálnánk.
A közlekedési és szállítási adatfolyamokat gyakran le kell fordítani, mielőtt grafikus megjelenítésre van szükség.
A közlekedési platformok útvonal-azonosítókat, becsült érkezési időt, peroninformációt, késési állapotot, szolgáltatási kódot vagy baleseti státuszt jeleníthetnek meg. A nyers értékek gyakran a szoftver számára, nem pedig a nyilvános megjelenítésre lettek tervezve.
A köztes réteg csökkentheti ezt a bonyolultságot, ha a belső kódokat stabil megjelenítési modellbe fordítja le. A lejátszó például csak a célállomást, az elvárt időpontot és az elfogadott státuszszöveget kapja meg. Ha a forrás később megváltozik, a megjelenítési réteg nagyrészt változatlan maradhat.
Döntse el, melyik réteg felelős egyes döntésekért, még a szoftverfejlesztés megkezdése előtt
Az integráció nehézzé válik, ha több rendszer csendben megosztja ugyanazt a felelősséget. Egy forrásalkalmazás formázhatja a megjelenítendő szöveget. Egy lejátszó kezdheti értelmezni a üzleti állapotkódokat. Egy másik szkript külön gyorsítótárat tarthat fenn. Az eredmény még mindig működhet bemutatáskor, de valami változása esetén a hibaelhárítás lényegesen nehezebbé válik.
Egy tisztább architektúra érthetővé teszi a határokat. A forrás birtokolja az üzleti tényt. A köztes réteg dönti el, hogy a tény alkalmas-e megjelenítésre. A lejátszó birtokolja a vizuális jelenetet. Az LED-vezérlési útvonal birtokolja a fizikai kimenetet.
Tárd fel a jóváhagyott rekordokat, a forrás időbélyegeit, azonosítókat és a forrás oldali állapotokat.
Érvényesítsd, térképezd, normalizáld, gyorsítótárazd, ellenőrizd a korát, és válaszd ki a megfelelő állapotot.
Helyezd be az elfogadott értékeket a megfelelő régiókba, kombináld őket médiaelemekkel, és jelenítsd meg a vizuális jelenetet.
A végleges megjelenítési kimenet kezelése, nem pedig a sorban állás, az időjárás vagy az árak szemantikájának értelmezése.
Ez a felosztás emellett egyszerűbbé teszi a projektkörök megbeszélését. Az „API-integráció” ugyanis máskülönben több, egymástól teljesen eltérő feladatot is jelenthet: külső adatforrás lekérése, közvetítőszoftver építése, adatok leképezése egy lejátszó sablonba, vagy több dinamikus régió koordinálása egyetlen fizikai képernyőn belül.
Amikor az információarchitektúra befolyásolja a képernyő geometriáját, egy Egyedi led kijelző projekt összehangolhatja e két oldalt. Egy állandó sorban állási blokk, időjárás-sáv, közlekedési listával vagy többzónás információs vászonnal rendelkező megoldás esetén a fizikai méretek és a szoftveres régiók egyidejű figyelembevétele szükséges.
Rögzített információs képernyőformátum
A tok a fizikai végpont. A régiók száma, az információhierarchia és a szolgáltatáselérés továbbra is illeszkedniük kell a végső megjelenítési geometriához.
960×960 LED-kijelző megtekintése
Moduláris információs vászon
A moduláris hardver különböző összképeket alkothat, miközben az adattartományok és a visszakapcsolási viselkedés továbbra is a tartalomszintű rendszer szintjén maradnak meghatározva.
500×500 LED kijelző megtekintéseHatározza meg, hogy minden látható mező mit jelent, mielőtt elkészítené a végső elrendezést
„Kapcsolja össze az időjárás-API-t” vagy „jelenítse meg a soradatokat” – ezek az állítások korai megbeszélések során egyértelműnek tűnnek. Gyakorlatban mindkét megfogalmazás nyitott kérdést hagy a legfontosabb integrációs döntésekkel kapcsolatban.
Egy kis adatszerződés a hasznosabb kiindulási pont. Ez egy látható elemet köt össze egy meghatározott forrásmezővel, és rögzít elegendő kontextust ahhoz, hogy eldönthessük: biztonságosan megjeleníthető-e az érték.
Egy mezőnevet egyedül ritkán magyaráz meg a vállalkozási jelentése
Egy tulajdonság neve statusszolgáltatás-elérhetőséget, API-állapotot, rekord-érvényességet, sorállapotot vagy útvonal-feltételt is jelenthet. Egy mező neve wait_timemég mindig szükség van mértékegységre és meghatározásra.
Ezért a mező meghatározásának nemcsak a szintaxist, hanem a jelentést is le kell fednie. Ez a kis lépés megakadályozza, hogy egy technikailag helyes integráció rossz értelmezést mutasson.
A nulla, az üres és az elérhetetlen állapotokat különálló állapotként kell kezelni
A sorban állók száma nulla értéke lehet érvényes üzleti adat. Egy üres mező azt jelentheti, hogy nincs aktív rekord. Egy hiányzó kulcs hiányos adatokra utalhat. Egy sikertelen kérés pedig más okból következhet be.
Ezen állapotok összeolvasztása félrevezető kimenetet eredményez. A megjelenítési modellnek meg kell őriznie a különbséget, amíg egy jóváhagyott megjelenítési szabály nem dönti el, hogy mindegyik feltétel hogyan nézzen ki.
A szöveghossz a adatokkal kapcsolatos megbeszélések tárgya
A dinamikus elrendezések gyakran vizuálisan is megbuknak, még mielőtt technikailag megbuknának. Egy célállomás neve tesztelés közben illeszkedhet, de normál működés során sokkal hosszabb lehet. Egy szolgáltatási üzenet más régióba csúszhat. Egy nagyobb ár több számjegyet igényelhet, mint amennyit az eredeti sablon engedélyezett.
Ennélfogva a szövegterhelésű mezők esetében ismert vizuális szabályra van szükség. A projekt elfogadott rövidítést, sortörést, lezárást (truncation), más sablonállapotot vagy más régiószélességet használhat. A szöveg csendes kicsinyítése addig, amíg olvashatatlan nem lesz, ritkán jó tartalék megoldás.
| Mező kérdése | Mit kell tudnia az integrációnak |
|---|---|
| Honnan származik? | A hiteles alkalmazás, szolgáltatás, helyi rendszer vagy jóváhagyott forrás. |
| Mit jelent ez? | Üzleti jelentés, mértékegység, időbélyeg jelentése és engedélyezett állapot. |
| Kötelező-e? | A régió továbbra is érvényes maradhat-e, ha ez a mező hiányzik. |
| Mennyire friss? | Forrás időbélyege és a jelenlegi megjelenítéshez engedélyezett legnagyobb kor. |
| Mi rombolhatja el? | Hiányzó érték, érvénytelen formátum, ismeretlen állapot, régi időbélyeg vagy elérhetetlen forrás. |
| Hol jelenik meg? | A pontos képernyőrégió, formázási szabály és a várt szöveghossz. |
| Mivel cseréljük fel? | Utoljára elfogadott érték, semleges üzenet, helyi média, elrejtett régió vagy más, jóváhagyott tartalék megoldás. |
„Valós idejű” túl homályos kifejezés, amíg a frissítés és az aktuális információ elkülönítése nem történik meg
Az egyik legegyszerűbb RFQ-hiba, ha csak annyit írunk, hogy „valós idejű frissítés”. A kifejezés pontosnak tűnik, de teljesen eltérő működési elvárásokat írhat le.
Egy sorban álló eseménynek gyorsan meg kell jelennie, mert az információ azonnal befolyásolja a szolgáltatási folyamatot. Az időjárás-adatok lassabb közzétételi ciklust követhetnek. Egy akciós ár akkor sem változhat, amíg egy jóváhagyott kereskedelmi esemény nem következik be. Ezek az adatforrások nem igényelnek azonos frissítési viselkedést csupán azért, mert ugyanazon a képernyőn jelennek meg.
A frissítési időköz azt kérdezi, milyen gyakran keres új információt a rendszer
A lekérdezés (polling) meghatározott időközönként ellenőrizhet egy API-t. Egy webhook esemény bekövetkezésekor továbbíthatja a változást. Egy másik helyi forrás csak akkor publikálhat fájlt vagy üzenetet, ha új rekord létezik.
A frissítési mechanizmusnak követnie kell a már meglévő forrást. Ugyanannak az időjárás-végpontnak a többszöri lekérdezése nem eredményez frissebb időjárási adatokat, ha a szolgáltató nem tett közzé új megfigyelést.
A frissesség azt kérdezi, hogy mennyire lehet régi az utoljára elfogadott érték.
Ez a kérdés általában hasznosabb. Egy kapcsolat egészséges maradhat, miközben a forrás továbbra is egy régi rekordot ad vissza. Ezért a képernyőnek külön szabályra van szüksége a vállalkozási információk saját korára vonatkozóan.
Amint ez a kor eléri a megállapodott küszöböt, a rendszer abbahagyhatja az érték jelenleginek tekintését. Ekkor a gyorsítótár- és tartaléklogika a tartalomalakítás részévé válik, nem csupán egy IT-kérdés.
Milyen gyakran kérdezi le, fogadja vagy ellenőrzi az integráció az új rekordot?
Mennyire lehet régi az utoljára elfogadott rekord, mielőtt a képernyő abbahagyja jelenleginek tekintését?
A hibabiztos tartalomnak fokozatosan romlania kell az üzenet minőségén, nem pedig elrejtenie a hibát.
A valós idejű információknak értelmes vizuális állapotra van szükségük, még akkor is, ha az adatforrás eltűnik. Enélkül a képernyő lefagyhat a régi információkon, üres szövegmezőt jeleníthet meg, alkalmazáshibát mutathat, vagy egyszerűen nagy, üres területet hagyhat.
A legerősebb helyettesítő megoldás ritkán egyetlen vészhelyzeti képernyő. A jobb megoldás az, ha az információ fokozatosan romlik le. Rövid megszakítások esetén megtartható az utolsó elfogadott rekord. Régebbi adatok elavult állapotba kerülhetnek. Végül egy semleges, helyi jelenet váltja fel az információt, amelyet már nem szabad aktuálisként megjeleníteni.
Gyűjtsük be az utolsó jó rekordot, ne egyszerűen az utolsó választ
Egy hibás formátumú válasz nem írhatja felül az egyetlen megbízható helyi rekordot. Ehelyett az új adatok csak akkor cserélhetik fel a gyorsítótárat, ha sikeresen átmentek az érvényesítésen.
A sorrend elvileg egyszerű: fogadjuk be az új rekordot, ellenőrizzük, normalizáljuk, fogadjuk el, majd frissítsük a tárolt legutóbbi ismert jó állapotot. Ha egy új válasz nem felel meg ezeknek az ellenőrzéseknek, a helyes gyorsítótár továbbra is elérhető marad, amíg az engedélyezett élettartama le nem jár.
Egy sikertelen adatforrás nem feltétlenül rombolja fel az egész kijelzőt
Egy vegyes információs képernyő tartalmazhat időjárás-, idő-, várakozási sor- és ütemezett médiaadatokat. Ha az időjárás-adatforrás meghibásodik, a várakozási sor-platform továbbra is működőképes lehet, és a helyi média is elérhető maradhat.
A régióalapú biztonsági másolat megőrizheti a képernyő hasznos részeit. Az időjárás-régió állapota megváltozik, miközben a várakozási sor-régió továbbra is frissül. Ez ellenőrzöttebb eredményt eredményez, mint ha az egész kijelzőt lecserélnénk, mert egy külső forrás vált elérhetetlenné.
Egy hihető helyettesítés rosszabb lehet, mint egy „nem elérhető” üzenet
Az alapértelmezett információnak nem szabad kitalált, plauzibilis értéket megadnia. Egy kitalált hőmérséklet is téves. A nulla nem helyettesítheti a nem elérhető várakozási sor-állapotot, kivéve, ha a nulla ténylegesen ezt a üzleti jelentést hordozza. Egy régi ár ne maradjon örökké csupán azért, mert még mindig illeszkedik a kialakításhoz.
A semleges helyettesítő tartalom általában biztonságosabb. Az alkalmazástól függően a régió általános szolgáltatási információkat, egy statikus helymeghatározó panelt, egy jóváhagyott „nem elérhető” állapotot vagy egy másik olyan helyi jelenetet jeleníthet meg, amely érvényes marad a külső adatforrás hiányában.
A helyreállítás saját szabályt érdemel
Amikor az adatforrás újra elérhetővé válik, az első válasz nem törölheti automatikusan a helyettesítő állapotot, mielőtt a normál ellenőrzések lefutnának. Az új rekordnak továbbra is meg kell felelnie ugyanazoknak a mező- és frissességi szabályoknak, mint bármely más élő frissítésnek.
Ez különösen hasznos, ha egy felsőbb szintű szolgáltatás instabil. Egyébként a látható régió többször is váltogathat a helyettesítő és az élő tartalom között, miközben az adatforrás-kapcsolat ingadozik.
Egy jobb RFQ leírja az információáramlást, nem csupán a képernyő méretét
A képernyő szélessége, magassága és telepítési feltételei továbbra is alapvetőek. Azonban ezek nem magyarázzák meg, hogy a kész vászon egy órát vagy hat független élő adatfolyamot tartalmaz.
A integrációs rövidítés sokkal világosabbá válik, ha megválaszol három gyakorlati kérdést: milyen információ érkezik be, milyen gyorsan változhat, és hány képernyőrészlet függ tőle.
Kezdje a forrással, ne a szoftvermárkával
Minden élő információtípusnak ismert forrása legyen. Ez lehet egy üzenetsor-platform, egy időjárás-szolgáltató, egy belső áradatbázis, egy közlekedési szolgáltatás, egy közlekedési rendszer vagy egy másik jóváhagyott üzleti alkalmazás.
A korai rövidítés azt is megállapíthatja, hogy létezik-e már felület-dokumentáció, és hogy az elérhető kapcsolati mód REST API, webhook, helyi szolgáltatás, üzenetfolyam, strukturált fájl vagy egy másik megerősített módszer. Ha a módszer még nem ismert, akkor jobb, ha ezt a tényezőt nyitva hagyja, mint hogy találgasson.
Egy kis minta adattartalom egyszerre több kérdésre is választ adhat
Egy fertőtlenített minta megmutathatja a mezőneveket, az adattípusokat, az időbélyegeket és az állapotstruktúrát anélkül, hogy felfedné a gyártási környezetben használt hitelesítő adatokat vagy bizalmas rekordokat. Ez gyakran több hasznos információt nyújt, mint egy hosszú, általános leírás a platformról.
Például egy várakozási sorhoz tartozó adatcsomag, amely tartalmazza a szolgáltatási kódot, a sor számát, a pultot, az állapotot és az utolsó frissítés időbélyegét, azonnal feltárja, mely mezőkhez szükséges leképezés, és mely értékek befolyásolják a vizuális állapotot.
A régiók száma módosítja az integráció hatókörét
Egy teljes képernyős időjárás-jelenet viszonylag egyszerű, mert egyetlen forrás birtokolja a legtöbb változó tartalmat. Egy összetett megjelenítés azonban másképpen működhet: az idő helyi idő szerint fut, az időjárás külső szolgáltatótól érkezik, a várakozási sor-információk belső platformról származnak, és az ütemezett média foglalja el a maradék területet.
Ezért a függetlenül vezérelt régiók számát fel kell tüntetni az ajánlatkérési dokumentumban (RFQ). Ezután minden régió kapcsolódhat saját forrásához, frissítési viselkedéséhez, biztonsági visszatérési állapotához és vizuális prioritásához.
A kérdőívet nem kell szoftverspecifikációval kiegészíteni. Ezeket a döntéseket kell meghozni.
Tesztelje a kényelmetlen adatállapotokat még a képernyő élesbe helyezése előtt
A tökéletes mintaadatok bizonyítják, hogy az elrendezés megjeleníthető. Nem bizonyítják, hogy az információs rendszer biztonságosan tud meghibásodni.
Az integrációs tesztelés akkor válik értékesebbé, ha szándékosan megtöri a normál forgatókönyv mögött rejlő feltételezéseket. Egy kötelező mező eltűnhet. Egy állapotérték váratlan lehet. Az API elérhető maradhat, miközben az időbélyege nem változik tovább. Az adatforrás hosszabb ideig is hiányozhat, így a gyorsítótárazott információk elavulttá válhatnak.
A hosszú, de érvényes szöveg is része a tesztelésnek. Egy több karaktert tartalmazó cél, egy nagyobb ár vagy egy hosszabb állapotüzenet olyan vizuális problémákat tárhat fel, amelyeket a rövid fejlesztési értékek soha nem mutatnak. Ezek a tesztek egyszerűek, mégis gyakran megelőzik a láthatóbb hibákat, mint egy további normál adatokról készült képernyőkép-kör.
GYIK
Mi a valódi különbség egy élő adatokat megjelenítő LED-kijelző és egy szokásos ütemezett lejátszás között?
A beütemezett lejátszás általában az idő alapján választja ki az előkészített médiafájlokat. Az élő adatok tartalma más helyen létrehozott értékektől függ, ezért a megjelenítési munkafolyamatnak el kell döntenie, hogy ezek az értékek érvényesek és naprakészek-e. A fő különbség nem a vizuális animáció, hanem a külső információs állapotra való függés.
Mi legyen az API, a köztes szoftver, a lejátszó és az LED-vezérlő rendszer egyes elemeinek feladata?
Az adatforrás vagy az API szolgáltassa a hiteles információt. A köztes szoftver érvényességet ellenőrizhet, normalizálhat, gyorsítótárazhat és megítélheti az adatok frissességét. A lejátszó a fogadott értékeket vizuális elrendezéssé alakítja. Az LED-vezérlési útvonal ezután a kész vizuális kimenetet továbbítja a megjelenítő hardver felé. Egyes platformok több funkciót is egyesítenek, így a végső felelősségi határok meghatározásához még projekt-specifikus megerősítésre van szükség.
Mikor kell megerősíteni a frissítési gyakoriságot az időjárás-, sorbanállási-, ár- vagy közlekedési adatforrások esetében?
A döntést az integrációs körzet és az elfogadási tesztelés véglegesítése előtt kell meghozni. A forrásfrissítési viselkedést és a maximálisan elfogadható adatkorhatárt külön kell megbeszélni, mivel ezek eltérő problémákat oldanak meg. Ugyanazon a képernyőn található különböző régiókhoz más frissítési szabályzatok is szükségesek lehetnek.
Mi történjen akkor, ha a külső adatforrás leállítja a frissítéseket?
Az utolsó elfogadott rekord csak addig maradhat érvényben, amíg az elfogadott frissességi időszakon belül van. Ezt követően az érintett régió átkapcsolódhat semleges helyettesítő tartalomra. A többi egészséges régió továbbra is normál módon működhet. Amikor újra érkezik friss adat, azt a normál érvényesítésnek kell alávetni, mielőtt a valós idejű jelenet újraindulna.
Milyen információk a legfontosabbak az árajánlatkérési szakaszban?
A legerősebb indítási rövid leírás minden forrást, az ismert interfész módszert, a szükséges mezőket, a várt frissítési viselkedést, az elfogadható adatkorhatárt, a dinamikus régiók számát, a tartalék megoldásra vonatkozó követelményt és a rendelkezésre álló minta-adatcsomagot azonosítja. A hálózati hely és a tesztelési hozzáférés állapota szintén segíthet meghatározni az integrációs határt a részletes szoftverfejlesztés megkezdése előtt.
A legjobb élőadat-megjelenítő képernyő a üzleti logikát felső szinten tartja, és a megjelenítést átláthatóvá teszi.
Egy üzenetsor-platformnak továbbra is az üzenetsor állapotát kell döntenie. Egy árképzési platformnak továbbra is az árakért kell felelnie. Egy szállítási alkalmazásnak továbbra is a szállítási információkért kell felelnie. A megjelenítés nem válik megbízhatóbbá azzal, ha ezeket az üzleti szabályokat minden lejátszóba másolják.
Ehelyett az integráció kizárólag a megjelenítéshez szükséges információkat vonhatja ki, eldöntheti, hogy egyes rekordok továbbra is megfelelőek-e a megjelenítésre, és egy tiszta megjelenítési modellt továbbíthat lefelé a folyamatban. Ez a szétválasztás egyúttal egyszerűbbé teszi a későbbi módosításokat is, mivel a képernyő elrendezésének nem kell értenie az upstream rendszer minden részletét.
Az árajánlat elkészítése előtt három döntés biztosítja a legtisztább kiindulási alapot:
- Térképezze le a valós idejű régiókat. Jegyezze fel, hogy melyik forrás és mely mezők vezérelnek mindegyik látható területet.
- Határozza meg az adatok életkorát és frissítési sebességét. Egy sikeres kapcsolat nem bizonyítja, hogy a megjelenített információk továbbra is naprakészek.
- A valós idejű adatfolyam csatlakoztatása előtt tervezze meg a tartalék megoldást. A gyorsítótárazási időtartam, a elavult állapot, a semleges tartalom és a helyreállítás nem szabad, hogy üzembe helyezés után improvizált megoldás legyen.
Készítse el az adatforrás-összefoglalót az integrációs átvizsgálás előtt.
Nyújtsa be az adatforrás típusát, az elérhető API-t vagy interfészdokumentációt, a szükséges mezőket, az elvárt frissítési gyakoriságot, az elfogadható adatéletkort és a függetlenül vezérelhető képernyőterületek számát.
Amennyiben rendelkezésre áll, adjon hozzá egy fertőtlenített mintaterhelést, régió-hozzárendelést, hálózati helyet, gyorsítótár-követelményt, tartalék forgatókönyvet és helyreállítási szabályt. Ezek a részletek lehetővé teszik egy egyedi LED kijelző panel információs rendszer végpontjaként történő átvizsgálását, nem pedig a projektet általános API-kapcsolat kéréseként kezelik.
Adatintegrációs követelmények benyújtása
