Make eyni sifarişi iki dəfə yaradır: necə yoxlamalı?

Make eyni sifarişi iki dəfə yaradırsa, bir sifarişin mənbə nömrəsini hədəf qeydlə müqayisə edin. Sabit açar, ardıcıl icra və nəticəyə əsaslanan bərpa qaydası qurun; bir parametrin bütün təkrarları dayandırdığını fərz etməyin.

Make eyni sifarişi iki dəfə niyə yaradır?

Make eyni sifarişi iki dəfə yaradırsa, əvvəl təkrarın hansı mərhələdə başladığını tapın. Make tətbiqləri birləşdirən avtomatlaşdırma alətidir. Ssenari bu tətbiqlər arasında qurduğunuz iş axınıdır. Problem təkcə son modulda olmaya bilər: mənbə eyni məlumatı yenidən göndərə, iki ssenari eyni sifarişə baxa və ya xəta sonrası cəhd artıq görülmüş işi təkrarlaya bilər.

Şərti nümunə: Bakıdakı onlayn mağaza yeni sifarişi müştəri idarəetmə sisteminə yazır. Eyni sifariş bildirişi iki dəfə gəlir və sistemdə iki qeyd görünür. Bu nümunə real mağaza haqqında fakt deyil. Məqsəd sifarişin özü ilə həmin sifariş barədə gələn bildirişin fərqini göstərməkdir.

Təkrar sifariş, təkrar email və təkrar stok əməliyyatı ayrı nəticələrdir. Birini dayandırmaq digərinin dayandığını göstərmir. Sifarişdən çatdırılmaya əməliyyat axınında hansı addımların ayrıca təsiri olduğunu qeyd edin. Müştərinin həqiqətən iki fərqli sifarişi varsa, onları birləşdirmək də səhvdir.

İlk addım yeni avtomatlaşdırma qurmaq deyil, bir sifarişin izini mənbədən son sistemə qədər izləməkdir. Ssenarinin yaşıl görünməsi biznes nəticəsinin bir dəfə yarandığına zəmanət deyil. Yoxlamanı real sifariş nömrəsinə bağlayın.

Bir sifarişin izini bu cədvəllə yoxlayın

Problemli sifarişin mənbə nömrəsini seçin. Make icralarında hansı məlumatın neçə dəfə gəldiyinə, sonra hədəf sistemdə hansı qeydlərin yarandığına baxın. Hədəf sistem məlumatın yazıldığı tətbiqdir. Sadəcə icra sayını müqayisə etmək kifayət deyil: bir icra bir neçə nəticə yarada bilər.

Xəta görünən icrada xarici tətbiqdə nəticənin yaranmadığını fərz etməyin. Məlumat yazılmış, amma cavab Make-ə çatmamış ola bilər. Bu halda bütün axını yenidən başlatmaq təkrar sifariş və ya bildiriş yarada bilər. Bu, xarici sistemlərlə işdə nəzərə alınmalı texniki ehtimaldır, konkret modulun hər xətada belə davranması iddiası deyil.

Komanda “təkrar” sözünü eyni mənada istifadə etsin. Müştərinin yeni sifarişi, əvvəlki sifarişin status dəyişikliyi və eyni bildirişin yenidən gəlməsi fərqlidir. Hər biri üçün hansı nəticənin gözləndiyini yazın. İşləməyən avtomatlaşdırmanı yoxlamaq daha geniş diaqnostika mövzusudur.

Sabit sifariş açarı seçin

Təkrar yoxlaması üçün sabit açar lazımdır. Açar eyni işi yenidən tanımaq üçün istifadə olunan identifikatordur. Mənbə sistemin sifariş nömrəsi yaxşı başlanğıcdır; bir neçə mağaza varsa, mağazanı da həmin açara daxil edin. Məsələn, “magaza-a:sifaris-123:yeni-qeyd” müəllifin təklif etdiyi sadə quruluşdur, Make-in məcburi formatı deyil.

