Web sitesinin yayına açılması teknik işin bittiği anlamına gelmez. Özellikle site; ERP, Netsis, e-ticaret altyapısı, stok sistemi, CRM, ödeme servisi veya başka bir iş uygulamasıyla veri alışverişi yapıyorsa asıl kritik dönem canlı kullanım başladıktan sonra ortaya çıkar.
Siparişin web sitesinden ERP’ye aktarılması ilk bakışta basit görünebilir. Fakat sipariş satırındaki ürünün hangi stok koduyla eşleşeceği, fiyatın hangi sistemden alınacağı, iptal edilen siparişin nasıl işleneceği, aynı kaydın iki kez gönderilmesinin nasıl engelleneceği ve aktarım başarısız olduğunda kimin haberdar olacağı belirlenmemişse çalışan bir bağlantı kısa sürede operasyon sorununa dönüşebilir.
Bu nedenle yayın sonrasındaki kontrolleri yalnızca “site açılıyor mu?” seviyesinde bırakmamak gerekir.
Önce veri akışının gerçekten çalıştığı doğrulanmalı
Entegrasyon projelerinde test ortamında başarılı olan bir işlem, canlı sistemde farklı davranabilir. Canlıdaki ürün kodları, müşteri kayıtları, yetkiler, ağ kuralları veya gerçek veri hacmi test ortamından farklı olabilir.
İlk kontroller gerçek iş akışları üzerinden yapılmalıdır. Örneğin bir e-ticaret ve ERP entegrasyonunda şu zincir baştan sona izlenebilir:
Sipariş oluşturuldu → ödeme bilgisi alındı → müşteri eşleştirildi → stok kodları bulundu → sipariş ERP’ye aktarıldı → stok güncellendi → işlem sonucu web sistemine döndü.
Burada yalnızca kaydın hedef sisteme ulaşması yeterli değildir. Alanların doğru karşılıklarla işlendiği de kontrol edilmelidir.
Web sitesindeki SKU-1458 kodunun Netsis tarafında başka bir stok koduna karşılık geldiği bir yapıda bu eşleşme açık biçimde tanımlanmazsa entegrasyon teknik olarak çalışırken yanlış üründe hareket oluşturabilir.
Netsis kullanılan projelerde hangi verinin hangi tablo veya modülle ilişkili olduğunun bilinmesi bu nedenle kritiktir. Piasoft’un Netsis tabloları ve açıklamaları rehberi, stok, cari, fatura ve entegrasyon gibi alanlarda çalışan ekipler için veri yapısını incelerken kullanılabilecek bir referanstır.
Verinin sahibi belirlenmeli
Entegrasyonlarda sık karşılaşılan sorunlardan biri aynı bilginin birden fazla sistemde değiştirilebilir olmasıdır.
Ürün fiyatı ERP’den web sitesine gönderiliyor ancak e-ticaret panelinden de değiştirilebiliyorsa bir süre sonra hangi fiyatın geçerli olduğu belirsizleşir. Benzer durum stok, müşteri adresi, cari bakiye, ürün açıklaması ve sipariş durumu için de yaşanabilir.
Her veri grubu için bir ana kaynak belirlemek gerekir.
Örneğin bir projede yapı şöyle kurulabilir:
-
Stok miktarı ve ürün kodu ERP tarafından yönetilir.
-
Ürün görselleri ve SEO metinleri e-ticaret sisteminde tutulur.
-
Sipariş web sitesinde oluşur ve ERP’ye aktarılır.
-
Fatura veya sevkiyat durumu ERP’den web sitesine geri gönderilir.
Bu dağılım her işletmede aynı olmak zorunda değildir. Kritik olan, hangi alan üzerinde hangi sistemin son sözü söylediğinin proje başında tanımlanmasıdır.
Aksi durumda entegrasyon yazılımı veri taşır, fakat işletme aynı verinin farklı sürümleriyle uğraşmaya başlar.
Eşleştirmeler canlı veriyle kontrol edilmeli
ERP ve web sistemleri çoğu zaman aynı kavramı farklı biçimde saklar.
Web sitesinde “İstanbul” olarak geçen bir değer ERP’de 34, başka bir sistemde IST olabilir. Ürün varyantları renk ve beden üzerinden tutulurken ERP tarafında her kombinasyon ayrı stok kodu olabilir. Müşteri web sitesinde e-posta adresiyle tanınırken ERP’de cari kod üzerinden izlenebilir.
Bu farklar için açık eşleştirme kuralları gerekir.
Özellikle şu alanlar kontrol edilmelidir:
stok kodları, cari kodlar, depo kodları, fiyat listeleri, para birimleri, vergi oranları, ödeme tipleri, kargo yöntemleri, sipariş durumları ve varyantlar.
Eşleşmeyen bir kaydın ne olacağı da önceden belirlenmelidir. Sistem kaydı reddedebilir, varsayılan bir değere yönlendirebilir veya müdahale edilmesi için hata kuyruğuna bırakabilir.
Sessizce yanlış değer kullanmak en riskli seçenektir.
Aynı kayıt ikinci kez işlenmemeli
Bağlantının kısa süreli kesilmesi olağan bir durumdur. Sorun, sistem yeniden denediğinde aynı siparişin ikinci kez ERP’ye aktarılmasıdır.
Bu nedenle entegrasyonun tekrar eden isteği tanıyabilmesi gerekir. Sipariş numarası, benzersiz işlem kimliği veya sistemler arasında ortak kullanılan başka bir anahtar bunun için kullanılabilir.
Örneğin ERP’ye gönderilen WEB-2026-00841 numaralı sipariş için bağlantı sırasında cevap alınamadığını düşünelim. Web sistemi işlemin başarısız olduğunu varsayıp siparişi yeniden gönderirse ERP tarafında önce aynı işlem kimliğinin daha önce kaydedilip kaydedilmediği kontrol edilmelidir.
Aksi halde tek müşteri siparişi iki satış kaydına dönüşebilir. Teknik tarafta birkaç saniyelik bağlantı sorunu, operasyon tarafında stok, sevkiyat ve muhasebe düzeltmesi çıkarır.
Hata yönetimi “bir şey ters giderse bakarız” şeklinde bırakılamaz
Entegrasyonun sağlıklı çalıştığı kadar hata verdiğinde nasıl davrandığı da önemlidir.
Bir servis geçici olarak yanıt vermeyebilir. ERP bakımda olabilir. API isteği zaman aşımına uğrayabilir. Zorunlu bir alan boş gelebilir. Bir stok kodunun karşılığı bulunamayabilir.
Bunların tamamını aynı tür hata gibi ele almak doğru değildir.
Geçici bağlantı sorunlarında kontrollü yeniden deneme yapılabilir. Veri hatalarında ise aynı kaydı sürekli göndermek çözüm üretmez. Hatalı veri ayrılmalı ve ilgili ekip tarafından düzeltilebilmelidir.
İyi tasarlanmış bir hata kaydı en azından şu soruların cevabını verebilmelidir:
Hangi işlem başarısız oldu? Ne zaman oldu? Hangi sistemden geldi? Hangi kayıt etkilendi? Hata mesajı neydi? Kaç kez tekrar denendi? Daha sonra başarıyla işlendi mi?
“Entegrasyon çalışmıyor” şeklindeki bir bildirim teknik ekip için yeterli bilgi değildir. İnsanlığın yüzyıllardır geliştirdiği kayıt tutma fikri burada da şaşırtıcı biçimde işe yarar.
Log tutmak yetmez, kayıtlar kullanılabilir olmalı
Bir sistem binlerce satır log üretebilir ve yine de hiçbir sorunu açıklayamayabilir.
İzlenebilirlik için işlemler arasında ilişki kurulması gerekir. Web sitesindeki sipariş numarasıyla ERP kaydına, API isteğine ve alınan cevaba ulaşılabiliyorsa sorun araştırmak ciddi biçimde kolaylaşır.
Loglarda şifre, erişim anahtarı, kart bilgisi veya gereksiz kişisel veri tutulmaması da gerekir. Teknik kayıt ihtiyacı güvenlik kurallarını ortadan kaldırmaz.
Kritik entegrasyonlarda hata oranı, bekleyen kayıt sayısı veya son başarılı aktarım zamanı gibi göstergelerin ayrıca izlenmesi faydalıdır. Sistem tamamen durmadan önce bozulmanın fark edilmesini sağlar.
Entegrasyon hesabına gereğinden fazla yetki verilmemeli
ERP bağlantısı için oluşturulan servis kullanıcısının yönetici yetkisine sahip olması kolay bir çözümdür. Aynı zamanda gereksiz bir risktir.
Bir entegrasyon yalnızca stok okuyor ve sipariş oluşturuyorsa kullanıcıya muhasebe kayıtlarını silme, personel bilgilerini görüntüleme veya sistem ayarlarını değiştirme yetkisi verilmesinin teknik bir gerekçesi yoktur.
API anahtarları, servis hesapları ve veritabanı kullanıcılarında yetki kapsamı ihtiyaçla sınırlı tutulmalıdır.
Kimlik bilgilerinin kaynak koduna açık biçimde yazılması da kaçınılması gereken bir uygulamadır. Parolaların ve API anahtarlarının nasıl saklanacağı, nasıl değiştirileceği ve eski anahtarların nasıl iptal edileceği proje yapısının bir parçası olmalıdır.
Sunucular arasındaki iletişimde şifreli bağlantı kullanılmalı; mümkün olduğu durumlarda erişim IP, ağ veya servis seviyesinde sınırlandırılmalıdır.
Performans gerçek veri hacmiyle yeniden değerlendirilmeli
Beş ürünle çalışan bir entegrasyonun 50 bin ürünle aynı davranacağını varsaymak pahalı bir iyimserliktir.
Özellikle stok ve fiyat güncellemesi yapan sistemlerde her ürünü tek tek sorgulamak ciddi yük oluşturabilir. Bazı projelerde toplu aktarım, yalnızca değişen kayıtların gönderilmesi veya işlemlerin kuyruk üzerinden yürütülmesi daha uygun olabilir.
Burada tek bir doğru yöntem yoktur. Günlük işlem hacmi, verinin ne kadar güncel olması gerektiği, ERP’nin kapasitesi ve karşı sistemin API sınırları birlikte değerlendirilmelidir.
Bir mağazada stok bilgisinin birkaç dakika gecikmesi kabul edilebilirken başka bir operasyon anlık senkronizasyona ihtiyaç duyabilir. Teknik mimari iş ihtiyacına göre kurulmalıdır, tersine değil.
Manuel müdahale gerektiren durumların yolu belli olmalı
Her problemi yazılımla otomatik çözmeye çalışmak entegrasyonu gereksiz yere karmaşıklaştırabilir.
Bazı kayıtların insan kontrolüne bırakılması daha sağlıklıdır. Örneğin ERP’de karşılığı bulunmayan bir müşteri tipi, tanımsız stok kodu veya sıra dışı fiyat farkı otomatik işlenmek yerine inceleme listesine düşebilir.
Buradaki kritik ayrıntı şudur: kayıt kaybolmamalıdır.
Operasyon ekibi hatalı işlemi görebilmeli, neden beklediğini anlayabilmeli ve düzeltildikten sonra yeniden gönderebilmelidir. Teknik ekibin her seferinde doğrudan veritabanına müdahale etmesi gereken bir yapı uzun vadede sürdürülebilir değildir.
Yayın sonrası sorumluluklar net olmalı
Entegrasyonda problem çıktığında ilk kontrolü kimin yapacağı proje dokümanında belli olmalıdır.
Web yazılım ekibi mi?
ERP ekibi mi?
İşletmenin bilgi işlem departmanı mı?
Operasyon sorumlusu mu?
“Karşı tarafın sisteminde sorun var” cümlesi entegrasyon projelerinin pek sevilen fakat hiçbir şeyi çözmeyen klasiklerinden biridir. İşlemin her aşaması izlenebiliyorsa sorunun hangi tarafta oluştuğunu tartışmak yerine kayıt üzerinden görmek mümkündür.
Yayın sonrası bakımın kapsamı da burada devreye girer. Yazılım güncellemeleri, sunucu değişiklikleri, ERP sürüm geçişleri veya üçüncü taraf API değişiklikleri çalışan bir entegrasyonu daha sonra etkileyebilir. Piasoft, web ve özel yazılım projelerinde yayın sonrası teknik süreçleri Bakım & Destek hizmetleri kapsamında ele alıyor.
Entegrasyonun gerçekten bittiği nasıl anlaşılır?
Siparişin ERP ekranında görünmesi tek başına yeterli kabul kriteri değildir.
Sağlıklı bir canlı geçişte normal işlemler kadar hata senaryoları da denenmelidir. Bağlantı kesildiğinde kayıt kayboluyor mu? Aynı istek ikinci kez gönderildiğinde çift kayıt oluşuyor mu? Tanımsız stok kodu geldiğinde ne oluyor? ERP cevap vermediğinde işlem bekliyor mu? Hata giderildiğinde kayıt yeniden işlenebiliyor mu?
Bunların cevabı proje tamamlandıktan sonra keşfedilmemelidir.
Başarılı entegrasyon veri taşımaktan ibaret değildir. Veri modelinin doğru kurulması, sistemlerin sorumluluklarının ayrılması, bağlantının güvenli tutulması, hataların yönetilmesi ve her işlemin geriye dönük izlenebilmesi gerekir.
Piasoft; web yazılımı, ERP ve Netsis gibi iş sistemlerinin birlikte çalışması gereken projelerde ihtiyaç analizinden veri akışının tasarımına, geliştirmeden canlı geçiş ve yayın sonrası desteğe kadar süreci uçtan uca planlayabilir. Piasoft’un web ve özel yazılım yaklaşımına ilişkin ayrıntılar piasoft.com.tr üzerinden incelenebilir.