Hur aktuella måste integrationsdata vara?

Beskriv beslutet bakom uppdateringen

”Allt i realtid” lämnar öppet vilken fördröjning som är acceptabel för vilken uppgift. Ett lagersaldo kan påverka ett försäljningslöfte. En redaktionell beskrivning kan vänta till en avtalad tidpunkt. Aktualitetsbehovet följer av användningen; först därefter går det att välja överföringssätt på rimliga grunder.

I asynkrona flöden kan systemen tillfälligt visa olika tillstånd. Microsoft beskriver denna följd av händelsestyrd arkitektur. En snabbt utlöst händelse tar inte bort köer eller bearbetningstid i målet.

Exempel: två fält, olika följder

Tabellen är en påhittad planering, ingen mätning eller allmän rekommendation om uppdateringsintervall.

Inte ens täta lageruppdateringar förhindrar i sig att samma sista exemplar säljs samtidigt. Beställningsprocessen behöver en tillförlitlig tillgänglighetskontroll och reservationsregel. Omvänt kan en beskrivning innehålla säkerhetsrelaterade eller avtalsmässigt viktiga uppgifter. Fördröjningen får då inte på förhand betraktas som oviktig.

Avtala mål, mätpunkt och reservväg

Definiera för varje datagrupp vilket bekräftat källtillstånd som startar tiden och när ändringen faktiskt måste kunna användas i målet. En lyckad sändning till ett gränssnitt är en tidigare mätpunkt. Bestäm också vem som hanterar överskridanden och vad som visas när aktualiteten är okänd, eller vad som kontrolleras före ett löfte.

Microsoft presenterar flera integrationsmönster, bland annat batchbearbetning. En planerad samlad körning kan passa acceptabla väntetider. Händelser kan hjälpa vid snäva tidskrav, men innebär egna driftuppgifter. Bedöm valet med försenade och avvisade ändringar innan du lovar en viss aktualitet.

Källor

• Microsoft: Event-driven architecture

• Microsoft: Data integration patterns