Otomasyon kesintiden sonra nasıl devam eder: durumun sahibi kim?

Konnektör sayısı, yeniden başlatmadan sağ çıkan bir iş akışı hakkında pek az şey söyler. Asıl soru, dış işlem gerçekleşmiş olabileceği halde onayı kaybolduğunda ne yapılacağıdır. Platform yürütme yolunu hatırlayabilir; bu, yetkili iş sonucunu bildiği anlamına gelmez.

Ekim ayındaki dört yayın bu ayrımı görünür kılıyor. Satın alma ve mimari kararı için yararlı ölçüt şu: teslimatın, yürütme geçmişinin ve dış sonucun doğrulanmasının sahibini baştan belirleyin.

Dört yayının farklı sorumlulukları

Microsoft’un 12 Ekim Durable Task yazısı kalıcı koordinasyon ile uygulamanın uzlaştırması gereken dış etkileri ayırıyor. 8 Ekim Temporal 1.32.1 sürümü görev yönlendirme düzeltmeleri içeriyor.

n8n’in 12 Ekim karşılaştırması araçların sorumluluk alanlarını ayırıyor. Workato’nun 13 Ekim konferans raporu yeniden kullanılabilir entegrasyon katmanlarını anlatıyor. Bu bir üretici anlatımıdır, bağımsız ürün üstünlüğü testi değildir.

Mimari çıkarımımız açık: taşıma katmanı işi ulaştırır, yürütücü ilerlemeyi kaydeder, iş kaydı ise kabul edilmiş sonucu belirler. Bir sınırdaki garanti diğerine kendiliğinden geçmez.

Bir talebin birden fazla durumu vardır

Müşteri açılış talebinin iş durumu, onaylanıp onaylanmadığını ve kimin değiştirebileceğini içerir. Yürütmenin teknik durumu, başlayan adımları ve beklemeleri tutar. Dış sağlayıcıda ise hesabın gerçekten oluşup oluşmadığı kayıtlıdır.

Bu durumlar ayrışabilir. Sağlayıcı hesabı oluşturur, çalışan yanıtı kaybeder. İşlemi yeni kimlikle tekrarlamak mükerrer hesap yaratabilir. Talebi başarısız işaretlemek de hesap zaten varken yanıltıcıdır.

Sabit işlem kimliği ve değişmeyen içerik bu belirsizliği çözmeye yardım eder. Sonuç bilinmiyorsa önce önceki işlemin akıbeti araştırılır. Güvenli tekrarın mümkün olup olmadığı gerçek API sözleşmesine bağlıdır.

Onaylar için de aynı özen gerekir. “Onaylandı” bildirimi gecikebilir veya iki kez gelebilir. Devam etmeye yetki veren şey, ilgili sürüme ait kalıcı karardır. Mesaj yalnızca değişiklik olabileceğini haber verir.

Varsayımsal iş ortağı açılışı

Bir yönetici CRM talebi açıyor, üst yönetici onaylıyor, dış sistem hesap oluşturuyor ve çalışan doğrulama görevi alıyor olsun. Bu bir tasarım örneğidir; müşteri sonucu veya ürün uyumluluğu iddiası değildir.

Talebe kalıcı anahtar atayın. Onayı, onaylanan bilgilerin sürümüyle saklayın. Eski banka veya iletişim bilgilerine verilen onay, değiştirilmiş verileri göndermeye yetki vermemelidir. Hesap oluşturma isteği yaşamı boyunca aynı işlem kimliğini kullanır.

Bağlantı gönderimden hemen sonra kesilsin. Güvenli sonraki adım sağlayıcıya göre değişir: işlem anahtarıyla sorgulama, kaydedilmiş dış kimliği araştırma veya operatöre yönlendirme. Körlemesine yeniden gönderim ancak API ve iş kuralları izin veriyorsa uygundur.

Son çalışan görevine de sabit kimlik verin. Aksi halde toparlanma birden çok görev yaratır ve iki kişi aynı işi yapabilir. Tamamlanma, zorunlu kayıtların birbiriyle uyuşmasıdır; başarılı çalışan kaydı tek başına yetmez.

Arayüz “onay bekliyor”, “sağlayıcı sonucu belirsiz” ve “operatör gerekli” durumlarını ayırmalıdır. Hepsini aynı kırmızı hata olarak göstermek, zaten yapılmış işi yeniden başlatmaya teşvik eder. Durum adları toparlanma tasarımının parçasıdır.

Ayrı motor ne zaman değer katar?

Veritabanı, kuyruk ve birkaç işleyiciyle güvenilir çalışan kısa akış başka bir çalışma ortamından yarar görmeyebilir. Uzun beklemeler, bağımsız dallar ve insan kararları arttıkça özel devam protokolünü sürdürmek pahalılaşır. Ayrı koordinasyon motorunu o noktada değerlendirin.

Yürütücünün güncellenmesi, geçmişin saklanması ve eski akışların yeni kodla uyumu maliyete dahildir. Kabul testi bekleme sırasında yeniden başlatmayı, kayıp onayı ve yinelenen olayı kapsamalı; CRM ile sağlayıcıdaki son kayıtları doğrulamalıdır.

Arka plan çalışanları ve tekrarlar mekanizmayı ayrıntılandırıyor. AmoCRM proje taslağı ilgili bağlamı sunuyor. İş akışı otomasyonu planı, toparlanma kuralları ve nihai sonuç sahibinden başlayabilir.