Hər yeni cəhddə təsadüfi nömrə yaratmaq eyni sifarişi tanımağa kömək etmir. Müştərinin emaili də təkbaşına uyğun açar deyil: eyni şəxs bir neçə düzgün sifariş verə bilər. Məbləğ və tarixdən qurulan açar isə müxtəlif sifarişləri səhvən birləşdirə bilər. Əsas mənbə nömrəsini qoruyun.

Yeni sifariş yaratmaqla sifarişin statusunu yeniləmək üçün eyni “bir dəfə gör” qaydasından istifadə etməyin. Əks halda sonrakı düzgün status dəyişikliyi bloklana bilər. Nəyi təkrarsız etmək istədiyinizi seçin: sifariş qeydi, müəyyən bildiriş və ya konkret əməliyyat. Bu ayrım idempotentlik prinsipidir: eyni iş yenidən gəlsə də əlavə biznes nəticəsi yaratmamaq.

Açarın harada saxlandığını və hədəf qeydlə necə əlaqələndiyini yazın. CRM sistemində mənbə sifariş nömrəsinin görünməsi araşdırmanı asanlaşdıra bilər. CRM müştəri münasibətlərini idarə edən sistemdir. Mövcud qeydlərin üzərinə kütləvi dəyişiklik etməzdən əvvəl ayrıca plan və yoxlama lazımdır.

Data Store nəyi saxlamalıdır?

Make Data Store icralar arasında məlumat saxlamaq üçün sadə məlumat anbarıdır. Check the Existence of a Record açarın olub-olmadığını yoxlayır. Add/Replace a Record açarla qeyd əlavə edir; mövcud qeydin üzərinə yazma söndürülübsə, eyni açarı əlavə etmək xəta verir. Bu davranış Data Store sənədində izah olunur.

“Açar var” ilə “sifariş uğurla yaradılıb” eyni məlumat deyil. Komanda üçün “iş başlanıb”, “hədəf qeyd təsdiqlənib” və “nəticə bilinmir” kimi vəziyyətləri ayrı saxlamaq faydalıdır. Bunlar təklif olunan qeyd qaydalarıdır, Make-in hazır sifariş vəziyyətləri deyil. Hədəf tətbiqin verdiyi qeyd nömrəsini də uyğun yerdə saxlayın.

İş başlamazdan əvvəl qeyd yazıb sonra onu avtomatik “tamamlandı” saymaq düzgün deyil. Xarici addım uğursuz ola bilər. Əksinə, yalnız xarici nəticədən sonra açar yazsanız, həmin iki addım arasında xəta yarana bilər. Ona görə Data Store ilə hədəf tətbiqin yazısı vahid, bölünməz əməliyyat kimi təqdim olunmamalıdır.

Sadə “yoxla, yoxdursa yarat” axını eyni vaxtda işləyən iki icrada yarış yarada bilər. Hər ikisi hələ qeyd olmadığını görə bilər. Data Store modullarının adları bu riski avtomatik həll etmir. Bir neçə ssenari eyni işi yazırsa, hədəf sistemdə sabit mənbə açarına uyğun unikal yazma qaydasını da texniki məsul şəxslə yoxlayın.

Ardıcıl icra təkrarı tam aradan qaldırır?

Webhook tətbiqin Make-ə yeni məlumat göndərdiyi çağırışdır. Make sənədinə görə ani webhook ssenariləri standart halda paralel işləyir. Ssenari parametrlərində Process data in order seçildikdə əvvəlki icranın bitməsi gözlənilir. Bu parametr həmin axında eyni vaxtda icra riskini azaltmaq üçün nəzərdən keçirilə bilər. Mənbə Make webhook sənədidir.

Ardıcıl icra eyni sifarişin sabah yenidən gəlməsini dayandırmır. O, başqa ssenaridən və ya başqa tətbiqdən eyni nəticənin yazılmasını da avtomatik bloklamır. Yavaş addım varsa, növbəti işlər gözləyə bilər. Parametrin faydasını və gecikmə təsirini sınaqda yoxlayın.

