Сату мен қойма үшін минималды API келісімі: объектілер мен оқиғалар

Неліктен минималды келісім қажет және ол немен көмектеседі

Сату жүйелері мен қойма арасында интеграциялар көбіне API-дің өзі үшін емес, терминдер мен мағыналардың алшақтығынан баяулайды. Бір жүйеде бұл «клиент», ал өзгесінде — «контрагент». Бір жерде «Отгружено» статусы «складтан шықты» дегенді білдірсе, екіншісінде — «тасымалдаушыға тапсырылды». Тұрғаны — әртүрлі идентификаторлар: бір сервис өз тапсырыс нөмірін сақтайды, басқасы жаңа нөмір генерациялайды, және кейін не қайсысы неге тең екенін анықтау қиын болады.

«Жылдам» интеграциялар бастапқыда арзан көрінеді, бірақ кейін олар қайта шығындарға әкеледі: дубликаттар, қате қалдықтар, бірнеше рет шығару, қолмен салыстырулар және әр жаңа сервис қосылғанда шұғыл түзетулер. Әсіресе қиын — жаңа сатылым арнасы немесе жаңа WMS қосылғанда: бұрынғы нүктелі келісімдер қайшылық тудырады.

Минималды келісім — бұл барлық жүйелерге бір операцияны бірдей түсінуге мүмкіндік беретін объектілер мен оқиғалардың ортақ жинағы. Ол ERP, CRM және WMS барлық жайттарын қамтамаса да, негізгі ортақ бөлікті бекітеді: біртұтас идентификаторлар, негізгі статустар және міндетті өрістер.

Көбіне мұндай келісім қарапайым тізбекті қамтиды: сату (тапсырыс құру және өзгерістер), резерв (қанша және не үшін сақталған), отгрузка (складтан нақты алынған заттар), қабылдау (қайтарылған немесе келген), түзетулер (инвентаризация, шығару, пересортица).

Жай мысал: жаңа жеткізу сервисі «Отгрузка создана» оқиғасын алады және статус не білдіретінін, адресті қайдан алу керектігін немесе позицияларды қалай сәйкестендіру керектігін болжаудың қажеті жоқ. Ол бір форматты оқиды — қалған қатысушылармен бірдей ID және ережелер бойынша.

Принциптер: шекаралар, дереккөздер және идентификаторлар

Сату мен қоймаға арналған келісім интеграцияны шын мәнінде жылдамдату үшін өрістер тізімінен гөрі ережелер туралы келісуді талап етеді. Олар төрт сұраққа жауап беруі керек: домен шекарасы қайда өтеді, деректердің иесі кім, идентификаторлар қалай көрінеді және қандай объектінің сілтеме дереккөзі екенін қалай есептеу.

Домен шекаралары: жауапкершілікті араластырмау

Сату, қойма, қаржы және логистика көбіне бірдей сөздерді («статус», «отгрузка», «оплата») қолданады, бірақ әрқайсысы өзгеше мағына береді. Жауапкершілікті араластыру әр түзетуді тізбекті реакцияға айналдырады.

Жай бағдар: әр домен өзіне тиесілі нәрсені ғана сақтап өзгертуі керек. Сату — тапсырыс пен оның өмірлік циклына ие, қойма — қозғалыстар мен резервке, қаржы — төлемдер мен есепке, логистика — маршрут пен трекингке.

Әр объект үшін бір шынайы дереккөз

Әр сущность үшін бір мастер таңдалады: объектіні құратын және өзгертетін жүйе. Басқалары көшірме алады және өз атрибуттарын қоса алады, бірақ өзге бөлікті қайта жазбауы тиіс.

Мысалы, тауар картасы (атауы, штрихкод, өлшеу бірлігі) PIM немесе ERP-ге тиесілі. Қойма атауды «түземеуі» керек, ал сату интерфейсте ыңғайлы болғанымен негізгі ораманы өзгертпеуі тиіс.

