Онлайн или асинхронно? Как да изберете начина за интегриране на системите си

Представете си един четвъртък в края на месеца. Вашият отдел по операции качва файл с 50 000 анекса към полици (endosos), за да коригира тарифата на портфейла. Порталът ги получава и ги изпраща, колкото може по-бързо, към централната система. След няколко минути основната система започва да се бави. После спира да отговаря. Агентите, които в същия момент издават нови полици, виждат замръзнали екрани и никой не знае кои от 50 000 анекса са приложени и кои не.

Никой не е сгрешил в кода: без да е казано, е избрана една-единствена форма на интеграция (онлайн извикването) за работа, която е изисквала друга. Статията е за онзи, който отговаря за операциите или технологиите в регулирана компания или във верига за търговия на дребно: три въпроса, по ред.

Интегрирането не е «свързване на системи». То е решение как се държи бизнесът, когато една от тях се бави, пада или получава десет пъти повече работа от обичайното.

Първи въпрос: нужен ли ви е отговорът в същия миг, или може да почака?

Задайте го за всеки процес, не за цялата компания.

• Онлайн (синхронно): онзи, който пита, остава да чака отговора, за да продължи. Котировка на екрана: човекът не може да продължи без цената. Това е телефонно обаждане.
• Асинхронно: онзи, който пита, оставя работата, получава потвърждение за получаване и продължава със своето; другата система приключва със своето темпо и известява. Издаване на полица или подписване (timbrado) на фактура: важното е да стане правилно и да се знае в какво състояние е, а не да се случи в същата секунда. Това е административно гише.

Четири критерия:

1. Има ли човек, който гледа екрана и чака? Ако да и отговорът е кратък, клонете към онлайн.
2. Работата отнема ли повече от търпението на този човек? Дълги секунди, минути или часове: асинхронно.
3. Издържа ли другата система обема в най-лошия момент? Ако се задръсти при пик, онлайн извикването повлича със себе си канала, който зависи от нея. Асинхронно.
4. Зависи ли от трета страна, която може да се забави или да откаже? (банка, данъчният орган, доставчик). Асинхронно, и с номер за проследяване.

Практическо правило: онова, което решава един екран, е онлайн; онова, което движи пари, документи или наличности, обикновено е асинхронно.

Ако е онлайн: REST или gRPC?

Решението е техническо; критерият е на ръководството:

• REST, когато тежи повече съвместимостта с онези, които извикват (партньор, приложение, доставчик) или възможността всеки да може лесно да тества и отстранява грешки. Това е общият език на интернет: почти всеки инструмент го разбира. Може да има и версионирани договори.
• gRPC, когато строг договор, генерирани от него клиенти, непрекъснато предаване или измерена производителност оправдават онези, които извикват, да го поддържат; затова обикновено се среща между собствени системи, където и двата края го говорят.

Честа насока, не правило: REST навън, gRPC между собствени системи. Подробностите са в статията «REST или gRPC: кога кое да изберете и защо основната ви система не говори нито един от двата» (/blog/rest-or-grpc-when-to-use-each).

Ако е асинхронно: какъв вариант?

За това решение е добре да се различават шест често срещани възможности, които могат да се комбинират; литературата за корпоративни съобщения (Hohpe и Woolf) и документацията на големите облачни доставчици [1][2] описват много повече. Никоя не е «правилната»: всяка решава различен проблем.

Обратно известие: «ще ви известим с вашия референтен номер»

Ползвайте го, когато работата отнема секунди или минути и онзи, който е поискал, може да получава известия. Системата получател отговаря веднага «получено, вашият референтен номер е 4821» и започва да работи. Когато приключи, известява обратно с референтния номер. Технически резултатът се връща чрез callback (обратно извикване); ако се доставя по HTTP на регистриран адрес, обикновено се нарича webhook.

Референтният номер е номерът за проследяване, който свързва всеки отговор със заявката му (идентификатор за корелация [3]). Без референтен номер едно известие е документ без собственик.

Справка за състояние: «върнете се с вашия референтен номер и попитайте»

Ползвайте го, когато онзи, който е поискал, не може да получава известия (защитни стени, мобилно приложение, трети страни с ограничения). Връщате се с референтния си номер и питате «готово ли е?» през определени интервали.

Документацията на Microsoft го описва така: първоначалният отговор е «прието» (HTTP код 202), което указва къде да се пита, а справката връща състояния като чакащо, в обработка, успешно или неуспешно [4]. Работи там, където известието не стига, и предлага да се изисква ключ за всяка заявка, за да не се обработва два пъти [4].

Опашка: редицата от задачи

