Uklare kundetilknytninger kræver en fast vej til afklaring
At sende igen afklarer ikke en usikker kundetilknytning. Integrationen har brug for en sporbar vej fra afklaring til et bekræftet resultat i målet.
Kan en integration ikke pålideligt tilknytte kunden til en handling, skal sagen stadig kunne behandles. Det kræver en ansvarlig rolle, de nødvendige oplysninger og en kontrolleret vej tilbage til behandlingen. En fejllog og beskeden om at sende igen senere løser ikke en uafklaret forretningsmæssig identitet.
Microsoft beskriver også manuelle indgreb med en sporbar fejlårsag i forløb med flere trin. Vores eksempel venter, før der skrives i målet.
En åben sag skal have et synligt udfald
I det helt fiktive eksempel skal projektforespørgslen R-28 oprette en projektkladde i ERP. Der mangler en bekræftet tilknytning for CRM-kunden C-508. Den ansvarlige person fastslår, at den eksisterende ERP-kundekonto K-410 skal bruges. Tabellen beskriver det ønskede forløb.
Tilstand | Betydning i eksemplet | Hvad der mangler |
|---|---|---|
| Kundetilknytningen er uafklaret; ingen kladde oprettes i målet. | Kontrollér identiteten, og bekræft tilknytningen. |
| Der findes en fagligt kontrolleret tilknytning. | Kontrollér aktuelle rettigheder og kundekontoens anvendelighed før skrivning. |
| Overførslen behandles. | Bekræftelse af resultatet i målet. |
| Den bekræftede projektkladde | Den aftalte overførsel er afsluttet. |
Et navn på en liste må ikke alene afgøre valget af kunde. Behandlingen skal holde anledning, kontrolleret kildeversion, tidligere og valgt tilknytning samt begrundelsen samlet. Kun den berettigede rolle får adgang til disse sager.
Rettelsen skal tage højde for den aktuelle tilstand
Data eller rettigheder kan ændre sig mellem visning og bekræftelse. Kontrollér før fortsættelsen den aktuelle tilladelse, og om den valgte kundekonto stadig må bruges. OWASP kræver rettighedskontrol ved hver forespørgsel. En allerede åben redigeringsside erstatter ikke kontrollen.
To samtidige behandlere må heller ikke gemme modstridende beslutninger ubemærket. Ændrede forudsætninger eller en allerede løst sag skal opdages ved bekræftelsen. Passer forudsætningerne ikke længere, forbliver handlingen åben til ny afklaring.
En gentagelse må ikke oprette endnu en projektkladde
Alle forsøg forbliver knyttet til samme projektforespørgsel. Det kræver også beskyttelse i målet: for eksempel idempotent oprettelse, som ikke danner en ekstra kladde ved en identisk gentagelse, eller en eksternt angivet reference, hvis entydighed håndhæves i målet, med pålideligt opslag af udfaldet. Sagsidentifikatoren alene forhindrer ikke dobbeltoprettelse.
Mangler svaret efter skrivningen, afklares først udfaldet af den eksisterende handling. AWS understreger, at en timeout ikke udelukker allerede indtrufne bivirkninger. Indtil udfaldet er kendt, må det ikke behandles som en sikker fejl og erstattes af en vilkårlig ny forespørgsel.
Begræns den manuelle vej til de nødvendige sager
En entydig, kontrolleret tilknytning kan behandles automatisk. Ikke alle poster kræver menneskelig godkendelse. For resten skal ansvar, aftalt reaktionstid og eskalering være synlige; en voksende liste uden ejer løser ikke problemet.
Vores eksempel stopper før projektoprettelsen. Er noget allerede oprettet under den forkerte kunde, kræver det en særskilt forretningsmæssig rettelse, som tager højde for de skabte relationer.
Kilder
Læs videre
Alle artikler
Snitflader & integration med ASES
ERP, CRM og webshop forbundet ordentligt