"AI otomasyon" hakkında yazılan çoğu içerik soyut kalır — akış şeması genel geçer, node isimleri kurgusaldır. Bu yazıda tam tersini yapıyoruz: kendi kurduğumuz bir sistemin gerçek node yapısını, gerçek alan adlarını ve gerçek bağlantılarını gösteriyoruz. Müşteri verisi ve kimlik bilgileri kaldırıldı; geri kalan her şey export edilen workflow JSON'larından birebir alındı.
Bu Otomasyon Hangi Problemi Çözüyor?
Bir ürün kataloğunu birden fazla arayüzden (bir yönetim paneli, bir sohbet arayüzü, ileride bir mobil uygulama) tutarlı şekilde yönetmek isterseniz, tek bir veri kaynağına ve o kaynağa yazan/okuyan standart uç noktalara ihtiyacınız olur. Bu sistemde o uç noktalar iki ayrı n8n workflow'u olarak kuruldu; veri kaynağı ise bir Google Sheets tablosu.
Sistemin Genel Mimarisi
Sistem üç ayrı n8n workflow'undan oluşuyor:
- Products Read Workflow — ürün listesini okur.
- Products Write Workflow — ürün ekleme, güncelleme, stok değiştirme ve silme işlemlerini yürütür.
- AdminPanel Serve Workflow — yönetim panelinin HTML arayüzünü sunar.
Üçü de aynı Google Sheets tablosundaki Ürünler sayfasını kullanıyor; her ürün satırında product_id, product_name, category, skin_type, concern, ingredients, texture, usage_time, usage_order, price, url, stock, warning, variant_id alanları bulunuyor. Bu, temsili bir kozmetik ürün seti — gerçek müşteri verisi değil.
Ürün Verilerini Okuma Akışı
Okuma tarafı üç node'dan oluşuyor: Webhook (POST /products-read) isteği karşılıyor, Get All Products Google Sheets node'u tabloyu okuyor, Respond node'u sonucu JSON olarak döndürüyor.
Burada teknik olarak dürüst olunması gereken bir nokta var: Respond to Webhook node'u responseBody: {{ $json }} ayarıyla çalışıyor ve aralarında bir birleştirme (Aggregate) node'u yok. n8n'de Respond to Webhook, kendisine ulaşan ilk item'ı yanıt olarak döndürür. Yani bu haliyle akış, node adı "Get All Products" olsa da, pratikte yalnızca ilk satırı döndürür — tüm listeyi döndürmek isteniyorsa araya bir Aggregate node eklenmesi gerekir. Bunu bir eksiklik olarak değil, mevcut sistemin gerçek davranışı olarak belirtiyoruz.
Switch Node ile İşlem Yönlendirme
Yazma tarafı, gelen isteğin gövdesindeki action alanına bakan bir Switch node ile başlıyor: {{ $json.body.action }}. Bu node dört çıkışa sahip: add, update, update_stock, delete. Önemli olan şu: bu bir yapay zeka sınıflandırması değil — gelen metni "anlayan" bir sistem yok. Switch node yalnızca gelen değeri önceden tanımlı dört string ile birebir karşılaştırıyor ve eşleşen dala yönlendiriyor.
Ürün Ekleme, Güncelleme, Stok Değiştirme ve Silme
Switch node'un dört çıkışı, dört ayrı Google Sheets node'una bağlanıyor:
| action değeri | Node | Google Sheets işlemi |
|---|---|---|
add | Add Product | append (yeni satır ekler) |
update | Update Product | update (tüm ürün alanlarını günceller) |
update_stock | Update Stock | update, yalnızca stock alanı, product_id ile eşleştirilir |
delete | Delete Product | delete, product_id filtresiyle satırı siler |
update_stock dalının özellikle diğerlerinden farkı: tüm ürün nesnesini değil, yalnızca product_id ve stock alanlarını alıyor — bu, stok değişikliklerinin ürünün geri kalan bilgilerini yanlışlıkla ezmemesi için kasıtlı bir tasarım.
Admin Panel Bağlantısı
Admin panel arayüzü ayrı bir webhook üzerinden sunulur: AdminPanel Serve Workflow, gelen isteğe yalnızca HTML içeriğiyle yanıt veren bir Webhook → Respond çiftinden ibarettir; kendisi hiçbir veri işlemi yapmaz.
Panel tarayıcıda yüklendikten sonra JavaScript ile doğrudan /products-read ve /products-write uç noktalarına fetch() istekleri gönderiyor — bunu panel HTML dosyasındaki istek adreslerinden doğruladık. Yani panel arayüzü ile CRUD mantığı iki farklı katman: biri arayüzü sunuyor, diğer ikisi (read/write workflow'ları) gerçek veri işlemini yürütüyor.
HTTP Yanıtları ve İşlem Sonuçları
Dört işlem dalının tamamı — ekleme, güncelleme, stok değiştirme, silme — aynı Respond OK node'una bağlanıyor. Bu node, işlemin türünü de içeren sabit bir JSON döndürüyor: {"success": true, "action": "..."} ve HTTP 200 kodu.
Okuma:
Webhook (POST /products-read)
↓
Get All Products (Google Sheets)
↓
Respond (JSON — yalnızca ilk item)
Yazma:
Webhook (POST /products-write)
↓
Switch — body.action
├─ add → Add Product (append)
├─ update → Update Product (update)
├─ update_stock → Update Stock (update, stock alanı)
└─ delete → Delete Product (delete)
↓
Respond OK (JSON, HTTP 200)Burada da önemli bir sınır var: Respond node'u yalnızca "işlem tetiklendi ve bir hata fırlatmadı" bilgisini döndürüyor; kendi başına bir hata yönetimi mekanizması değil. Google Sheets işlemi başarısız olursa, n8n'in kendi hata davranışı devreye girer — akışın içinde ayrı bir hata dalı tanımlı değil.
Üretim Ortamında Doğrulama, Güvenlik ve Hata Yönetimi
Mevcut sistem ile üretim ortamı için önerilen geliştirmeleri birbirine karıştırmamak gerekiyor:
- Mevcut akışta olan: webhook ile istek karşılama, action alanına göre koşullu yönlendirme, Google Sheets CRUD işlemleri, sabit JSON yanıtı.
- Üretim için önerilen (bu sistemde şu an yok): gelen verinin şema doğrulaması, kimlik/yetki kontrolü, başarısız işlemler için ayrı hata dalları, işlem loglaması ve geçici hatalarda tekrar deneme (retry) mekanizması.
Bir prototipi üretime taşırken bu ayrımı netleştirmek, "çalışıyor" ile "güvenilir" arasındaki farkı görmek açısından önemli.
Aynı Mimarinin CRM, Randevu ve Sipariş Süreçlerine Uyarlanması
Buradaki desen ürüne özgü değil: webhook ile isteği karşılama, bir alana göre işlem türünü ayırma (Switch), ilgili veri kaynağına yazma ve tek bir noktadan yanıt döndürme. Aynı iskelet; müşteri kaydı güncelleme, randevu oluşturma/iptal etme veya sipariş durumu değiştirme gibi kayıt bazlı birçok süreçte aynı şekilde kurulabilir. Değişen şey veri kaynağı ve alan isimleri, mimari değil.
İşletmenizde ürün, stok veya farklı sistemler arasında manuel veri aktarımı yapılıyorsa, bu süreci n8n ile nasıl otomatikleştirebileceğimizi birlikte inceleyebiliriz — bkz. n8n danışmanlığı sayfamız. Daha geniş resim için AI otomasyon hizmetlerimize de göz atabilirsiniz.