En ändring med två parter
Det mesta man ändrar i ett system ändrar man ensam. Man rullar ut, man ser att det fungerar, och går det fel rullar man tillbaka.
En formatändring är inte sådan. Den har två parter, och den ena av dem är inte din. Avsändaren bestämmer när fältet får ett nytt namn, en ny struktur eller en ny upplösning. Mottagaren måste förstå det från samma ögonblick. Det finns inget mellanrum där båda delarna är sanna, och det finns ingen återställning som fungerar på båda sidor samtidigt.
I en kedja med en tidsfrist är detta värre än det låter. Felet upptäcks inte när ändringen sker, utan nästa morgon, när något skulle ha levererats.
Varför "alla byter samtidigt" är en dyr plan
Det vanliga sättet är ett datum. Alla byter natten till måndag, och alla hoppas.
Problemet är inte ambitionen, utan vad som måste stämma för att planen ska hålla. Mottagarsystemet måste vara färdigtestat mot ett format som ännu inte har levererat riktiga data. Testdata liknar sällan tillräckligt: det är de sällsynta värdena som fallerar, inte de vanliga. Nollvärdena, de negativa, de som saknas, de som kommer i fel ordning.
Och det som avgör om det gick bra visar sig först i ett fönster där ingen har tid att undersöka något.
Två strömmar, samma data, två versioner
Alternativet är att sluta behandla formatändringen som en händelse och börja behandla den som en överlappning.
Samma data kan levereras i två versioner samtidigt, på var sin ström:
ström A gammalt format → produktionssystemet, oförändrat
ström B nytt format → testsystemet, som byggs färdigt under tiden
Produktionen fortsätter på det den alltid har läst. Testmiljön får de nya data, äkta och färska, inte konstruerade. När det nya systemet har läst en vecka av verklighet utan att fallera är omläggningen ett byte av vilken ström produktionen prenumererar på, och ingenting annat.
Skillnaden är vad som måste vara sant på förhand. I en datumbaserad omläggning måste du tro att det fungerar. I en överlappande behöver du bara titta efter.
Samma mekanism täcker det motsatta fallet: att avsändaren ändrar något innan du är redo. Då levereras det gamla formatet vidare till dig medan du hinner ikapp, i stället för att ändringen tvingar fram ett brådskande arbete hos dig för att den skedde hos någon annan.
Nycklarna hör hemma i meddelandet
Den andra halvan av samma problem handlar inte om format, utan om vad som möter dig efteråt.
En mätpunkt har en identifierare i navet. Ditt system har som regel en annan, en intern nyckel som betyder något hos dig. När data kommer in måste de två kopplas, och den kopplingen görs traditionellt på två ställen: parsning av det som kom, och en uppslagning för att ta reda på vem det tillhör.
Bådadera kan flyttas. Läggs kundens egna nycklar in på mätpunktsnivå hos avsändaren följer de med i meddelandet, och mottagarsystemet kan importera direkt. Ingen parsning, ingen uppslagstabell som måste hållas i synk, och inget jobb som fallerar tyst den dag en mätpunkt saknas i tabellen.
Det är värt att notera vad detta faktiskt tar bort: inte arbetstid, utan ett helt lager där fel kan uppstå.
Det man förlorar, och det som måste ersätta det
En äldre meddelandeplattform gav något reellt utöver själva transporten. Ett ställe att leta på när ett meddelande försvann, en logg som var lätt att läsa, och ett gränssnitt en superanvändare kunde hitta i utan hjälp.
Det är inget argument mot att byta. Det är en kravspecifikation för det som ska komma i stället.
Ett modernt alternativ ska kunna svara på samma sak, och gärna mer: hur många meddelanden kom igenom i går, vilka stannade, hur lång tid tog de, och hur såg flödet ut förra veckan jämfört med denna. Kan en driftsansvarig svara på det själv, utan att be någon om en rapport, är förlusten täckt. Kan hen inte det är bytet ett steg bakåt hur modernt resten än är.
Tre frågor att ställa före nästa formatändring
Kan jag få samma data i två versioner samtidigt? Om inte är varje omläggning en datumbaserad omläggning, vad den än kallas.
Hur länge kan de två leva sida vid sida? En överlappning som varar en dag är ett test. En överlappning som kan vara tills du är klar är en plan.
Vem äger kopplingen mellan deras identifierare och min? Ligger den i meddelandet följer den med. Ligger den i en tabell hos mig är den min att underhålla, och min att glömma.
Ny funktionalitet i SAMTYGD
Skälet till att denna artikel kommer nu är att den sista biten är på plats hos oss. SAMTYGDTvimennings plattform för Elhub-integration - hanterar alla meddelandetyper och processer mot Elhub. skickar mätvärdena vidare i samma stund de hämtas från ElhubNationellt nav för mätvärden och marknadsprocesser på den norska elmarknaden., i stället för att ditt system ska behöva fråga om det kommit något nytt. Det är ny funktionalitet, och den är i drift.
Med den följer de två mekanismer denna artikel handlar om. Samma data kan levereras på två strömmar i två versioner samtidigt, så att en formatändring kan köras i test på äkta data innan produktionen flyttas. Och kundens egna nycklar läggs in per mätpunkt och följer med i meddelandet, så att mottagaren slipper både parsning och uppslagning.
Statistik över dataflödet ligger i gränssnittet: vad som kom igenom, vad som stannade, och hur förra veckan såg ut mot denna.
En precisering hör hit, eftersom den är värd att känna till innan någon planerar kring den: nycklarna sätts när mätpunkten läggs upp, och ett APIApplikationsprogrammeringsgränssnitt - standardiserat gränssnitt som låter två system kommunicera med varandra. för att ändra dem i efterhand är under uppbyggnad.