Ползвайте я, когато системата, която получава, има ограничение на темпото, а онзи, който изпраща, може да произвежда много повече. Който изпраща, оставя работата си и се оттегля; който обработва, я взема със собственото си темпо. Тя е преди всичко буфер: документацията на Microsoft я нарича Queue-Based Load Leveling и я описва като буфер между онзи, който пита, и услугата, който изглажда прекъсващи натоварвания, които биха могли да сринат услугата [5]. За повече скорост се добавят още обработващи върху същата редица (Competing Consumers), ако задачите са независими [6].

Сценарий (илюстративни цифри, без клиент). Един портал получава 50 000 анекса; основната система издържа 20 в минута. Без буфер порталът изтласква всичко наведнъж и основната система се задръства. При 20 в минута теоретичното време е около 42 часа (50 000 ÷ 20 = 2 500 минути); реалното зависи от проверки, повторни опити и оперативни прозорци. Опашката регулира входа; референтният номер за партида, таблото за напредъка и алармите се проектират отделно, а в замяна няма срината основна система в час пик.

Опашката не прави основната система по-бърза: прави така, че нейната граница да престане да бъде изненада. Не е подходяща, ако е нужен незабавен отговор или ако обемът е нисък и стабилен [5].

Събитие или тема (topic): известие по високоговорител

Ползвайте го, когато един и същ факт трябва да задвижи няколко неща едновременно: документи, известие до клиента, CRM, измами. Предишните вървят от един към един; събитието — от един към много. Вместо да каже на една система «направи това», онзи, който преживява факта, го обявява: «полица издадена», «плащане приложено». Всички абонирани получават копие, а онзи, който го издава, не знае колко са. В литературата за съобщения това е разликата между канал от точка до точка (един получател) и канал за публикуване и абониране (всички заинтересовани) [7].

Цената му: всичко е евентуално консистентно; известно време някои системи знаят новината, а други не. Не е подходящо, ако е нужна една-единствена атомарна транзакция между изпращача и получателите [8].

Поток от събития с голям обем: лентата, която може да се превърти назад

Ползвайте го, когато събитията са безброй, непрекъснати и е важно да се запазват, за да се прочитат отново. Apache Kafka го определя като улавяне на събития в реално време, съхраняването им трайно, за да се четат по-късно, и обработването им както в момента, така и ретроспективно [9]. Образът: лента от факти, която няколко екипа четат със собственото си темпо, докато трае конфигурираният период на задържане [9].

Има смисъл за телеметрия, наличности или измами; не за единична поръчка, защото е машинария, която някой трябва да експлоатира. Според документацията на всеки доставчик гаранциите за доставка, ред, дубликати и повторно възпроизвеждане се различават по продукт и конфигурация [10][11].

Обмен чрез таблици или файлове: когато другата система не може да получи нищо повече

Ползвайте го, когато системата получател е стара основна система, която не умее да говори на нито един от предишните езици. Такава система обикновено има четири ограничения:

• Не излага интерфейси, през които други да ѝ искат неща, и също така не известява, когато нещо се промени вътре в нея.
• Приема данни само в зона за обмен: договорени таблици или файлове, където им се оставя информацията.
• Обработва ги със своето темпо, често на пакети, като пуска собствен процес, който ги взема, изпълнява ги и записва резултата.
• Издържа малко натоварване, а отговорът идва когато този процес приключи, не когато е поискан.

Зоната за обмен е гише с фиксиран формат: там се оставя всяка инструкция със своя референтен номер, а основната система оставя резултата на същото място. Нейното достойнство: не се пише във вътрешните таблици на основната система. Нейната цена: някой трябва да следи зоната и отговорът се забавя колкото трае пакетът.

Върху тази зона се поставя антикорупционен слой (anti-corruption layer): преводач от модерните договори към полетата и темпото, които основната система разбира [12]. Така се модернизира на етапи (Strangler Fig, «удушаваща смокиня»), докато основната система продължава да работи [13].

Получено не е обработено

Ако отнесете от тази статия само една идея, нека бъде тази: потвърждението за получаване не е потвърждение на резултата. Често се вярва, че щом е дошло потвърждението, изпратеното е решено.

Има три нива на отговор и е добре да знаете на кое е всеки ваш процес:

SPEI е мексиканската система за междубанкови преводи, CEP е електронното удостоверение за плащане, Banxico е централната банка на Мексико, CFDI е мексиканската електронна фактура, а SAT е мексиканската данъчна служба.

Само третото ниво казва дали фактурата съществува, плащането е пристигнало или поръчката ще бъде изпълнена. Banxico го илюстрира: liquidado значи, че SPEI е уредила превода и е известила получаващата институция, а CEP удостоверява постъпването по сметката на бенефициента [16].

Индустрията вече разделя получаването от обработката. HTTP определя кода 202 като «приета за обработка, но обработката не е приключила»; заявката може никога да не се изпълни и протоколът няма как да изпрати по-късно състоянието [17]. В AS2, стандарта за обмен на документи между фирми, официалният пример за подписана разписка носи този коментар: «Това не е гаранция, че съобщението е обработено напълно или разбрано от получаващия преводач» [18].

