BRE-migrering: vad som faktiskt går att flytta till Azure

Under flera år var standardsvaret att Business Rules Engine inte har någon motsvarighet i Azure, och att varje policy därför måste skrivas om till kod. Det svaret är föråldrat. Azure Logic Apps Rules Engine ingår numera i Logic Apps Standard och innehåller BizTalks egen BRE-runtime, vilket betyder att befintliga policies kan återanvändas i stället för att tolkas om av en utvecklare.

Det är goda nyheter, och det är också där de flesta kalkyler går fel, fast åt andra hållet. Att runtime finns kvar betyder inte att hela er regelmassa följer med. Skillnaden mellan de policies som lyfter rakt över och de som inte gör det avgör er tidsuppskattning, och den skillnaden går att avgöra idag, innan projektet startar.

Det som följer med

Rules Engine bygger på samma inferensmotor som ni redan kör: Rete-algoritmen, forward chaining, agenda och prioritet fungerar som förut. Ni behåller alltså semantiken i era regler, inklusive kedjningsbeteendet, som är den del som är svårast att återskapa manuellt och lättast att få fel om någon skriver om reglerna till if-satser.

• XML-fakta och .NET Framework-fakta stöds.
• Vokabulär finns kvar som begrepp och redigeras i Microsoft Rules Composer.
• Prioritet och forward chaining beter sig som i BizTalk.

Det som inte följer med — och som styr er estimering

Databasfakta stöds inte. Policies som läser DB facts måste tas bort eller skrivas om till en annan faktatyp innan export. Det här är den enskilt viktigaste raden på hela sidan, för det är exakt de policies som brukar vara verksamhetskritiska: prislistor, partnerspecifika villkor och gränsvärden som någon en gång valde att läsa direkt ur en tabell i stället för att skicka in som fakta.

Konsekvensen är att er BRE-migrering inte har en kostnad utan två, och att fördelningen mellan dem är känd redan innan ni börjar. Räkna dem var för sig:

• Policies utan databasfakta: export och verifiering. Mekaniskt arbete.
• Policies med databasfakta: omdesign av hur data når regeln. Kräver någon som förstår varför regeln ser ut som den gör, inte bara vad den gör.

Räkna kategorierna i BizTalkRuleEngineDb innan ni sätter en siffra. En miljö där tio procent av policyerna använder databasfakta och en där hälften gör det är två helt olika projekt, trots att de har samma antal policies.

Så exporterar ni

Regler exporteras från BizTalk med Business Rules Engine Deployment Wizard: välj Export Policy/Vocabulary to file from database och peka ut BizTalkRuleEngineDb. Exporten görs per policy, och det finns ingen massexport, så planera för att det är en lista att beta av, inte ett kommando att köra.

På Azure-sidan skapas projektet i Visual Studio Code som ett Logic apps with rules engine project, och regler redigeras i Microsoft Rules Composer, som installeras separat.

Vad vi skulle välja

Lyft de policies som kan lyftas, och gör det tidigt. Poängen är inte att spara timmar utan att bevisa att regelsemantiken överlever flytten medan ni fortfarande har BizTalk igång att jämföra mot. Kör samma fakta genom båda motorerna och jämför utfallet regel för regel. Det är den enda verifiering som betyder något, och den blir omöjlig att göra i efterhand.

Skriv inte om regler till C# bara för att de ser enkla ut. En regelmassa som flyttas till kod förlorar det som gjorde BRE värt besväret: att verksamheten kunde ändra ett gränsvärde utan att beställa en release. Har ni bestämt er för att lämna regelmotorn helt är det ett eget beslut med egen motivering, inte en bieffekt av en plattformsflytt.

För policies med databasfakta: flytta datat till fakta som skickas in, inte till en regel som hämtar själv. Det är ändå den designen ni vill ha på andra sidan.

En sak till, om prestanda

.NET-fakta utvärderas snabbare än XML-fakta, precis som i BizTalk. Och regler med många OR-operatorer expanderar analysnätet kraftigt. Har ni policies som varit långsamma i BizTalk av det skälet blir de inte snabbare av att byta värd. Migreringen är ett bra tillfälle att skriva om dem på disjunktiv normalform, men gör det som ett separat steg efter att flytten är verifierad, aldrig samtidigt.

Nästa steg

Ni behöver antalet policies och hur många av dem som rör databasfakta innan någon kan uttala sig om tid. Ett inventeringsskript som räknar BRE-policies och vokabulär tillsammans med resten av miljön finns som beta. Komplettera dess grundräkning med en granskning av policyernas faktatyper. Därefter visar kostnadssidan hur den siffran blir persondagar.