Toveissynkronisering trenger tydelige skriveregler
Hvis CRM og ERP kan skrive, trenger hvert felles felt en konfliktregel. Sist mottatte melding er ikke automatisk den nyeste forretningsbeslutningen.
En kobling kan overføre data i begge retninger. Det betyr ikke at hvert felt bør kunne overskrives fritt på begge sider. Felles felt trenger en regel som kobler redigeringsrett, basisversjon og konflikthåndtering. Ellers kan en teknisk ny melding gjeninnføre en verdi som er utdatert for virksomheten.
En sen melding kan bygge på eldre data
Et fiktivt programvareselskap synkroniserer CRM og ERP. ERP bekrefter fakturaadressen mens CRM vedlikeholder prosjektkontakten. Dette oppdiktede forløpet viser hva en generell oppdatering av hele posten kan føre til:
Tid | Handling | Dataversjon |
|---|---|---|
| CRM leser kundeposten. |
|
| ERP-teamet bekrefter en ny fakturaadresse. |
|
| CRM sender en endret prosjektkontakt tilbake sammen med den gamle adressen. | Meldingen inneholder fortsatt |
Meldingen kommer senere, men adressen kommer fra en eldre versjon. Hvis integrasjonen overtok hele posten uten kontroll, kunne den bekreftede endringen gå tapt. Her viser v7 og v8 til samme ERP-post; uavhengige lokale versjonstellere fra ulike systemer kan ikke uten videre sammenlignes.
Gjenkjenn basisversjonen og avgjør konflikten
Microsoft beskriver optimistisk samtidighetskontroll for Dataverse: et program kan oppdage om serverposten er endret mellom lesing og skriving. Hvilken kontroll som finnes, og hvordan den aktiveres, avhenger av produktet og grensesnittet.
En oppdaget forskjell avgjør ikke hvilken adresse som er riktig for virksomheten. I eksemplet skal den gamle adressen vente på avklaring eller behandles som en ikke tillatt tilbakeskriving. Bare å sende den avviste gamle verdien igjen med en ny versjonskode ville omgå versjonskontrollen uten å løse den virksomhetsmessige forskjellen. En enkelt versjonskontroll gjør heller ikke alle trinn mellom flere systemer atomære.
Når begge sider kan skrive
Hvis begge team faktisk må redigere de samme opplysningene, kan en toveisløsning passe. Tillatte felt, endringer og konfliktavgjørelser må da være tydelige. Microsofts dual-write-dokumentasjon viser for eksempel ulike retninger per kolonnekobling; én felles innstilling for alt er ikke et virksomhetskrav.
Det kan også være nok å overføre ulike felt i ulike retninger. I eksemplet skal den nye prosjektkontakten tas imot etter sin regel, mens den gamle fakturaadressen ikke skrives tilbake uten kontroll. Begge verdier tilhører samme kunde, men krever ulike skriveavgjørelser.
Kilder
Les videre
Alle artikler
API-er og integrasjon med ASES
ERP, CRM og nettbutikk ryddig koblet sammen