Какво видяхме. При една интеграция на поръчки между две корпоративни системи, която прегледахме, от около осем извиквания две връщаха идентификатора на създадения документ; останалите шест — само потвърждение. Грешките идваха по имейл от получаващия отдел, около три дни по-късно. В същата партида имаше повече от десет еднакви случая, които никой не беше видял: откриват се само онези, които някой прегледа случайно, а останалите не се различават от успешните. Това е измерване на един-единствен случай, не цифра за индустрията. Най-евтиното, което проработи: да се провери, че върнатата референция съответства на правилния запис. При 234 записа не даде нито една фалшива тревога.

Какво да поискате, според варианта:

• При всички: референтен номер за всяка операция, който пътува напред и назад, за да се свърже всеки резултат със заявката му [3].
• Обратно известие: да известява резултата; едно «приключих», без да казва дали е приложено, е друго потвърждение за получаване.
• Справка за състояние: ясно състояние за всеки референтен номер (чакащо, в обработка, успешно или неуспешно) и, ако е неуспешно, причината [4].
• Опашка: съобщенията, които се провалят, да се отделят за преглед, с отбелязан произход [15].
• Таблици или файлове: един ред с резултат за всеки изпратен запис.

И още две защити. Изрично състояние за онова, което не се е върнало («непотвърдено от 10:40»): най-лошото не е грешката, а да не се знае. И периодично съгласуване, което сравнява изпратеното с потвърденото, с аларма за онова, което не се е върнало навреме; така мълчанието се превръща в задача с отговорник.

Проблем на отрасъла, първи въпрос, вариант

Насока за разговор, не рецепта: нормалното е да се комбинират варианти.

Рисковете, на езика на бизнеса

Един асинхронен вариант не премахва проблемите: премества ги. Пет за масата.

• «Вече е таксувано два пъти». Повечето опашки доставят всяко съобщение поне веднъж: може да пристигне повторено. Microsoft изисква многократната обработка да дава същия резултат, за да се избегнат «дублирани записи или повторни такси» [5]: всяка инструкция носи уникален ключ и системата отбелязва кои вече е обработила.
• Редът. Когато няколко обработващи взимат от една и съща редица, няма гаранция, че задачите ще завършат в реда, в който са влезли [5][6]. Ако «анулирай полицата» пристигне преди «издай полицата», има проблем. Определете ключа за ред на вашия бизнес (полица, плащане, щета) и го спазвайте там, където е важно.
• Повторни опити без спирачка. Преходна грешка заслужава нов опит; функционален отказ («несъществуваща сметка») не се оправя с повторение. Препоръчва се да се отдели в опашка за изключения и да се наблюдава [5][6].
• Да не се знае в какво състояние е нещо. Това е рискът от предишния раздел; при събитията е добре освен това идентификатор, който да преминава през всяка операция от край до край [8].
• Всеки вижда различна версия, за известно време [8]. Решете предварително кой е собственикът на крайните данни и как се съгласува една операция, останала наполовина.

Форматът на известията е споразумение, което се версионира; CloudEvents изисква source плюс id да е уникално за всяко събитие, което помага да се откриват повторни изпращания [14].

Пет въпроса за следващия ви комитет

1. Кои решения изискват незабавен отговор и кои могат да се решат с референтен номер?
2. Какво е максималното темпо, което нашата основна система издържа, и какво става, ако пристигне десет пъти този обем?
3. Кой е собственикът на крайното състояние на всяка операция и как се съгласува такава, която е останала непълна?
4. Как проверяваме, че повторен опит не дублира плащане, полица, CFDI или движение?
5. От онова, което изпратихме вчера, кои операции имат потвърждение на резултата (приложена или отхвърлена) и кои само потвърждение за получаване?

Ако при два или повече от тях отговорът е «не знам», там може да е вашият риск.

Откъде да започнете тази седмица

Запишете най-важните си процеси (издаване, събиране на плащания, подписване, наличности), коя система отговаря за всеки и колко работа в минута издържа; и дали онзи, който го започва, има нужда от отговора веднага, или би му стигнал референтен номер. Ще видите къде се ползва онлайн извикване за работа, която е изисквала опашка.

После вземете един интерфейс и пребройте колко от операциите, изпратени вчера, имат потвърждение на резултата, не само потвърждение за получаване.

Какво прави Hábil

Hábil е мексиканска инженерна консултантска компания, основана през 2006 г., която работи между системите, които една компания вече има, и каналите, които трябва да отвори. Вижте страницата Обединяване на дейността и каналите.

Първият разговор е безплатен: тръгва от картата на вашите текущи интеграции и от мястото, където операцията ви би могла да загуби пари, време или доказателства. Пишете ни в WhatsApp.

Описанията на услугите на доставчиците отразяват тяхната документация към 6 октомври 2026 г.; това са твърдения на доставчика, не наши измервания.