Sifariş qeydini yaratmaq üçün bir əsas axın müəyyən edin. İşin Make, başqa avtomatlaşdırma və əl əməliyyatı arasında paylaşılması əlavə təkrar riski yarada bilər. Sistemin bütün yazma yollarını sadalayın. Make, n8n və Zapier müqayisəsi alət seçimi üçündür; eyni sifarişi bir neçə alətdən paralel yazmaq problemi həmin müqayisə ilə həll olunmur.

Məqsəd “bir parametr açdıq, problem bitdi” deyil. Sabit açar, sifariş qeydini yaradan məsul axın, hədəf nəticə və bərpa qaydası birlikdə yoxlanmalıdır. Ödəniş və stok kimi həssas nəticələrdə bu planı texniki məsul şəxsə verin. Məqalə canlı sistemə hazır tətbiq ssenarisi deyil.

Xəta sonrası cəhddən əvvəl nəticəni yoxlayın

Make-də Store incomplete executions aktivdirsə, yarımçıq icralar saxlanıla bilər. Funksiya standart halda söndürülüdür. Dəstəklənən xəta növləri və ya Retry error handler ilə avtomatik cəhd, həmçinin əl ilə həll imkanları var. Detallar yarımçıq icralar sənədində verilir.

Yenidən cəhddən əvvəl hədəf sistemə baxın. Sifariş artıq yaranıbsa, məqsəd onu bir daha yaratmaq deyil, çatışmayan addımı müəyyən etməkdir. Nəticə bilinmirsə, icranı “tamamlandı” və ya “uğursuz” kimi kor-koranə bağlamayın. Məsul şəxs hədəf qeyd və əvvəlki cəhdi əlaqələndirsin.

Təkrar riski aradan qalxsın deyə saxlanmış açarları silmək düzgün başlanğıc deyil. Bu, əvvəl görülmüş işi yeni iş kimi göstərə bilər. Eyni səbəbdən bütün xəta növlərini təkrar sifariş sayıb səssiz keçmək olmaz. Saxlama limiti və bağlantı problemi də ola bilər. Xətanın səbəbini ayırın.

Müştəriyə email göndərilməsi ayrıca nəticədir. Sifariş bir dəfə yaransa da, bütün axın yenidən işlədiləndə email yenidən gedə bilər. Email avtomatlaşdırmasını sifariş yazısı ilə eyni “uğurlu” işarəyə bağlamadan əvvəl hər addımın bərpasını planlayın.

Təhlükəsiz sınaq və gündəlik nəzarət qurun

Real sifariş əvəzinə test məlumatı ilə başlayın. Eyni mənbə nömrəsini iki dəfə göndərin, iki fərqli sifarişin düzgün keçdiyini də yoxlayın. Status dəyişikliyinin yeni sifariş kimi yazılmadığına baxın. Xəta sonrası nəticənin bilinmədiyi halı ayrıca sınaqdan keçirin.

• Eyni sifariş və eyni əməliyyat iki dəfə gələndə əlavə qeyd yaranmır?
• Eyni müştərinin iki fərqli sifarişi ayrı saxlanılır?
• Status yeniləməsi səhvən bloklanmır?
• İlk nəticə yaranıb cavab gecikəndə bərpa qaydası aydındır?
• Təkrar email və stok nəticəsi ayrıca yoxlanır?
• Yarımçıq işi görəcək məsul şəxs məlumdur?

Bu siyahı təklif olunan qəbul meyarıdır, artıq keçirilmiş test nəticəsi deyil. Öz sisteminizdə faktiki nəticəni yazın. Bir nümunənin uğuru bütün mümkün cəhdlər üçün zəmanət vermir. Yeni yazma yolu və ya modul əlavə edildikdə yoxlamanı yeniləyin.

Biznes proseslərini avtomatlaşdırarkən yalnız uğurlu icraları yox, yarımçıq işləri də izləyin. Hədəf sifariş sayı ilə mənbə sifariş sayını uyğun meyarla müqayisə edin. Dəyişiklikdən sonra təkrar yoxdursa, bunu öz sübutunuzla deyin; alətin adından nəticə çıxarmayın.