Lemidea · Yayın:
| Gözlem | Ayırmanız gereken durum | İstenecek kanıt |
|---|---|---|
| Kaynakta beş, hedefte beş satır var | Aynı kayıtlar mı; biri iki kez yazılmış olabilir mi? | Aynı kapsam için kayıt kimliği listeleri |
| Bir kayıt hedefte görünmüyor | Bilinçli eleme mi, açıklanamayan eksik mi? | Kaydın son görüldüğü adım ve varsa eleme nedeni |
| Akış devam etmiş | Hata sonraki adıma veri olarak mı aktarılmış? | İlgili düğümün On Error ayarı ve çıkışı |
| Tablo doğru, bildirim gelmedi | Veri kaydı ile bildirim ayrı mı izleniyor? | Hedef kayıt kimliği ve bildirim durumu |
| Elle başlatılan denemede hata bildirimi yok | Elle deneme ile otomatik yürütüm aynı mı sınanıyor? | Yürütüm türü ve atanan hata akışı |
| Tekrar çalıştırmak öneriliyor | Önceki işlem hedefte gerçekleşmiş olabilir mi? | Hedefte mevcut kayıt ve tekrara ilişkin kural |
Önce hangi kayıtların aktarılmasını beklediğinizi belirleyin
Aynı günün kaynak ve hedef tablolarını karşılaştırıyor olmak yeterli olmayabilir. Saat dilimi, başlangıç ve bitiş saati, filtreler ve bekleyen işlemler aynı kapsamı anlatmalı. Örneğin gün içinde hâlâ değişen bir listeyi sabah alınmış raporla karşılaştırırsanız yeni kayıtları yanlışlıkla kayıp sayabilirsiniz. İnceleme için sabit bir zaman aralığı ve kişisel bilgi içermeyen örnek kayıt kimlikleri seçin.
Her aktarım bir satırdan bir satır üretmek zorunda değildir. Bir kayıt birden fazla satıra bölünebilir, bir rapor birçok kaydı tek toplamda birleştirebilir. Önce beklenen ilişkiyi yazın. Aşağıdaki örnekte, seçilen beş kaydın her birinin hedefte tam bir kez bulunması gerekiyor. Gerçek akışınız farklıysa kontrol kuralını da değiştirin.
Beş kayıtlık örnek: sayılar tutuyor, kayıtlar tutmuyor
Bu örnek tamamen sentetiktir. Kaynak kimlikleri AKS-101, AKS-102, AKS-103, AKS-104 ve AKS-105 olsun. Hedefte ise AKS-101, AKS-102, AKS-102, AKS-104 ve AKS-105 görünsün. İki listede de beş satır var. Ancak hedefte dört farklı kimlik bulunuyor: AKS-103 eksik, AKS-102 iki kez yazılmış.
Bu karşılaştırma sorunun nereden çıktığını söylemez; araştırılacak kayıtları belirler. AKS-103 hangi adıma kadar geldi? AKS-102 ikinci kez ne zaman yazıldı? Önce bu iki soruyu yanıtlayın. Mükerrer satırı hemen silmek veya akışı topluca tekrar çalıştırmak, sorunu açıklayacak bilgiyi kaybettirebilir ya da yeni tekrarlar üretebilir.
AKS-103 bilinçli olarak elendiyse nedeni ve ilgili kuralı ayrı kaydedin. Örneğin kapsamda yalnız onaylı kayıtlar varsa henüz onaylanmamış bir kayıt hedefte beklenmez. Böyle bir kanıt yokken eksik kaydı sonradan kapsam dışı ilan etmeyin. Beklenen, aktarılmış ve gerekçesi kayıtlı istisna listeleri birbiriyle açıklanabilmeli.
Başarı durumunun yanında düğüm ayarlarına da bakın
n8n'in düğüm belgesinde Execute Once ayarının yalnız ilk öğeyi işlediği, Always Output Data ayarının ise veri dönmeyince boş bir öğe üretebildiği açıklanır. On Error seçeneği akışı durdurabilir veya hata sonrasında devam ettirebilir; hata çıkışıyla devam etme seçeneği hata bilgisini sonraki adıma taşır. Bu seçenekleri, kayıtların azaldığı adımda inceleyin.
Bu ayarlar tek başına yanlış değildir. Tek bir özet üretmek için bir kez çalışma veya beklenen bir eksikliği ayrı kola taşıma tasarımın parçası olabilir. Sorun, bu davranışın aktarılması gereken kaydı sessizce dışarıda bırakmasıdır. Bir sonraki düğüme veri gelmesini, hedef sisteme doğru kaydın yazıldığına kanıt saymayın. Hangi alanın kaynak kimliğini taşıdığını ve hedef kaydın hangi kimlikle saklandığını ayrıca kontrol edin.
Hata bildirimi ile iş sonucunu ayrı kontrol edin
n8n, başarısız yürütümlerde çalışacak ve Error Trigger ile başlayan bir hata akışı tanımlamaya izin verir. Resmî belgede, belirlediğiniz bir koşulda Stop And Error düğümüyle yürütümü başarısız kılma yolu da anlatılır. Ancak sizin için yanlış olan bir toplam, ayrıca kontrol edilmedikçe kendiliğinden teknik hata sayılmaz.
Bir ayrıntı test sonucunu değiştirebilir: n8n'in Error Trigger belgesine göre elle çalıştırılan bir akış, hata akışını sınamak için yeterli değildir; Error Trigger otomatik yürütümdeki hata üzerine çalışır. Bu yüzden yalnız editörde elle denedikten sonra bildirim gelmedi diye bağlantıyı bozuk saymayın. Önerimiz, canlı veriden ayrı bir test akışında, sentetik kayıtlarla otomatik tetiklenen kontrollü hata oluşturup hata akışının başladığını ve test bildiriminin alındığını ayrı ayrı kaydetmek. Bu denemeyi bu yazı için yapmadık.
Önerimiz, kritik aktarım sonunda beklenen kimlikleri hedefle karşılaştırmak ve açıklanamayan eksikleri ayrı bir inceleme listesine almak. Her eksikte bütün akışı durdurmak zorunlu değildir; işi kullanacak ekiple hangi durumun durduracağına, hangisinin gerekçeli istisna olacağına karar verin. Listeyi kontrol edecek kişi, kontrol sıklığı ve düzeltilmemiş kayıtların görünürlüğü belli olsun. Bu kayıt düzeni hazır bir n8n garantisi değil, akışa eklenmesi gereken iş kuralıdır.
Kaynak: n8n: hata akışları ve Stop And Error ↗n8n: Error Trigger ve elle çalıştırma sınırı ↗
Yeniden çalıştırmadan önce hedefte ne olduğunu bulun
n8n yürütüm ekranında başarısız bir çalışmayı önceki verilerle, özgün akış veya o sırada kaydedilmiş güncel akış üzerinden yeniden deneme seçenekleri vardır. Bu nedenle inceleme notuna kullanılan akış sürümünü de ekleyin. Eski veriyi değişmiş bir akışla çalıştırmak, ilk denemeyle aynı koşulları oluşturmaz.
Hedef sistem kaydı saklamış ama yanıt geri ulaşmamış olabilir. Tekrar yazmadan önce ilgili kimliğin hedefte bulunup bulunmadığını ve aynı isteğin ikinci kez gönderilmesinde ne olacağını kontrol edin. Hedef sistemin desteklediği güvenli tekrar kuralını test ortamında gösterin. Sadece hata bildirimini yeniden göndermek ile bütün aktarımı yeniden çalıştırmak farklı işlemlerdir. Özellikle ödeme, mesaj veya sipariş oluşturan adımlarda etkileri ayrı inceleyin.
Düzeltmenin kabulünü aynı örnekle yapın
İlk kabul kontrolünde beş beklenen kimliğin hedefte birer kez bulunduğunu gösterin. İkinci kontrolde, gerekçesi kaydedilmiş bir kapsam dışı kaydın gerçekten ayrıldığını gösterin. Üçüncü kontrolde beklenmeyen bir kimliği ve mükerrer kaydı kontrol listesinin yakaladığını gösterin. Sonra test ortamında aynı işlemi tekrar göndermenin hedefi nasıl etkilediğini ayrıca deneyin. Bu son adım, listeleri karşılaştırmakla test edilmiş olmaz.
Kopyalanabilir inceleme notu: Akış ve sürüm: __. Yürütüm türü (elle / otomatik): __. Zaman aralığı ve saat dilimi: __. Beklenen kayıt kimlikleri: __. Hedefte bulunan kimlikler: __. Eksik / mükerrer / kapsam dışı: __. İlk ayrışan adım: __. Değiştirilen kural: __. Tekrar deneme sonucu: __. Hata akışı başladı mı: __. Test bildirimi alındı mı: __. Kontrol edilmeyenler: __. Sorunu bu biçimde kaydetmek, yalnız ekran görüntüsünde görünen başarı işaretinden daha kullanışlı bir teslim kanıtı sağlar.
Yeni otomasyon kurmadan mevcut akışı inceletebilirsiniz
Başlangıç için akışın amacı, kullandığı programlar, bir eksik kaydın anonim kimliği ve beklenen sonuç yeterli. Canlı müşteri tablosunu veya erişim anahtarlarını ilk mesajda paylaşmanız gerekmez. İnceleme kapsamını, sorunun tekrar üretilebildiği küçük bir örnek üzerinden belirleyebiliriz. Düzeltme süresi veya kazanım, akış incelenmeden kesin söylenemez.
Aşağıdaki rapor atölyesinde kaynak ve dönem filtresini değiştirip özeti alttaki satırlarla karşılaştırabilirsiniz. Bu, raporu kaynağıyla birlikte okuma alıştırmasıdır; yazıdaki mükerrer kayıt senaryosunu çalıştıran bir n8n demosu değildir. Gerçek aktarımın kabulü için yukarıdaki kimlik kontrolü kendi test ortamınızda ayrıca yapılmalıdır.
Kaynaklar ve hazırlanış
Bu içerik yapay zekâ desteğiyle hazırlanmıştır. n8n ayarları ve hata bildirimi açıklamaları dört resmî belgeyle karşılaştırılmıştır. Beş kayıtlık sentetik örnek için beş kimlik kontrolü ve rapor demosunun altı filtre kontrolü yerel olarak çalıştırılmıştır. Gerçek n8n kurulumu, CRM bağlantısı veya bildirim gönderimi test edilmemiştir. İnceleme sırası ve kabul listesi Lemidea'nın önerisidir; insan editör kontrolü iddia edilmez.
Araç özellikleri ve sağlayıcı koşulları değişebilir. Kaynak kontrolü: .
Kontrol, sentetik kimlik karşılaştırmalarını ve rapor demosunun filtre hesabını kapsar. Error Trigger'ın elle çalıştırma sınırı resmî belgede doğrulandı; çalışan n8n üzerinde denenmedi. Gerçek yeniden deneme, CRM'ye kalıcı kayıt, otomatik yürütüm ve bildirim teslimi test edilmedi.
