На тази страница
Актуализация на поръчка пристига преди събитие за нейното създаване. На друго място събитие за плащане пристига преди по-ранно събитие за абонамент. Това са илюстративни екипи с различни продукти и формати. И двата се изкушават да поправят проблема, като подредят доставките по момента на пристигане.
Това не е доклад за инцидент на нито един от екипите. Пита дали двата провала имат обща форма, макар подробностите на доставчиците да се различават.
Разговор от включените източници за математически връзки отбелязва, че наглед различни проблеми може да имат полезна обща форма. Прилагането на идеята към софтуерни интеграции е извод. Той е полезен само когато общата форма дава тест, подкрепен от документираното поведение на всяка система.
Махнете имената, после върнете договорите
Опишете първия случай без имена на продукти: събитие за ресурс може да пристигне след по-късна промяна на същия ресурс. Получател, който третира реда на пристигане като ред на състоянията, може да презапише нова информация със стара.
Сега разгледайте двата действителни договора. Документацията на Shopify за уебхукове казва, че редът не е гарантиран дори в рамките на тема, и дава пример, в който събитие за актуализация на продукт може да се достави преди събитието за създаването му. Документацията на Stripe за уебхукове също казва, че събитията не е задължително да пристигнат в реда на генериране, и препоръчва извличане на липсващи обекти, когато очаквано по-ранно събитие не е пристигнало.
Shopify и Stripe предупреждават, че редът на доставяне не е гарантиран. Общият въпрос е дали крайното състояние остава правилно; идентификаторите и правилата за възстановяване на всеки доставчик искат собствени тестове.
Преносимият въпрос е: „Ако това събитие пристигне преди свързано с него, можем ли пак да определим правилното текущо състояние?“. Отговорът за реализацията не се пренася по допускане. Shopify документира заглавки като X-Shopify-Webhook-Id и времеви отметки. Stripe използва свои ID-та на събития и правила за извличане на обекти. Идентификатор, който означава „доставка“ в една система, може да означава друго в друга.
Нашето ръководство за конектора към Brevo разглежда отделни подробности за полета и съпоставяне. Те са важни за работеща интеграция, но не бива да се приемат за универсално поведение на API.
Общата форма е неизменно условие
За синхронизация на клиенти неизменното условие може да бъде: след обработката клиентският запис в целевата система отразява текущото състояние на разрешения източник. За фактуриране може да бъде: действие, зависещо от плащане, се извършва само когато авторитетното състояние на плащането го позволява. Условието назовава какво трябва да остане вярно дори когато събитията закъсняват, се повтарят или са непълни.
Запишете четири неща, преди да изберете поправка:
| Въпрос | Защо има значение |
|---|---|
| Коя идентичност назовава бизнес обекта? | ID-то на събитие може да назовава съобщение, а не клиент или поръчка. |
| Коя система притежава текущото състояние? | Съдържанието на събитие може да е моментна снимка, промяна или само препратка. |
| Какви времеви гаранции дава източникът? | Редът на доставяне може да е различен от реда на състоянията. |
| Кое крайно условие доказва успех? | Полученото събитие не доказва, че целевата система е правилна. |
Таблицата помага на мисленето; не е протокол. Отговорът за източника на истината зависи от процеса. Справка на живо може да е необходима в една система и неподходяща в друга. Някои събития трябва да се запазят като исторически факти, вместо да се слеят в най-новата моментна снимка.
Използвайте пак теста, после приспособете поправката
Малък тест на договора може да изпрати свързани събития в обратен ред и да попита дали крайното състояние в целевата система остава правилно. Друг може да изпрати същата доставка два пъти. Тестовете показват формата на риска. После документацията на доставчика определя как да идентифицирате, проверите и възстановите всяко събитие.
Разграничението пази екипите от архитектура на копиране. Ключ за премахване на дубликати от един API може да се провали в друг. Времева отметка с груба точност може да не установява реда. Извличане на текущия обект може да е необходимо за синхронизация на състояние, но не може да възстанови всяко междинно историческо събитие. Ръководството за интегриране на няколко бизнес инструмента започва с решението коя система притежава всяко поле; без него „най-ново“ няма ясен смисъл.
Преносът на закономерности има граници. Подобни симптоми може да имат различни причини: липсващ запис може да е резултат от заявка без разрешение, забавен уебхук, невалидно съпоставяне или отхвърлен запис. Преди да обявите два случая за еднакви, сравнете договора на източника, договора на целевата система и наблюдаваното крайно условие. Ако някое се различава, запазете общия въпрос и сменете теста.
Методът помага и отвъд доставката на събития. Поле, прието от API, но липсващо от видимия за потребителя запис, повдига същия общ въпрос във всеки конектор: какво доказва потвърждението и кое доказателство потвърждава желаното състояние? Отговорът може да включва прочитане от целевата система, справка за схемата или проверка на разрешенията. Закономерността подсказва на екипа да отдели транспорта от смисъла. Не му казва кое поле или крайна точка да извика. Този по-тесен урок е по-малко вълнуващ от универсална рецепта за интеграции, но се пренася по-далеч, защото държи местните факти видими.
Най-силният повторим урок не е откъс от код. Той е въпрос, който преживява преминаването към друга система и прави местния договор по-лесен за изследване.
Често Задавани Въпроси
Може ли един тест за интеграция да се използва при различни доставчици?
Въпросът често се пренася, например дали актуализации могат да пристигнат в различен ред. ID-тата на събитията, смисълът на данните, подписите и стъпките за възстановяване трябва да се вземат от договора на всеки доставчик.
Каква е разликата между закономерност и копирана поправка?
Закономерността назовава условието за провал и неизменното правило за запазване. Копираната поправка приема без проверка, че втората система има същите идентификатори, ред на събитията и значение на състоянията.
Какво трябва да се провери след прилагане на събитие?
Проверете състоянието в целевата система, което процесът изисква, не само получаването на събитието или HTTP отговора. Крайното условие зависи от бизнес обекта и правилото за източник на истината.