Yanıt gelmemesi, işlemin yapılmadığını göstermez
Müşteri bir sunucu siparişi verir, paneliniz sağlayıcıya oluşturma isteği gönderir ve bağlantı zaman aşımına uğrar. Ekranda hata görünür. Ancak sağlayıcı isteği alıp kaynağı oluşturmuş olabilir. Panel aynı isteği düşünmeden tekrarlarsa tek sipariş için iki sunucu açılması mümkündür. Sorun sadece hatayı göstermek değil, sonucu belirsiz kalan işlemi doğru yönetmektir.
Özellikle ücretli kaynak oluşturan entegrasyonlarda “başarısız” ve “sonucu henüz bilinmiyor” durumlarını ayırın. Müşteriye işlem sürerken yeniden satın alma düğmesi göstermek veya arka planda sınırsız tekrar çalıştırmak, belirsizliği yeni işlemlerle büyütebilir.
Sipariş numarası bütün adımlarda aynı kalsın
Kendi sisteminizde bir sipariş numarası oluşturun ve sağlayıcıdaki kaynak kimliğiyle ilişkilendirin. Aynı müşteri aynı üründen iki farklı sipariş verebilir; bu nedenle yalnızca müşteri numarası tekrar kontrolü için yeterli değildir. Öte yandan aynı sipariş için yapılan yeniden denemeler de yeni sipariş gibi görünmemelidir.
API’nin desteklediği tekrar önleme anahtarı veya istemci referansı varsa belgelediği biçimde kullanın. Desteklenmeyen bir alanı isteğe eklemek koruma sağladığı anlamına gelmez. HTTP POST istekleri tekrarlandığında ek etkiler oluşabileceği için tekrarın güvenli olduğunu varsaymayın. Bu teknik ayrım MDN’nin POST belgesinde de açıklanır.
Belirsiz sonucu ayrı bir duruma alın
Basit bir akışta sipariş “alındı”, “sağlayıcıya gönderildi”, “doğrulama bekliyor”, “hazır” veya “inceleme gerekiyor” durumlarından geçebilir. Bunlar zorunlu standart adlar değildir; önemli olan her durumun bir sonraki işleme izin verip vermediğinin açık olmasıdır. Zaman aşımını doğrudan yeni oluşturma isteğine bağlamayın.
Önce sağlayıcı tarafında kaynak oluşup oluşmadığını desteklenen sorgulama yöntemiyle kontrol edin. Kontrolün de sonucu belirsizse siparişi inceleme kuyruğuna alın. Tekrar sayısını ve bekleme süresini sınırlayın. Müşteri ekranında işlemin hangi aşamada olduğunu anlaşılır biçimde gösterin; teknik hata dökümünü müşteri mesajı olarak kullanmayın.
Sağlayıcı seçerken sadece oluşturma örneğini istemeyin
Başarılı bir kaynak oluşturma örneği entegrasyonun küçük bir bölümüdür. Durum sorgulama, başarısız kurulum, iptal, kaynak kimliğinin bulunması ve yinelenen bildirimlerin işlenmesi de belgelenmelidir. Bize ait VDSHost’un sunucu bayiliği ve API entegrasyonu seçeneklerini incelerken bu hata senaryolarını da sorun. Güncel kapsamı ürün belgeleri ve destek kanalı üzerinden doğrulayın.
Teklifte test işlemlerinin gerçek ücretli kaynak oluşturup oluşturmadığı yazılı olsun. Kontrol amacıyla açtığınız sunucuların kim tarafından ve ne zaman kapatılacağını belirleyin. Entegrasyon tamamlandığında sisteminizdeki aktif siparişlerle sağlayıcıdaki aktif kaynakları eşleştiren bir kontrol de düşünün.
Pilotta denenecek dört durum
- Aynı siparişin oluşturma isteğinin iki kez gönderilmesi.
- Kaynak oluştuğu halde ilk isteğin yanıtının alınamaması.
- Sağlayıcıya ulaşılamadan önce bağlantının kesilmesi.
- Hazır bildiriminin aynı kaynak için yeniden gelmesi.
Her denemede sipariş sayısını, oluşan kaynak sayısını ve sistemin son durumunu birlikte kontrol edin. Başarılı görünen ekranın arkasında sahipsiz kaynak kalmamalı. Bu çalışma için önce tek sipariş ve sınırlı bir test ortamı kullanın. Operasyonun devamı için zamanlanmış görevlerin izlenmesi de önemlidir; uzlaştırma kontrolünüzün sessizce durmasını istemezsiniz.