İş akışını ve verinin kaynağını tanımlayın
Bir siparişin hangi sistemde oluştuğunu, stok bilgisinin nerede tutulduğunu ve müşteri kaydının hangi uygulamada güncellendiğini belirleyin. Aynı verinin birden fazla sistemde düzenlenmesi çakışma yaratabilir; öncelikli kayıt kaynağı açık olmalıdır.
Entegrasyona dahil alanlar, eşleme kuralları ve kimlikler dokümante edilmelidir. Ürün kodu, müşteri numarası veya sipariş anahtarındaki farklılıklar yanlış kayıt eşleşmesine neden olabilir. Toplu aktarım ile gerçek zamanlı veri akışı farklı tasarım ihtiyaçları doğurur.
API erişimlerini ve teknik sınırları inceleyin
Sistemlerin desteklediği API, webhook veya dosya aktarım yöntemlerini doğrulayın. Erişim lisansları, çağrı limitleri, sürümler ve üreticinin destek koşulları proje takvimini etkileyebilir. API anahtarları için yetki kapsamı ve güvenli saklama yöntemi belirlenmelidir.
Test ortamına erişim, örnek veri ve teknik dokümantasyon geliştirmeyi kolaylaştırır. Canlı sistemde deneme yapılması gerekiyorsa etkilenecek işlemler ve geri dönüş adımları önceden planlanmalıdır. Erişimin mevcut olması, her veri alanının aktarılabileceği anlamına gelmez.
Hata ve tekrar deneme senaryolarını tasarlayın
Bağlantı kesilmesi, zaman aşımı veya karşı sistemin geçici olarak çalışmaması veri akışını durdurabilir. Başarısız işlemlerin kaydı, bildirim yöntemi ve yeniden denenmesi gerekir. Aynı işlemin tekrar gönderilmesi mükerrer sipariş veya fatura üretmemelidir.
Hangi işlemlerin otomatik tekrar edileceği, hangilerinin insan onayı gerektirdiği belirlenir. Loglarda gereksiz kişisel veya hassas veri tutulmaması ve yalnızca yetkili kullanıcıların erişmesi tasarımda dikkate alınmalıdır.
Kabul testlerini ve bakım modelini belirleyin
Başarılı veri aktarımının yanında eksik alan, hatalı kimlik, mükerrer kayıt ve iptal işlemleri de test edilmelidir. İş birimlerinin kabul edeceği sonuçlar somut örneklerle tanımlanır; yalnızca API çağrısının başarılı olması yeterli değildir.
Canlıya geçişte ilk veri aktarımı, eski süreçten geçiş ve izleme adımları planlanır. Sonrasında API sürüm değişiklikleri ve yeni alanlar bakım ihtiyacı yaratabilir. Kaynak kod teslimi, dokümantasyon, barındırma ve bakım sorumlulukları teklif aşamasında ayrı belirtilmelidir.
Örnek senaryo: e-ticaret siparişini ERP’ye aktarmak
Bir e-ticaret sitesinde oluşan siparişin ERP’ye aktarılması istensin. Basit görünen bu işte müşteri kaydının bulunması, ürün kodlarının eşleşmesi, vergi ve indirim bilgilerinin doğru taşınması gerekir. Siparişin iptal edilmesi veya sonradan değiştirilmesi ayrı bir veri akışıdır. Sadece ilk sipariş kaydının aktarılması, bütün sürecin entegre olduğu anlamına gelmez.
Örnekte önce siparişin hangi aşamada ERP’ye gönderileceği ve aktarımdan sonra hangi sistemde düzenlenebileceği kararlaştırılır. Aynı müşteri iki kez kaydedilmemeli; aynı sipariş tekrar gönderildiğinde mükerrer belge oluşmamalıdır. Kapsam hazırlarken mutlu akışın yanında değişiklik ve hata akışlarının da konuşulması gerektiğini gösterir.
Kimlik eşlemesi kaydın adıyla sınırlı değildir
Ürün adları ve müşteri adları değişebilir veya birbirine benzeyebilir. Entegrasyonda kayıtları yalnızca ad üzerinden eşlemek bu yüzden risklidir. Sistemlerin benzersiz kimlikleri, ürün kodları veya belirlenen eşleme anahtarları kullanılır. Aynı kayıt iki sistemde farklı kimlik taşıyorsa bu ilişki saklanmalıdır. İlk veri aktarımının nasıl yapılacağı da bu eşleme tasarımına bağlıdır.
Eşleme bulunamadığında işlem otomatik olarak tahminle tamamlanmamalıdır. Hangi kaydın sorunlu olduğu görünmeli ve gerekli düzeltme yapılabilmelidir. İş biriminin anlayabileceği bir hata açıklaması, yalnızca teknik hata kodundan daha kullanışlıdır. Kayıtların sonradan birleştirilmesi veya silinmesi halinde eski eşlemelerin nasıl ele alınacağı da baştan düşünülür.
Tekrar deneme mükerrer işlem üretmemeli
Bir API çağrısının yanıtı zaman aşımına uğradığında karşı sistemde işlemin hiç gerçekleşmediği varsayılamaz. Kayıt oluşmuş, yanıt geri dönememiş olabilir. Aynı siparişi yeniden göndermek ikinci bir kayıt yaratıyorsa entegrasyon veri bütünlüğünü bozabilir. İşlem kimliği ve tekrar gönderim davranışı bu nedenle tasarımın parçasıdır.
Otomatik tekrarların sayısı, aralığı ve hangi hatalarda uygulanacağı belirlenir. Yanlış veri nedeniyle reddedilen işlem, bağlantı hatası gibi tekrar edilmemelidir. Uzun süre başarısız kalan işler için insan müdahalesi ve bildirim yolu gerekir. Testlerde yanıtın kaybolması, karşı sistemin durması ve aynı mesajın tekrar gelmesi gibi durumları simüle etmek, canlıda çıkabilecek belirsizlikleri azaltır.
Gerçek zamanlı aktarım her zaman gerekli mi?
Stok veya ödeme gibi işlerde gecikme beklentisiyle raporlama işindeki beklenti aynı olmayabilir. Bazı veriler kısa aralıklarla toplu aktarılabilir; bazı işlemler ise olay oluştuğunda tetiklenmelidir. “Gerçek zamanlı olsun” talebinin hangi iş sonucunu koruduğu anlaşılmadan bütün akışı aynı tasarımla kurmak gereksiz karmaşıklık yaratabilir.
API çağrı limitleri, veri miktarı ve karşı sistemin kapasitesi seçilecek yöntemi etkiler. Webhook bulunması da tek başına teslim garantisi anlamına gelmez; bildirimin kaçırılması halinde kayıtların nasıl uzlaştırılacağı değerlendirilir. Belirli aralıklarla kaynak ve hedef kayıtların karşılaştırılması, eksik işlemleri fark etmek için kullanılabilir. Bu kontrolün kapsamı ve işletim maliyeti de proje teklifinde yer almalıdır.
Canlıya geçiş ve bakım için teslim listesi
Geliştirme tamamlandıktan sonra erişim hesapları, ayarlar, log noktaları ve hata bildirimleri devredilmelidir. Hangi veri alanlarının aktarıldığı ve hangi senaryoların kapsam dışında olduğu dokümante edilir. Teknik erişimlerin kişisel bir geliştirici hesabına bağlı kalmaması, bakımın sürdürülebilmesi için önemlidir. Kaynak kod ve dağıtım sorumluluğu teklifte açıklanmalıdır.
API sürümü veya iş kuralı değiştiğinde entegrasyon da değişebilir. Bu değişiklikleri kimin takip edeceği ve yeni bir alanın eklenmesinin bakım mı, yeni geliştirme mi sayılacağı konuşulur. Disket’e entegrasyon talebi iletirken yalnızca uygulama isimlerini değil, örnek bir sipariş veya kayıt akışını ve beklenen sonucu paylaşmanız işin kapsamını daha iyi tarif eder. Gizli veriler yerine anonimleştirilmiş örnekler kullanılabilir.
Entegrasyon kabulünde örnek hata senaryoları
| Senaryo | Beklenen davranış | Kontrol noktası |
|---|---|---|
| Aynı sipariş yeniden gelir | Tek kayıt oluşur | İşlem kimliği ve tekrar davranışı |
| Ürün kodu bulunamaz | Hata görünür ve işlem takip edilir | Eşleme tablosu |
| API yanıtı kaybolur | Kayıt durumu doğrulanır | Zaman aşımı ve sorgulama |
| Sipariş iptal edilir | İptal akışı doğru yansır | İş kuralı |
| API sürümü değişir | Uyumluluk test edilir | Bakım ve sürüm takibi |
Teklif öncesi kontrol listesi
- İş süreci, kayıt kaynağı ve aktarılacak alanlar
- API dokümantasyonu, erişim ve lisanslar
- Veri eşleme, kimlikler ve çakışma kuralları
- Hata kayıtları, tekrar deneme ve bildirim
- Kabul senaryoları, teslimatlar ve bakım modeli
Sık sorulan sorular
Her ERP veya CRM sistemiyle entegrasyon yapılabilir mi?
Desteklenen API veya aktarım yöntemlerine, lisans koşullarına ve erişilebilen verilere bağlıdır. Teknik inceleme yapıldıktan sonra kapsam belirlenir.
Entegrasyonun başarı kriteri nasıl belirlenir?
Beklenen iş sonucu somut testlerle tanımlanır. Örneğin siparişin tek kez oluşması, stokların doğru güncellenmesi ve hata halinde işlemin izlenebilmesi kabul kriterleri olabilir.
API çağrısı zaman aşımına uğrarsa işlemi yeniden göndermek güvenli midir?
Karşı sistem işlemi tamamlamış fakat yanıt geri dönememiş olabilir. Aynı kaydı tekrar göndermeden önce işlem kimliği ve hedefteki kayıt durumu değerlendirilmelidir. Tekrar deneme davranışının mükerrer sipariş veya belge üretmeyecek şekilde tasarlanması gerekir.
Teknik kaynaklar
Disket Teknoloji’nin sektör faaliyetleri 2014 yılında şahıs şirketi olarak başladı. Bugün hizmetlerimiz Disket Teknoloji Ltd. Şti. bünyesinde sürüyor. Şirket geçmişimiz.