Hvor aktuelle skal integrationsdata være?

Beskriv beslutningen bag opdateringen

»Alt i realtid« afklarer ikke, hvilken forsinkelse der er acceptabel for hvilken opgave. En lagerbeholdning kan påvirke et salgsløfte. En redaktionel beskrivelse kan vente til et aftalt tidspunkt. Den nødvendige aktualitet følger af anvendelsen; først derefter kan overførselsformen vælges meningsfuldt.

I asynkrone forløb kan systemer midlertidigt vise forskellige tilstande. Microsoft beskriver denne følge af hændelsesdrevet arkitektur. En hurtigt udløst hændelse fjerner hverken køer eller behandlingstid i målet.

Eksempel: to felter, forskellige konsekvenser

Tabellen er en opdigtet planlægning, ikke en måling eller en generel anbefaling om opdateringsintervaller.

Selv hyppige lageropdateringer forhindrer ikke i sig selv samtidige salg af det samme sidste styk. Ordreprocessen kræver en pålidelig tilgængelighedskontrol og reservationsregel. Omvendt kan en beskrivelse indeholde sikkerhedsrelevante eller kontraktmæssigt vigtige oplysninger. Forsinkelsen kan da ikke på forhånd regnes som uvigtig.

Aftal mål, målepunkt og alternativ

Definér for hver datagruppe, hvilken bekræftet kildetilstand der starter tiden, og hvornår ændringen faktisk skal kunne bruges i målet. Vellykket afsendelse til en grænseflade er et tidligere målepunkt. Aftal også, hvem der håndterer overskridelser, og hvad der vises ved ukendt aktualitet, eller hvad der kontrolleres før et løfte.

Microsoft præsenterer flere integrationsmønstre, herunder batchbehandling. En planlagt samlet kørsel kan passe til acceptable ventetider. Hændelser kan hjælpe ved snævre tidskrav, men medfører egne driftsopgaver. Vurdér valget med forsinkede og afviste ændringer, før du lover en bestemt aktualitet.

Kilder

• Microsoft: Event-driven architecture

• Microsoft: Data integration patterns