Идентификаторлар: өзгермейтіндік және сәйкестендіру

Екі типті ID бастапқыда бекітіңіз: ішкі (иелік жүйедегі) және сыртқы (интеграцияға арналған). Сыртқы ID тұрақты болуға тиіс — тасымалдау, біріктіру немесе миграция кезінде өзгермеуі керек.

Практикалық ереже: кез келген сервис сұрауды сыртқы ID-мен қабылдап, екеуін де қайтарады. Бұл сәйкестіктер құруды және айырмашылықтарды қолмен кестелерсіз түзетуді жеңілдетеді.

Справочниктер және транзакциялар: өмір сүру моделдері әртүрлі

Справочниктар «бұл не» деп сипаттайды (тауар, қойма, контрагент, валюта) және сирек өзгереді. Транзакциялар «не болды» деген фактіні сипаттайды (тапсырыс, отгрузка, қайтару, кіріс, перемещение) және факт ретінде тіркеледі.

Егер күмәндансаңыз: объектіге атау өзгертілсе ешқандай салдары бола ма, әлде әр өзгеріс оқиға ретінде көрінуі керек пе? Екінші жағдайда бұл транзакция және оны дата, автор және себеппен бөлек сақтау жөн.

Негізгі справочтық объектілер: әрқашан болуға тиіс нәрселер

Жаңа сервис ұзақ келісімдерсіз қосылсын десеңіз, ортақ сөздікпен бастаңыз. Сату мен қойма келісімі көбіне тапсырыстар мен қалдықтарда емес, жүйелердің «кім сатады», «тауар қайда орналасқан» және «қай позиция бір затты білдіреді» деген мәселелерінде үзіледі.

Жақсы базалық справочниктер — «толық мастер-деректер» емес, әр операцияға контекст беріп құжаттарды сәйкестендіруге мүмкіндік беретін қысқа сущносттер жиынтығы.

Минималды жиын, әдетте қажет болады:

• Ұйым және бөлімше: қай юрлицо операцияның иесі және қай жерде өткен (филиал/нүкте). Көбіне company_id, branch_id, атауы және активтілік статусы жеткілікті.
• Қойма және сақтау орны: қойма барлыққа қажет, ал аймақ немесе ячейка нақты дәлдік үшін керек (мысалы, адрессіз сақтау). Ячейка жоқ болса да location_id өрісін қарастыру пайдалы.
• Тауар және SKU (вариант): тауар — «немені сатамыз» (модель), SKU — «қандай күйде» (түсі, комплектациясы, сериялық). Өлшеу бірлігін және коэффициенттерді қосыңыз (дана, қорап, кг), сонда қайта есептеу даулары болмайды.
• Контрагент: құжаттар үшін клиент немесе жеткізушінің минималды картасы. Барлық реквизиттерді бірден салмаңыз, бірақ тұрақты counterparty_id, түрі (customer/supplier), атау және қажет болса салық идентификаторын сақтаңыз.
• Actor (қолданушы немесе сервис): кім құрастырды, өзгертті, растады. Аудит пен инциденттерді зерттеу үшін қажет.

Практикалық мысал: тапсырыс интернет-дүкенде филиал A-ға рәсімделген, отгрузка қойма B-ден жасалған, жинау нақты аймақтан өтті. Егер справочниктерде бірдей branch, warehouse және location болмаса, тіпті бірдей нөмірлер болғанымен екі құжатты сенімді байланыстырмауға болады.

Бұл сущносттерді шағын, анық идентификаторлары бар және архивтік белгісімен ұстаңыз. Қалғанын кейін қосуға болады, негізді өзгертпей.

Қойма сущносттері: қалдықтар, резервтер және қозғалыстар

Қойма интеграцияларды күрделі логикадан гөрі бірдей сөздердің әртүрлі түсіндірілуінен бұзады: «қалдық», «резерв», «қозғалыс». Келісімде бұл сущносттерді осылайша бекіту маңызды — жаңа сервис қанша тауар бар, не клиентке уәде етілген және неге сандар өзгергенін бірден түсінсін.

