En endring med to parter
Det meste man endrer i et system, endrer man alene. Man ruller ut, man ser at det virker, og går det galt, ruller man tilbake.
En formatendring er ikke slik. Den har to parter, og den ene av dem er ikke din. Avsenderen bestemmer når feltet får et nytt navn, en ny struktur eller en ny oppløsning. Mottakeren må forstå det fra samme øyeblikk. Det finnes ikke noe mellomrom der begge deler er sanne, og det finnes ingen tilbakerulling som virker på begge sider samtidig.
I en kjede med en frist er dette verre enn det høres ut. Feilen oppdages ikke når endringen skjer, men neste morgen, når noe skulle vært levert.
Hvorfor «alle bytter samtidig» er en dyr plan
Den vanlige måten å gjøre det på er en dato. Alle bytter natt til mandag, og alle håper.
Problemet er ikke ambisjonen, det er hva som må stemme for at planen skal holde. Mottakersystemet må være ferdig testet mot et format som ennå ikke har levert ekte data. Testdata ligner sjelden nok: det er de sjeldne verdiene som feiler, ikke de vanlige. Nullverdiene, de negative, de som mangler, de som kommer i feil rekkefølge.
Og det som avgjør om det gikk bra, viser seg først i et vindu der ingen har tid til å undersøke noe.
To strømmer, samme data, to versjoner
Alternativet er å slutte å behandle formatendringen som en hendelse, og begynne å behandle den som en overlapping.
Samme data kan leveres i to versjoner samtidig, på hver sin strøm:
strøm A gammelt format → produksjonssystemet, uendret
strøm B nytt format → testsystemet, som bygges ferdig imens
Produksjonen kjører videre på det den alltid har lest. Testmiljøet får de nye dataene, ekte og ferske, ikke konstruerte. Når det nye systemet har lest en uke med virkelighet uten å feile, er omleggingen et bytte av hvilken strøm produksjonen abonnerer på, og ingenting annet.
Forskjellen er hva som må være sant på forhånd. I en datobasert omlegging må du tro at det virker. I en overlappende må du bare se etter.
Den samme mekanismen dekker det motsatte tilfellet: at avsenderen endrer noe før du er klar. Da leveres det gamle formatet videre til deg mens du henter deg inn, i stedet for at endringen tvinger fram et hastearbeid hos deg fordi den skjedde hos noen andre.
Nøklene hører hjemme i meldingen
Den andre halvparten av samme problem handler ikke om format, men om hva som møter deg etterpå.
Et målepunktGrunnenheten i Elhub - det unike punktet i strømnettet der energi måles og avregnes, identifisert med et 18-sifret GSRN-nummer. har en identifikator i navet. Systemet ditt har som regel en annen, en intern nøkkel som betyr noe hos deg. Når data kommer inn, må de to kobles, og den koblingen gjøres tradisjonelt to steder: parsing av det som kom, og et oppslag for å finne ut hvem det tilhører.
Begge deler kan flyttes. Legges kundens egne nøkler inn på målepunktnivå hos avsenderen, følger de med i meldingen, og mottakersystemet kan importere direkte. Ingen parsing, ingen oppslagstabell som må holdes i synk, og ingen jobb som feiler stille den dagen et målepunktGrunnenheten i Elhub - det unike punktet i strømnettet der energi måles og avregnes, identifisert med et 18-sifret GSRN-nummer. mangler i tabellen.
Det er verdt å merke seg hva dette faktisk fjerner: ikke arbeidstid, men et helt lag der feil kan oppstå.
Det man mister, og det som må erstatte det
En eldre meldingsplattform ga noe reelt utover selve transporten. Ett sted å lete når en melding forsvant, en logg som var lett å lese, og et grensesnitt en superbruker kunne finne fram i uten hjelp.
Det er ikke et argument mot å bytte. Det er en kravspesifikasjon for det som skal komme i stedet.
Et moderne alternativ skal kunne svare på det samme, og gjerne mer: hvor mange meldinger kom gjennom i går, hvilke stoppet, hvor lang tid tok de, og hvordan så flyten ut i forrige uke sammenlignet med denne. Kan en driftsansvarlig svare på det selv, uten å be noen om en rapport, er tapet dekket. Kan hen ikke det, er byttet et tilbakeskritt uansett hvor moderne resten er.
Tre spørsmål å stille før neste formatendring
Kan jeg få samme data i to versjoner samtidig? Hvis ikke er enhver omlegging en datobasert omlegging, uansett hva den kalles.
Hvor lenge kan de to leve side om side? Overlapping som varer en dag er en test. Overlapping som kan vare til du er ferdig, er en plan.
Hvem eier koblingen mellom deres identifikator og min? Ligger den i meldingen, følger den med. Ligger den i en tabell hos meg, er den min å vedlikeholde, og min å glemme.
Ny funksjonalitet i SAMTYGD
Grunnen til at denne artikkelen kommer nå, er at det siste stykket er på plass hos oss. SAMTYGDTvimennings plattform for Elhub-integrasjon - håndterer alle meldingstyper og prosesser mot Elhub. sender måleverdiene videre i det de er hentet fra ElhubNasjonalt nav for måleverdier og markedsprosesser i norsk kraftmarked., i stedet for at systemet ditt må spørre om det har kommet noe nytt. Det er ny funksjonalitet, og den er i drift.
Med den følger de to mekanismene denne artikkelen handler om. Samme data kan leveres på to strømmer i to versjoner samtidig, så en formatendring kan kjøres i test på ekte data før produksjonen flyttes. Og kundens egne nøkler legges inn per målepunktGrunnenheten i Elhub - det unike punktet i strømnettet der energi måles og avregnes, identifisert med et 18-sifret GSRN-nummer. og følger med i meldingen, så mottakeren slipper både parsing og oppslag.
Statistikk over dataflyten ligger i grensesnittet: hva som kom gjennom, hva som stoppet, og hvordan forrige uke så ut mot denne.
Én presisering hører med, fordi den er verdt å vite før noen planlegger rundt den: nøklene settes når målepunktet opprettes, og et APIApplication Programming Interface - grensesnitt som lar systemer kommunisere med hverandre. for å endre dem i etterkant er under bygging.