Интеграции без дупли нарачки: што се случува кога барањето ќе се повтори?

Онлајн продавница испраќа нарачка до деловен систем. Системот ја зачувува, но врската се прекинува пред продавницата да добие одговор. Од гледна точка на испраќачот, исходот е непознат. Ако тој повторно го испрати истото барање, дали ќе добиеме втора нарачка?

Ова сценарио покажува зошто интеграцијата треба да се планира и за неизвесен исход. Успешното поврзување во демонстрација е почеток; секојдневната работа вклучува повторувања, доцнења и нецелосни податоци.

Дајте ѝ идентитет на операцијата

Идемпотентна обработка значи дека повторувањето на иста логичка операција го зачувува нејзиниот ефект, наместо повторно да го создава. Практичен пристап е испраќачот да приложи стабилен идентификатор, а примачот да го поврзе со исходот на обработката. Овој модел и неговите ограничувања се разработени во Amazon Builders’ Library.

Клучот треба да означува конкретна намера. Повторното доставување на нарачката WEB-1842 е различно од подоцнежна промена на истата нарачка. За промените треба посебно правило за верзија, дозволени полиња и редослед.

Проверката на клучот и создавањето на записот треба да бидат заштитени и при истовремени барања. Проверка само во интерфејсот на продавницата не го решава проблемот во системот што ги прима податоците.

Направете ја состојбата разбирлива

За оперативниот тим, пораката „грешка при синхронизација“ е недоволна. Корисно е да се знае која нарачка е засегната, кога е направен последниот обид и дали е потребна поправка на податоците или проверка на врската.

Замислете три работни состојби: подготвено за обработка, обработено и потребна проверка. Тимот треба да знае што значи секоја состојба и кој е одговорен за записите што остануваат нерешени. Техничките детали може да се чуваат одделно од пораката што ја гледа операторот.

Бележете ги идентификаторите што ја поврзуваат нарачката во двата система. При пријава на проблем, тие се многу покорисни од пребарување по име на купувач.

Одвојте прекин од погрешен податок

Краток прекин на врската може да оправда повторен обид. Непостоечка шифра на артикл бара друга постапка. Ако секој неуспех се повторува бесконечно, редицата може да остане полна со записи што никогаш нема да поминат без интервенција.

Договорете ограничен број обиди и разумно растојание меѓу нив. По достигнатиот лимит, записот нека премине во видлива листа за проверка. Рачното повторно пуштање треба да ги почитува истите правила за идентитет како автоматското.

Проверете ја целата деловна слика

Тестирајте прекин по зачувување, повторно доставување на ист запис и два истовремени обида. Вклучете и непостоечки артикл, изменета количина и откажана нарачка. За секој случај договорете што треба да видат и двата тима.

Периодична споредба на записите може да открие и пропуштени нарачки што не создале видлива грешка. Одредете кој ја прегледува таа споредба и како се разрешува разликата. Добрата интеграција му остава на тимот јасен пат од проблем до проверен исход.

Погледнете како го планираме поврзувањето на продавница со Сметко ERP.