Остаток (stock balance) — нақты орын бойынша «қазір қанша бар» деген сәттік сурет. Ол кемінде қойма (warehouse), орын (location) және SKU бойынша бөлінуі керек. Мөлшердің статусын көрсету маңызды: мысалы, «жеткілікті», «карантин/брак», «жолда», сонда сервистер сатуға болмайтын тауарды есептемейді.

Резерв (reservation) — «не қазір артықсыз» деген сұраққа жауап береді. Резерв әрдайым себебіне сілтейді (әдетте тапсырыс немесе тапсырыс жолы), авторы (система/қолданушы), жарамдылық мерзімі және анық тоқтату бар. Осылайша тапсырыс отмена болғанымен резерв мәңгі тұрып қалмайды.

Қозғалыс (stock movement) — қалдықтың не үшін өзгергенінің шынайы дереккөзі: кіріс, шығыс немесе перемещение. Қозғалыстар болғанда «тауар жоғалды» деген дау тез «мында операция бар, мында себеп» түріне айналады.

Міндетті өрістер (ұсынылған)

Барлық сервистерде бірдей болатын шағын жиынға келісу жақсырақ:

• warehouse_id, location_id, sku_id (қайда және не)
• quantity және өлшеу бірлігі (қанша)
• stock_status (жетімді, брак, жолда)
• reservation_id немесе reference (қайда резервтелген/шыққан)
• movement_type және reason_code (не болды және не үшін)

Инвентаризация (inventory count) нақты табылған «факт»-ты қосады: қанша табылды, есепке қатысты айырма қандай және кім растады.

Партиялар/сериялар/жағымдылық мерзімі тек сату мен шығару үшін маңызды болса қосылады (мысалы, дәрі-дәрмек, тағам, кепілдік техника). Бұл атрибуттар қалдықтарда, резервтерде және қозғалыстарда бірдей көрсетілуі тиіс. Егер олар тек бір жерде сақталса, есеп тез айырылып кетеді.

Сату: тапсырыс, отгрузка, қайтару және төлемдер

Жаңа сервис сату жүйесіне тез қосылу үшін әдетте төрт сущность жеткілікті: тапсырыс, отгрузка, қайтару және төлем.

Тапсырыс: сатып алушы не сұрады

Тапсырыс ниетті тіркейді, нақты отгрузка фактісі емес. Оны басқа сервистерге бармай-ақ оқу керек: соманы есептеп, құрамын және мерзімдерін түсіну мүмкін болуы тиіс.

Көп жағдайда жеткілікті минималды жиын:

• Идентификаторлар: order_id, тапсырыс нөмірі, құру күні/уақыты, клиент (customer_id)
• Жолдар: item_id/sku, көлем, баға, жеңілдік, салық ставкасы/сома, жол бойынша итог
• Қаржы: валюта, салыққа дейін/кейінгі сомалар, дөңгелектеулер
• Мекенжайлар және байланыс: жеткізу және биллинг (кемінде ел/қала/мекенжай жолы)
• Мерзімдер: уәде етілген отгрузка/жеткізу күні, шарттар бойынша комментарий

Тапсырыс статустары қарапайым әрі анық болуы тиіс. Қызмет көрсетудің минимумдары: draft (шаблон), confirmed (растау), canceled (отмена), closed (жабық). Атынан маңыздысы — статус тек анық оқиға бойынша өзгереді (растау, отмена, толық отгрузка және жабу).

Отгрузка және қайтару: не нақты орындалды

Отгрузка (shipment/fulfillment) — нақты фактіні сипаттайды: не шықты, қашан және қайдан. Ол тапсырысқа және отгрузка құрамына байланысты өтуі тиіс, себебі бөліп отгрузу — қалыпты жағдай.

