Hvor oppdaterte må integrasjonsdata være?

Beskriv beslutningen bak oppdateringen

«Alt i sanntid» avklarer ikke hvilken forsinkelse som er akseptabel for hvilken oppgave. En lagerbeholdning kan påvirke et salgsløfte. En redaksjonell beskrivelse kan vente til et avtalt tidspunkt. Behovet for oppdaterte data følger av bruken; først deretter kan overføringsformen velges på et fornuftig grunnlag.

I asynkrone flyter kan systemer midlertidig vise ulike tilstander. Microsoft beskriver denne følgen av hendelsesdrevet arkitektur. En raskt utløst hendelse fjerner verken køer eller behandlingstid i målet.

Eksempel: to felt, ulike følger

Tabellen er en oppdiktet planlegging, ikke en måling eller en generell anbefaling om oppdateringsintervaller.

Selv hyppige lageroppdateringer hindrer ikke i seg selv samtidige salg av det samme siste eksemplaret. Bestillingsprosessen trenger en pålitelig tilgjengelighetskontroll og reservasjonsregel. Omvendt kan en beskrivelse inneholde sikkerhetsrelaterte eller avtalemessig viktige opplysninger. Forsinkelsen kan da ikke på forhånd regnes som uviktig.

Avtal mål, målepunkt og alternativ

Definer for hver datagruppe hvilken bekreftet kildetilstand som starter tiden, og når endringen faktisk må kunne brukes i målet. Vellykket sending til et grensesnitt er et tidligere målepunkt. Avklar også hvem som håndterer overskridelser, og hva som vises ved ukjent aktualitet, eller hva som kontrolleres før et løfte.

Microsoft presenterer flere integrasjonsmønstre, blant annet batchbehandling. En planlagt samlet kjøring kan passe til akseptable ventetider. Hendelser kan hjelpe ved stramme tidskrav, men fører med seg egne driftsoppgaver. Vurder valget med forsinkede og avviste endringer før du lover en bestemt aktualitet.

Kilder

• Microsoft: Event-driven architecture

• Microsoft: Data integration patterns