Шартты мысал: интернет-дүкен тапсырысты жұмыс жүйесіне жіберді. Жауап уақытында келмеді. Қызметкер қайталауды басты, менеджер екі тапсырыс көрді. Желі бір рет істен шықты, жұмыс екі есе көбейді.
Бұл міндетті түрде CRM-ді, яғни клиенттермен қарым-қатынасты басқару жүйесін ауыстыруды талап етпейді. Алдымен интеграцияның — бағдарламалар арасындағы дерек алмасудың — әрекетін тексеріңіз. «Қайталау» қызметкердің жадынан жаңа тапсырыс жасау емес, бір операцияны жалғастыруды білдіруі керек.
Күту уақытының асуы не болғанын айтпайды
Күту уақыты біткенде жіберуші бір ғана нәрсені біледі: түсінікті жауап алған жоқ. Сұрау жетпеуі, орындалуы немесе әлі өңделіп жатуы мүмкін.
Қайта жазар алдында бастапқы операцияның тұрақты идентификаторы бойынша нақты нәтижені іздеңіз. Клиент аты мен сома жеткіліксіз: бір адам екі бірдей тапсырыс бере алады. Бірақ бір сұраудың екі жеткізілуі екі тапсырыс жасамауы керек.
Бастапқы тапсырыс нөмірін, нақты оқиға идентификаторын және өзгеріс нұсқасын ажыратыңыз. Бір карточка талай рет өзгеруі мүмкін. Оның нөмірі бардың бәрін қайталану деп санасаңыз, заңды жаңартулар жоғала бастайды.
Қауіпсіз қайталау нені білдіреді
Пайдалы қағида идемпотенттілік деп аталады: сол әрекетті қайталау екінші бизнес-нәтиже тудырмайды. Бұл — алмасуды іске асыру талабы, Битрикс24-тің әмбебап қосқышы емес.
Орындаушы операция кілті қайда сақталатынын, нәтиже қалай тіркелетінін және бірдей сұраулар қатар келсе не болатынын түсіндіруі керек. «Алдымен іздеу, кейін құру» жеткіліксіз болуы мүмкін: екі өңдегіш те бір уақытта ештеңе таппай үлгереді.
Құру операциясында бастапқы тапсырыс пен алынған карточка арасындағы байланысты сақтаңыз. Жаңартуда жаңа мәліметті кешіккен нұсқадан қалай ажырататыныңызды келісіңіз. Қайталау расталған күйді кері қайтармауы тиіс.
Кезектің де ережесі бар
Битрикс24 ресми құжаттамасы сәтті жауаптан бұрын кіріс оқиғаны сенімді сақтап, ауыр өңдеуді бөлек орындауды ұсынады. Онда өңдегіш апаттық жауап қайтарса, кәдімгі Битрикс24 оқиғасы қайта жіберілмейтіні де көрсетілген. Қалпына келтіруді «платформа тағы жібереді» деген болжамға құрмаңыз.
Ал интеграцияның өз кезегі ақаудан кейін өңдеуді қайталай алады. Дәл осы жерде нәтижені екі рет құрмау маңызды. Әрекет саны, кідірістер, тұрақты қатені өңдеу және жауаптыға хабарлау алдын ала анықталуы керек.
Қате мәліметі немесе жеткіліксіз құқығы бар сұрауды шексіз қайталамаңыз. Алдымен себепті түзеп, күйін тексеріп, қай операцияны жалғастыруды шешіңіз.
Үш қолайсыз сәтті тексеріңіз
- Қабылдаушы тапсырысты сақтады, жауап жоғалды: қайталау бар нәтижені табады.
- Екі өңдегіш бір операцияны қатар алды: бір тапсырыс пайда болады.
- Ескі өзгеріс жаңасынан кейін келді: өзекті дерек өшірілмейді.
Оқу жазбаларын пайдаланып, сынаудың қауіпсіз шарттарын келісіңіз. Журнал операцияны, уақытты, әрекет нөмірін және нәтижені табуға көмектессін. Құпиясөздер, токендер мен артық клиент мәліметін жарияламаңыз.
Өзгерісті қалай талқылауға болады
Бір тарап Битрикс24 болса, REST API-дің — бағдарламалық алмасу интерфейсінің — қолжетімділігін және қажетті құқықтарды порталыңыздың шарттары бойынша тексеріңіз. Екінші бағдарламаны бөлек тексеру қажет. Екі API-дің болуы қайталаудан қорғамайды.
Қырғызстандағы бизнес үшін бір қайталанатын жағдайдан бастаңыз: бастапқы операция, нөмірі және екі жүйедегі нақты нәтиже. QQDev REST API әзірлеу бетінде алмасудың қайталау ережелері мен журналын талқылауға болады. Бір батырма үшін жұмыс істеп тұрған жүйені алдын ала ауыстыру қажет емес.