Қайтару (return) нақты отгрузкаға немесе оның жолдарына сілтеме жасауы керек, сонда не қайтарылғаны туралы дау болмайды. Қайтаруға себеп және тауардың жағдайын көрсетіңіз (жаңа/ашылған/зақымдалған).

Төлем минималды түрде сақталуы мүмкін: payment_id, order_id, сома, валюта, әдіс, статус (жасалды, авторизацияланған, төленді, отмена, қайтару), операция күні. Егер тапсырыс расталғанымен төлем тек авторизацияланған болса, жеткізу және қолдау сервистері оны автоматты түрде «төленді» деп санамауы тиіс.

Интеграциялық оқиғалар: қайсысы және не үшін

Интеграциялық оқиғалар сатулар мен қоймаға не болғанын басқа сервистерге хабарлап, оларды бір-біріне шақырмай-ақ әрекет етуге мүмкіндік береді. Бір сервис факт жариялайды, қалғандары жазылып алып әрекет жасайды.

Оқиға мен команданы айыра білу маңызды. Команда — бұл «осыны жаса» деген сұраныс (мысалы, тауарды резервте). Оқиға — «бұл болды» деген хабарлама (мысалы, резерв жасалды). Командалар әдетте жауап күтеді және бас тартылуы мүмкін. Оқиғалар сұрау емес және факт болуы тиіс.

Сатулар үшін минималды оқиғалар жиыны көбінесе OrderCreated, OrderConfirmed, OrderCanceled болып жеткілікті. Бұлар антифрод, бонус жүйелері, хабарламалар, құжаттарды басып шығару және аналитика үшін жеткілікті.

Қоймаға қалдық пен өзгерістер туралы фактілер қажет: StockReserved, StockReleased, StockMoved, StockAdjusted (инвентаризация/брак бойынша түзету). Олар тарихқа сүйенуге мүмкіндік береді, болжамға емес.

Логистика отгрузка мен қайтарудың өміршеңдігін қосады: ShipmentCreated, ShipmentShipped, ShipmentDelivered, ReturnReceived. Осылай жеткізу, CRM және қолдау бірдей статусты көреді, қолмен салыстырусыз.

Оқиғалар пайдалы әрі қауіпсіз болу үшін әр хабарламада міндетті минимум болсын:

• eventId
• type
• occurredAt
• source
• version

Егер әрекеттер тізбегі болса (мысалы, тапсырыс резерв жасады, сосын отгрузка пайда болды), correlationId қосыңыз. Ол оқиғаларды бір тарихқа байланыстырып, интеграциядағы проблемаларды іздеуді айтарлықтай жеңілдетеді.

Келісім ережелері: статустар, нұсқалар, идемпотенттілік

Келісім бір айдан кейін құламаса, объектілер мен оқиғаларға қатысты ережелер қажет. Олар сервистер тәуелсіз дамыса да интеграцияны болжамды етеді.

Әр объектіде оны сақтау, жаңарту және жүйелер арасында салыстыруға болатын жалпы негізгі өрістер болуы керек:

• id (объектінің тұрақты идентификаторы)
• createdAt және updatedAt (қашан пайда болды және қашан өзгерді)
• status (объектінің ағымдағы жағдайы)
• source немесе originSystem (жазбаны кім жасады - тергеулер үшін қажет болса)

Статустармен аса қырағы болыңыз: қысқа тізім және нақты өту ережелері. Негізгі талап — күтпеген секірістерге тыйым салу. Егер тапсырыс уже shipped болса, ол кенеттен draft болуы керек емес. Откат қажет болса, жеке оқиға (мысалы, қайтару) арқылы жасаңыз, тарихты қайта жазбаңыз.

Идемпотенттілік екі орында қажет: командаларда және оқиғаларда.

• Командалар (тапсырыс жасау, резерв растау) үшін idempotencyKey пайдаланыңыз: қайталағанда сервер дәл сол нәтижені қайтаруға міндетті, дубликат жасаудың орнына.
• Оқиғалар үшін қайталануды қалыпты жағдай ретінде қарастырыңыз: тұтынушы бір оқиғаны екі рет өңдей алатындай болсын, жанама әсерлер болмайсын — eventId пен өңдеу фактісін сақтау арқылы.

