En ændring med to parter
Det meste, man ændrer i et system, ændrer man alene. Man ruller ud, man ser, at det virker, og går det galt, ruller man tilbage.
En formatændring er ikke sådan. Den har to parter, og den ene af dem er ikke din. Afsenderen bestemmer, hvornår feltet får et nyt navn, en ny struktur eller en ny opløsning. Modtageren skal forstå det fra samme øjeblik. Der findes ikke noget mellemrum, hvor begge dele er sande, og der findes ingen tilbagerulning, der virker på begge sider samtidig.
I en kæde med en frist er dette værre, end det lyder. Fejlen opdages ikke, når ændringen sker, men næste morgen, når noget skulle have været leveret.
Hvorfor "alle skifter samtidig" er en dyr plan
Den sædvanlige måde er en dato. Alle skifter natten til mandag, og alle håber.
Problemet er ikke ambitionen, men hvad der skal passe, for at planen holder. Modtagersystemet skal være færdigtestet mod et format, der endnu ikke har leveret ægte data. Testdata ligner sjældent nok: det er de sjældne værdier, der fejler, ikke de almindelige. Nulværdierne, de negative, dem der mangler, dem der kommer i forkert rækkefølge.
Og det, der afgør, om det gik godt, viser sig først i et vindue, hvor ingen har tid til at undersøge noget.
To strømme, samme data, to versioner
Alternativet er at holde op med at behandle formatændringen som en hændelse og begynde at behandle den som en overlapning.
Samme data kan leveres i to versioner samtidig, på hver sin strøm:
strøm A gammelt format → produktionssystemet, uændret
strøm B nyt format → testsystemet, der bygges færdigt imens
Produktionen kører videre på det, den altid har læst. Testmiljøet får de nye data, ægte og friske, ikke konstruerede. Når det nye system har læst en uge af virkelighed uden at fejle, er omlægningen et skift af, hvilken strøm produktionen abonnerer på, og intet andet.
Forskellen er, hvad der skal være sandt på forhånd. I en datobaseret omlægning skal du tro, at det virker. I en overlappende skal du bare se efter.
Den samme mekanisme dækker det modsatte tilfælde: at afsenderen ændrer noget, før du er klar. Så leveres det gamle format videre til dig, mens du henter dig ind, i stedet for at ændringen tvinger hastearbejde igennem hos dig, fordi den skete hos nogen andre.
Nøglerne hører hjemme i meddelelsen
Den anden halvdel af samme problem handler ikke om format, men om hvad der møder dig bagefter.
Et målepunktGrundenheden i Elhub - det unikke punkt i elnettet, hvor energi måles og afregnes, identificeret med et 18-cifret GSRN-nummer. har en identifikator i navet. Dit system har som regel en anden, en intern nøgle, der betyder noget hos dig. Når data kommer ind, skal de to kobles, og den kobling laves traditionelt to steder: parsing af det, der kom, og et opslag for at finde ud af, hvem det tilhører.
Begge dele kan flyttes. Lægges kundens egne nøgler ind på målepunktniveau hos afsenderen, følger de med i meddelelsen, og modtagersystemet kan importere direkte. Ingen parsing, ingen opslagstabel, der skal holdes i sync, og intet job, der fejler stille den dag, et målepunktGrundenheden i Elhub - det unikke punkt i elnettet, hvor energi måles og afregnes, identificeret med et 18-cifret GSRN-nummer. mangler i tabellen.
Det er værd at bemærke, hvad dette faktisk fjerner: ikke arbejdstid, men et helt lag, hvor fejl kan opstå.
Det, man mister, og det, der skal erstatte det
En ældre meddelelsesplatform gav noget reelt ud over selve transporten. Ét sted at lede, når en meddelelse forsvandt, en log, der var let at læse, og en grænseflade, en superbruger kunne finde rundt i uden hjælp.
Det er ikke et argument mod at skifte. Det er en kravspecifikation for det, der skal komme i stedet.
Et moderne alternativ skal kunne svare på det samme, og gerne mere: hvor mange meddelelser kom igennem i går, hvilke stoppede, hvor lang tid tog de, og hvordan så flowet ud i sidste uge sammenlignet med denne. Kan en driftsansvarlig svare på det selv, uden at bede nogen om en rapport, er tabet dækket. Kan vedkommende ikke det, er skiftet et tilbageskridt, uanset hvor moderne resten er.
Tre spørgsmål at stille før næste formatændring
Kan jeg få samme data i to versioner samtidig? Hvis ikke, er enhver omlægning en datobaseret omlægning, uanset hvad den kaldes.
Hvor længe kan de to leve side om side? En overlapning, der varer en dag, er en test. En overlapning, der kan vare, til du er færdig, er en plan.
Hvem ejer koblingen mellem deres identifikator og min? Ligger den i meddelelsen, følger den med. Ligger den i en tabel hos mig, er den min at vedligeholde, og min at glemme.
Ny funktionalitet i SAMTYGD
Grunden til, at denne artikel kommer nu, er, at det sidste stykke er på plads hos os. SAMTYGDTvimennings platform for Elhub-integration - håndterer alle meddelelsestyper og processer mod Elhub. sender måleværdierne videre, i samme øjeblik de hentes fra ElhubNationalt nav for måledata og markedsprocesser på det norske elmarked., i stedet for at dit system skal spørge, om der er kommet noget nyt. Det er ny funktionalitet, og den er i drift.
Med den følger de to mekanismer, denne artikel handler om. De samme data kan leveres på to strømme i to versioner samtidig, så en formatændring kan køres i test på ægte data, før produktionen flyttes. Og kundens egne nøgler lægges ind per målepunktGrundenheden i Elhub - det unikke punkt i elnettet, hvor energi måles og afregnes, identificeret med et 18-cifret GSRN-nummer. og følger med i meddelelsen, så modtageren slipper for både parsing og opslag.
Statistik over dataflowet ligger i grænsefladen: hvad der kom igennem, hvad der stoppede, og hvordan sidste uge så ud mod denne.
Én præcisering hører med, fordi den er værd at kende, før nogen planlægger omkring den: nøglerne sættes, når målepunktet oprettes, og et APIApplikationsprogrammeringsgrænseflade - standardiseret grænseflade der giver to systemer mulighed for at kommunikere med hinanden. til at ændre dem bagefter er under opbygning.