Balya ve Bandırma: Yazılım Entegrasyonu Kontrolü

Balya veya Bandırma’da işletmenizin siparişleri bir yazılımdan diğerine aktarılırken kayboluyor ya da iki kez oluşuyorsa, ihtiyaç yeni bir ana sayfa tasarımından farklıdır. Önce aktarımın hangi koşulda güvenilir sayılacağını tanımlamak gerekir. Bu rehber özel yazılım entegrasyonu için örnek veri, hata yönetimi ve kabul testlerini açıklar. Senaryolar varsayımsaldır; bu ilçelerde tamamladığımız bir müşteri projesi veya bölgesel araştırma sonucu olarak sunulmaz.

Bir siparişin yaşam döngüsünü çıkarın

Örnek bir sipariş için kaynağı, dış sistemdeki kimliği, oluşturulma zamanını, toplam tutarı ve durum değişikliklerini yazın. “Sipariş aktarıldı” demek yeterli değildir: karşı sistemde kayıt oluştu mu, yalnızca kuyruğa mı alındı, yoksa doğrulama bekliyor mu? İşletme ve geliştirici bu durumları aynı adlarla kullanmalıdır. Tutar, vergi ve para birimi gibi alanların anlamı da iki tarafta eşleşmelidir.

İlk denemede gerçek müşteri verisi yerine hazırlanmış örnekler kullanın. Normal siparişin yanında iptal edilmiş, kısmen karşılanmış ve adresi eksik sipariş ekleyin. Bu veri seti geliştirme boyunca korunursa, değişikliklerin eski davranışı bozup bozmadığı tekrar ölçülebilir.

Aynı bildirim iki kez gelirse ne olacak?

Bir bağlantı zaman aşımına uğradığında kaynak sistem işlemi tekrar gönderebilir. İlk istek karşı tarafta tamamlandığı hâlde cevabı ulaşmamış olabilir. Yeni isteği ayrı bir sipariş saymak, stok ve muhasebe hatasına yol açar. Bu nedenle işleme ait sabit bir dış kimlik ve tekrar kontrolü tasarlanmalıdır.

• Dış sipariş kimliğinin hangi sistem tarafından üretildiğini belirleyin.
• Aynı kimlikle gelen ikinci isteğin önceki sonuçla ilişkilendirilmesini test edin.
• Aynı kimliğe farklı tutar geldiğinde sessizce üzerine yazmak yerine uyuşmazlığı görünür kılın.
• Tekrar deneme aralığını ve deneme sınırını ilgili servisin kullanım koşullarıyla birlikte belirleyin.

HTTP üzerinden POST kullanılması tek başına tekrar güvenliği sağlamaz. MDN’nin POST açıklaması da bu yöntemin varsayılan olarak idempotent olmadığını belirtir. Aynı işin ikinci defa gerçekleşmesini önleme davranışı uygulamanın veri modeli ve işlem kontrolü içinde ayrıca kurulmalıdır.

Hata kuyruğunu işletmenin anlayacağı şekilde hazırlayın

Teknik bir günlük dosyasında hata bulunması, işletmenin sorunu yönetebildiği anlamına gelmez. İşlem numarası, son deneme zamanı, sorumlu ekip ve yapılacak iş görünür olmalıdır. “Ürün kodu bulunamadı” ile “karşı servis geçici olarak yanıt vermiyor” aynı çözümü gerektirmez. Eksik ürün eşleştirmesi düzeltilmeden sürekli tekrar denemek sorunu büyütebilir.

Yeniden gönderme yetkisi sınırlandırılmalı ve yapılan işlem kayıt altına alınmalıdır. Günlüklerde parola, erişim anahtarı veya gereksiz kişisel veri tutulmamalıdır. Bir hatayı incelemek için bütün müşteri kaydını paylaşmak yerine işlem kimliği ve gerekli alanlarla çalışmak daha güvenli bir yaklaşımdır.

Aktarım sayısını değil, mutabakatı kontrol edin

Kaynakta yüz, hedefte yüz sipariş bulunması tek başına doğruluk kanıtı değildir. Aynı sipariş iki kez, başka bir sipariş hiç aktarılmamış olabilir. Karşılaştırmayı sabit kimlik üzerinden yapın; durum, toplam tutar, para birimi ve ilgili satırları kontrol edin. İptallerin ve sonradan gelen güncellemelerin nasıl işleneceği ayrıca tanımlanmalıdır.

1. Kaynak ve hedef kayıtlarını aynı zaman aralığı için alın.
2. Eşleşmeyen kimlikleri ve alan uyuşmazlıklarını ayrı listelerde gösterin.
3. Farkı kimin inceleyip kapatacağını belirleyin.
4. Düzeltme sonrasında aynı karşılaştırmayı yeniden çalıştırın.

Pilot geçişte aranacak kabul kanıtları

Entegrasyonu bütün işlemlere açmadan önce sınırlı bir örnek üzerinde deneyin. Bağlantı kesintisi, yinelenen bildirim, eksik ürün kodu, yetkisiz istek ve eşzamanlı güncelleme testlerinin beklenen sonuçlarını teklif aşamasında yazın. “Ekran açıldı” veya “API yanıt verdi” yerine, her senaryo için oluşan kayıt ve işletmenin göreceği durum doğrulanmalıdır.

Geri dönüş planında yalnızca eski yazılımı yeniden açmak bulunmamalıdır. Pilot sırasında oluşan yeni siparişlerin hangi sistemde kalacağı ve tekrar aktarımın nasıl yapılacağı açıklanmalıdır. Teslimatta entegrasyon sözleşmesi, alan eşleştirmesi, test sonuçları, erişim sorumluları ve bakım sınırları birlikte verilmelidir.

Deca Yazılım’ın merkezi Atakum/Samsun’dadır. Balya ve Bandırma için keşif ve teknik değerlendirme uzaktan yürütülebilir; bu yazı yerel şube bulunduğu anlamına gelmez. Proje kapsamını Balıkesir özel yazılım ve özel yazılım geliştirme sayfalarından inceleyebilirsiniz.

Teknik kaynak: MDN — HTTP POST yöntemi. Her entegrasyonda karşı servisin güncel teknik sözleşmesi ayrıca incelenmelidir.