Схема нұсқаларын қарапайым ұстаңыз: артқа үйлесімділік міндетті. Жаңа өрістер қосуға болады, бірақ ескі өрістерді қайта атауға және мағынасын өзгертуге болмайды. Егер өріс ескірсе, оны deprecated деп белгілеп, шығару мерзімін беріңіз.

Қателерді қолдау үшін ыңғайлы етіңіз: код, түсінікті хабар және өрістер бойынша детальдар. Валидациядан өтпеген жағдайда жалпы код (мысалы, VALIDATION_ERROR) және проблемалы өрістер тізімі мен себептері қайтарылсын — интегратор сұрақсыз түзетеді.

Келісімді 1–2 аптада қалай жинауға болады: кезеңдер

1–2 апта ішінде бәрін сипаттауға тырыспаңыз. Маңыздысы — құн әкелетін минимум: сату, отгрузка, қабылдау және қойманың қайта есептелуі. Осы сценарийлер шұғыл қажет объектілер мен оқиғаларды көрсетеді.

Іс-қимыл жоспары (керексіз бюрократиясыз)

3–4 минималды сценарий жинап, оларды қысқа әңгімелер ретінде жазыңыз: кім не істейді және қандай нәтиже көру керек (мысалы, тапсырыс жасалды, тауар резервтелді, отгрузка расталды).

Содан кейін бір бетке сущносттер мен байланыстарды сызып шығыңыз: тауар, қойма, контрагент, тапсырыс, отгрузка, кіріс, қозғалыс, қалдық, резерв. Осы кезеңде қай жерде мастер, қай жерде сыртқы кілт екенін келісіңіз — нені бір объект деп санау керек.

Келесі қадам — тапсырыс пен отгрузка үшін статустар мен өту ережелерін бекіту. Көп керек емес: 4–6 статус, бірақ өзгерістер қай жағдайда рұқсат етілетіні анық болуы керек.

Содан соң оқиғалар мен олардың payload-ын анықтаңыз. Әр оқиға үшін үш сұраққа жауап беріңіз: не болды, қабылдаушыға қандай кілттер қажет және оқиға өңделгені қалай анықталады (eventId, нұсқа және дедупликация ережелері арқылы).

Және де интеграцияларды бұзатын «ұсақ-түйектерді» келісіңіз: уақыт пен уақыт белдеуі, дата форматы, дөңгелектеулер, валюта, өлшеу бірліктері, қайта есептеу ережелері (дана, қорап, кг).

Келісілгеннен кейін тест деректер мен эталон хабарламалар жасаңыз. Барлығы бір үлгіге қарап істегенде талқылауда күндер үнемделеді.

Шығарда не болу керек

• Бір оқылатын сущносттер мен байланыстар схемасы (түсініктемесіз оқуға болады).
• Тапсырыс пен отгрузка үшін статустар мен өту ережелері кестесі.
• Оқиғалардың тізімі, қысқа сипаттамасы және payload мысалы.
• Тексерулер үшін тесттік объектілер және 5–10 эталондық хабарлама жиынтығы.

Жобалау кезінде жиі қателер мен тұзақтар

Көп кездесетін қате — справочник пен транзакцияны бір объектте сақтау. Мысалы, «Тауар» объектісіне соңғы сату бағасы, қалдық және соңғы отгрузка күні енгізіледі. Нәтижесінде справочник тұрақсыз өзгереді, кэштелген деректер үзіледі, және жаңа сервистер дереккөзді қайдан алу керектігін түсінбейді.

Екінші тұзақ — өзгермелі идентификаторлар мен әлсіз сілтемелер. Егер тапсырыс нөмірін «қайта атауға» болады және отгрузка тапсырысқа сілтеме сақтамаса, бір айдан кейін не отгрузылғаны және несіне ақша қайтарылғанын нақты айту қиын болады.

