Kısa yanıt
Sunucu API entegrasyonunda çift siparişi önlemek için kendi sipariş kimliğinizi sağlayıcı kaynak kimliğiyle eşleştirin. Zaman aşımını kesin başarısızlık saymayın. Önce önceki isteğin sonucunu sorgulayın; desteklenen tekrar önleme yöntemini kullanın. Sonucu hâlâ belirsiz kalan işi yeni kaynak açmak yerine incelemeye alın ve kaynaklarla siparişleri düzenli karşılaştırın.
Dört adımda uygulama rotası
BAŞLANGIÇ → SONUÇ- 01Kimlik ver
Siparişi sabit referansla oluştur.
- 02Gönder
İstek ve sonucunu aynı kayda yaz.
- 03Doğrula
Belirsiz yanıtın sağlayıcı tarafını araştır.
- 04Eşleştir
Sipariş ve aktif kaynakları karşılaştır.
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.
Örnek: yanıtın kaybolduğu oluşturma isteği
Sipariş 742 için oluşturma isteği gönderiliyor ve sağlayıcı kaynağı açıyor olsun. Yanıt, ağ sorunu nedeniyle panelinize ulaşmıyor. Panel bu durumda yeni bir sipariş numarası üretip tekrar gönderirse iki kaynak oluşabilir. Müşteri yalnızca bir satın alma yapmış olsa bile arka plandaki ikinci işlem maliyet yaratır.
Doğru kontrol, ilk siparişin sonucu için mevcut referansı korumaktır. Sağlayıcının desteklediği istemci referansı veya durum sorgusu varsa onunla araştırma yapılır. Kaynak bulunursa kimliği ilk siparişe bağlanır. Bulunamayan ama işlemin sürüyor olabileceği durumlarda hemen yeni oluşturma yerine bekleme ve inceleme kuralı gerekir.
Ayrıca müşterinin düğmeye yeniden basmasıyla arka planın yeniden denemesi aynı siparişe bağlı kalmalıdır. Tekrarlanan bildirimin kaynağı ikinci kez teslim edilmiş göstermemesi de sınanır. Amaç bütün tekrarları yasaklamak değil, hangi tekrarın aynı işi temsil ettiğini korumaktır.
Bu senaryo açıklama amacıyla hazırlanmıştır; gerçek müşteri sonucu veya ürün testi değildir.
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.
Belirsiz sonuç için karar tablosu
| Bulgu | Yapılacak kontrol | İşlem kararı |
|---|---|---|
| İstek hiç çıkmadı | Yerel kayıt ve bağlantı aşaması | Aynı sipariş üzerinden kontrollü gönderim |
| Sağlayıcı kaynağı doğruladı | Kaynak kimliği ve sipariş eşleşmesi | Yeni kaynak açmadan kaydı tamamla |
| Sonuç henüz bilinmiyor | Resmi sorgu ve desteklenen bekleme | İnceleme durumunda tut |
| Kesin ret ve kaynak yok | Hata nedeni ve gerekli düzeltme | Düzeltilmiş isteği tanımlı kuralla dene |
HTTP yanıtı, sağlayıcının iş süreciyle birlikte yorumlanmalıdır. Bazı işlemler arka planda devam edebilir. Kendi varsayımınızla eklediğiniz bir alanın tekrar koruması sağladığını kabul etmeyin; sağlayıcının belgelediği davranışı pilotta doğrulayı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.
Uzlaştırma ve iptal süreçlerini unutmayın
Canlı kullanımda belirli aralıklarla aktif siparişleri sağlayıcıdaki kaynaklarla karşılaştırın. Bir siparişin iki kaynağa bağlanması, kaynağı olmayan aktif sipariş veya siparişsiz açık kaynak ayrı inceleme başlıklarıdır. Listeleri körlemesine eşitleyip kaynak silmek yerine farkları sorumlu kişiye gösterin.
Bir olayda müşteriye hangi durum bilgisinin verileceğini de tasarlayın. Teknik hata kodunu olduğu gibi göstermek yerine siparişin beklediğini veya incelendiğini açıkça belirtin. Fakat kaynak gerçekten hazır olmadan teslim tamamlandı demeyin.
0 / 4 adım kontrol edildi · Bu seçimler yalnızca açık sayfada tutulur.
Sık sorulan sorular
Zaman aşımı olunca hemen tekrar gönderebilir miyim?
Önce işlemin sağlayıcıya ulaşıp ulaşmadığını araştırın. Yanıtın kaybolması kaynak oluşmadığını kanıtlamaz. Tekrar davranışı sağlayıcının desteklediği koruma ve sorgulama yöntemine dayanmalıdır.
Müşteri numarası tekrar önleme anahtarı olur mu?
Tek başına uygun değildir; aynı müşteri iki meşru sipariş verebilir. Koruma aynı işi temsil eden sipariş veya işlem kimliği düzeyinde tasarlanmalıdır.
Çift kaynak bulunca otomatik silmek doğru mu?
Önce hangi kaynağın kullanıldığını ve ilgili siparişleri doğrulayın. Otomatik silme yanlış kaynağı etkileyebilir. Fark tespitiyle düzeltme işlemi arasında kontrollü bir karar adımı bulunsun.
Yöntem ve kaynak notu
Örnek senaryolar ve karar tabloları, konuyu açıklamak için hazırlanmış çalışma önerileridir. Ölçülmüş müşteri sonucu veya bağımsız ürün testi olarak sunulmaz. Platform ve ürün koşulları değişebileceğinden uygulama öncesinde ilgili resmi belgeyi ve kendi hizmet kapsamınızı kontrol edin.