Business Central 429 Too Many Requests Hatası: Teşhis ve Çözüm Adımları

Dynamics 365 Business Central API çağrısı 429 Too Many Requests döndürüyorsa istek limiti aşılmıştır. Bu tek başına kullanıcı parolası veya ürün verisi sorunu anlamına gelmez. Microsoft'un resmi dokümantasyonu, yoğun isteklerde istemcinin kontrollü yeniden deneme stratejisi uygulamasını önerir.

Hatanın yaygın tetikleyicileri

• Her ekranda tüm stok listesinin yeniden sorgulanması.
• Birden fazla entegrasyonun aynı anda yoğun çağrı üretmesi.
• Veri değişikliklerini olaylarla izlemek yerine aşırı sık kontrol yapılması.
• Hata alan işlemin beklemeden tekrar tekrar gönderilmesi.

Uygulanabilir çözüm

1. Ölçün: Hangi endpoint ve entegrasyonun çağrı sayısını artırdığını kaydedin. Aynı müşteriye ait işlemleri ilişkilendirin.

2. Soğuma süresi ekleyin: Uygun sunucu yanıtları ve dokümantasyon doğrultusunda kademeli bekleme veya exponential backoff kullanın. Tekrarlara rastgele gecikme eklemek, tüm istemcilerin aynı anda yeniden yüklenmesini azaltabilir.

3. Kuyruk kullanın: Kritik iş emirlerini veya siparişleri bellekte unutmak yerine takip edilebilir bir iş kuyruğuna alın. Tekrar edilen işlemler çift sipariş üretmemeli.

4. Değişiklik bazlı çalışın: Uygun kaynaklar için Business Central webhook özelliklerini değerlendirin; her ekranda büyük veri setini indirmeyin.

5. Yeniden uzlaştırın: Kaçırılan olayları ve eksik siparişleri belirlemek için belirli aralıklarla mutabakat yapın.

Örnek pseudo-code

istek_yap()
429 gelirse:
    uygun_bekleme_suresini_belirle()
    kuyruga_al_ve_bekle()
    islem_kimligini_koruyarak_tekrar_dene()
sinirli_tekrar_sayisi_asildiysa:
    insan_incelemesine_gonder()

Başarı ölçütü

Düzelen tek istek değil, entegrasyonun yoğun saatlerde sipariş kaybetmeden çalışmasıdır. Hatalı/başarılı çağrı oranını ve kuyruk gecikmesini ayrı izleyin.

Yeniden deneme ne zaman durmalı?

Aynı iş için deneme sayısı ve toplam bekleme süresi sınırlı olsun. Süre dolduğunda işlem kaybolmamalı; başarısız/bekleyen kaydı ve inceleyecek sorumlu görünür kalmalıdır. Kuyruğu hızlandırmak için sınırsız paralel işçi açmak yükü artırır.

Örnek senaryo: Gece katalog aktarımı sabah bayi siparişleriyle çakışıyor. Önce katalog sorgusunun kapsamını daraltın ve aynı ortam için toplam eşzamanlılığı azaltın. Sipariş kuyruğuna öncelik verilebilir; fakat kayıt doğrulama ve mükerrer önleme kuralları atlanmaz.

Uzun süren tek isteğin sorunu için 504 zaman aşımı rehberini kullanın.

Kaynaklar ve doğrulama

• learn.microsoft.com — resmî doküman
• learn.microsoft.com — resmî doküman

Örnek akışlar mimari öneridir; tamamlanmış müşteri projesi veya üretici iş ortaklığı iddiası değildir. Teknik kaynak kontrolü: 17 Ekim 2026. Kurulumun sürümü, lisansı ve izinleri ayrıca doğrulanır.

İşletmenizdeki akışa uyarlayın

ERP entegrasyonu planlama rehberi. Özel yazılım geliştirme kapsamını inceleyebilir, mevcut sürecinizi birlikte değerlendirebiliriz.

İhtiyacınızı konuşalım →