Тағы бір ауыртпалық — резервтердің болмауы немесе «қалдықтың ішінде жасырылуы». Сонда сату «қалдық 10» деп көріп сатады, ал қойма оның 8-ін басқа тапсырысқа қойған. Қолмен есептеу басталады.

Интеграциялық оқиғалар жиі версиясыз және correlationId-сіз жасалады. Сол кезде айырмашылықтарды іздеу болжамға айналады: қай оқиға бірінші болды, қай жерде расталғаны жоғалды, қандай тапсырысқа қозғалыс қатысты.

Келісім көмектесуі үшін модельді бірінші күннен аса жүктемеңіз. Әдетте негізгі сценарийлер жабылып, кейін кеңейтуге орын қалдырылады.

Көбіне ұмытылатыны:

• бөлшектеп отгрузу (бір тапсырыс 2–3 машинада кетуі мүмкін)
• бөлшектеп қайтару (5 позицияның 1-ін ғана қайтарды)
• әр құжат үшін бөлек статустар: «жасалды», «растады», «отменен»
• командалар мен оқиғаларда идемпотенттілікті қамтамасыз ету

Мысал: жеткізу сервисі «Отгрузка создана» хабарын жіберіп, кейін «Отгрузка обновлена» деп версиясыз жіберсе, қойма қозғалысты екі рет есептеп қалуы мүмкін. Оқиға версиясы мен correlationId қайталануды қай жерде болғанын көрсетер еді.

Жылдам тексеріс: минималды келісім чек-листі

Келісімді жаңа командаларға және сыртқы сервистерге бермес бұрын қысқа тексерістен өткізіңіз. Мақсат — интеграция болжамсыз болмауы және оқиғалардың қайталануынан сынбауы.

Тізім бойынша өтіп, шынайы түрде «иә/жоқ» деп жауап беріңіз:

• Біртұтас идентификаторлар: order, shipment, sku, warehouse, location үшін тұрақты ID бар ма, олар уақыт өте өзгермейді және әр жүйенің исходынан тәуелсіз бе?
• Статустар және өтулер: тапсырыс пен отгрузка үшін статустар мен рұқсат етілген өтулер анықталған ба? Отмена, бөлшек отгрузка және қайтару қалай өңделетіні түсінікті ме?
• Қойма бөлек модель ретінде: қалдыққа емес, бөлек резерв (reservation) және қозғалыс (stock movement) сущностері бар ма? Қалдық қайдан және неге өзгергені түсінікті ме?
• Оқиғалар толық: әр оқиға eventId, уақыт, source, version және correlationId-пен келеді ме, сонда «тапсырыс → отгрузка → төлем» тізбегін байланыстыру оңай ма?
• Қайталау мен дәлдік: идемпотенттілік пен қайта жіберу ережелері анықталған ба (қайсысы дубль, дедупликация қай өрістер бойынша)? Өлшеу бірліктері, дөңгелектеу және уақыт белдеуі келісілген бе?

Егер екі және одан көп тармаққа «жоқ» жауап берілсе, тосын сыйлар дерлік кепілдендірілген. Мысалы, жеткізу сервисі ShipmentCreated-ты қайта жіберсе және идемпотенттілік болмаса, қалдық екі рет шығып кетуі немесе чек қайталануы мүмкін. Мұндай тексеріс 10 минутқа сыйып кетеді, бірақ өндірістегі қателерді шешуге күндер үнемдейді.

Мысал сценарий: жаңа сервисті ядроны өзгертпей қосамыз

Интернет-дүкен өсіп, екі мәселені бірден шешуді қалады: жаңа жеткізу сервисін (мерзімдер мен трекинг үшін) қосу және қоймада жаңа WMS енгізу. Бұрын менеджер «тапсырыста не», «не жиналды» және «не шықты» дегенді қолмен салыстыратын, ал қалдықтар жиі сәйкес келмейтін.

