Tovejssynkronisering kræver tydelige skriveregler
Hvis CRM og ERP må skrive, kræver hvert fælles felt en konfliktregel. Den senest modtagne besked er ikke automatisk den seneste forretningsbeslutning.
En kobling må overføre data i begge retninger. Det betyder ikke, at hvert felt bør kunne overskrives frit på begge sider. Fælles felter kræver en regel, der forbinder redigeringsret, basisversion og konflikthåndtering. Ellers kan en teknisk ny besked genindføre en forretningsmæssigt forældet værdi.
En sen besked kan bygge på ældre data
Et fiktivt softwarefirma synkroniserer CRM og ERP. ERP bekræfter faktureringsadressen, mens CRM vedligeholder projektkontakten. Dette opdigtede forløb viser, hvad en generel opdatering af hele posten kan medføre:
Tid | Handling | Dataversion |
|---|---|---|
| CRM læser kundeposten. |
|
| ERP-teamet bekræfter en ny faktureringsadresse. |
|
| CRM sender en ændret projektkontakt tilbage sammen med den gamle adresse. | Beskeden indeholder stadig |
Beskeden kommer senere, men adressen stammer fra en ældre version. Hvis integrationen overtog hele posten ukontrolleret, kunne den bekræftede ændring gå tabt. Her gælder v7 og v8 samme ERP-post; uafhængige lokale versionstællere fra forskellige systemer kan ikke uden videre sammenlignes.
Genkend basisversionen, og afgør konflikten
Microsoft beskriver optimistisk samtidighedskontrol for Dataverse: et program kan opdage, om serverposten er ændret mellem læsning og skrivning. Hvilken kontrol der findes, og hvordan den aktiveres, afhænger af produktet og grænsefladen.
En konstateret forskel afgør ikke, hvilken adresse der er forretningsmæssigt rigtig. I eksemplet skal den gamle adresse afvente afklaring eller behandles som en ikke tilladt tilbageskrivning. Blot at sende den afviste gamle værdi igen med en ny versionskode ville omgå versionskontrollen uden at løse den forretningsmæssige forskel. En enkelt versionskontrol gør heller ikke alle trin mellem flere systemer atomare.
Hvornår begge sider må skrive
Hvis begge teams faktisk skal redigere de samme oplysninger, kan en tovejsløsning passe. Tilladte felter, ændringer og konfliktbeslutninger skal så fastlægges udtrykkeligt. Microsofts dual-write-dokumentation viser for eksempel forskellige retninger pr. kolonnekobling; en fælles indstilling for alt er ikke et forretningskrav.
Det kan også være nok at overføre forskellige felter i forskellige retninger. I eksemplet skal den nye projektkontakt overtages efter sin regel, mens den gamle faktureringsadresse ikke skrives ukontrolleret tilbage. Begge værdier tilhører samme kunde, men kræver forskellige skrivebeslutninger.
Kilder
Læs videre
Alle artikler
Snitflader & integration med ASES
ERP, CRM og webshop forbundet ordentligt