Минималды келісім басты мәселені шешеді: барлық жүйелер бірдей объектілер мен оқиғалар тілін қолданады. Сату ядросы WMS немесе жеткізудің ішкі егжей-тегжейін білмейді; ол стандартты фактілер жариялайды және қабылдайды: тапсырыс расталды, резерв жасалды, отгрузка жіберілді.

Әдеттегі ағым: OrderConfirmed -> StockReserved -> ShipmentShipped -> StockMoved. Осы арқылы жаңа WMS қойма оқиғаларын орындаушы ретінде қосуға болады, ал жеткізу сервисі отгрузка оқиғаларына жазылушы болып қосылады — бар процестерді бұзбай.

Шығыстар тағайындалған орынға ие болады, өйткені бәрі келісімде қарастырылған:

• заказ отменасы: OrderCanceled резервтерді босатады және жинауды тоқтатады
• жетіспеушілік: StockReservationFailed немесе StockAdjusted факті мен себебін тіркейді
• бөлшектеп отгрузу: ShipmentPartiallyShipped және резервтің дұрыс азаюы
• қайтару: ReturnRegistered -> StockMoved (бөлек аймаққа немесе негізгі қоймаға)
• қайталанған жағдайлар: идемпотенттілік резервті немесе қозғалысты екі рет жасамауға кепілдік береді

Нәтижені бағалау үшін алдын ала метркаларды келісіңіз: интеграция қанша күнде аяқталды, алғашқы 2 аптадағы инциденттер саны және сатулар мен қойма арасындағы қалдықтар айырмашылығы қаншалықты жиі болды. Жақсы келісім болса, осы сандар айтарлықтай төмендейді.

Келесі қадамдар: енгізу және қайда көмек қажет

Инвентаризациядан бастаңыз. ERP, WMS, POS, маркетплейстер, CRM сияқты жүйелердегі бар объектілер мен оқиғалар тізімін жинап, оларды минималды бекітуге сай салыстырыңыз. Қай жерлерде атаулар әртүрлі, қай жерде идентификатор жетіспейтінін және қай статустар тек команда мүшесінің «басында» екенін тез анықтайсыз.

Сосын деректер иелерін белгілеңіз. Олай етпесеңіз интеграциялар «кімнің шындық» деген ұрысқа айналады. Негізгі аймақтар бойынша жауапкершілікті бекітіңіз: тауар мен справочниктерді кім жүргізеді, қалдық пен резерв бойынша қай жүйе шынайы дереккөз, тапсырыс қай жерде құрылады және қай жүйе отгрузка мен қайтаруды хабарлайды, төлем туралы кім хабарлайды және қандай ережелер бойынша.

Пилотты осылай жоспарлаңыз: әсер беретіндей, бірақ детальдарға батып кетпейтіндей. Жақсы нұсқа — бір қойма мен бір сатылым арнасы (мысалы, интернет-дүкен) және нақты сценарийлер: тапсырыс, резерв, отгрузка, қайтару. Пилоттан кейін масштабтаңыз — келісімді өзгертпей, жаңа көздерді қосыңыз.

Инфрақұрылымды алдын ала ойластыру қажет: кезек немесе оқиға шинасы, біртұтас журналдар, алерттер мен жеткізу метрлері, қайталама әрекеттер және дедупликация. Қарапайым ереже: егер оқиғаны апта бойы табу және түсіндіру мүмкін болмаса, ол бизнеске көмектеспейді.

Егер интеграция мен инфрақұрылым бойынша көмек қажет болса, GSE.kz жүйелік интегратор ретінде көмектесе алады: архитектура жинақтау, мониторинг пен отказоустойчивость орнату, сондай-ақ шина мен сервистерге арналған серверлік платформаны таңдау және орналастыру (мысалы, S200 серверлері негізінде) және 24/7 қолдауды ұйымдастыру.