Paylaşımlı Hesap Yuvaları için Carrier Lookup API Eşzamanlılık Kuyruğu

Bir Carrier Lookup API eşzamanlılık kuyruğu, her sürecin kendi kullanılabilir kapasitesini tahmin etmesine izin vermek yerine, tek bir hesap kullanan tüm çalışanları koordine etmelidir.

Bir Carrier Lookup API eşzamanlılık kuyruğu, her sürecin kendi kullanılabilir kapasitesini tahmin etmesine izin vermek yerine, tek bir hesap kullanan tüm çalışanları koordine etmelidir. CarrierLookup, paylaşımlı devam eden gerçek zamanlı yuvaları ve ayrı bir çoklu istek hesap geçidini belgeler. Tekli ve eşzamanlı çoklu istekleri hesap genelinde bir denetleyici üzerinden yönlendirin, her çoklu istek için giriş sırasını koruyun ve bir yuvayı yalnızca o istek sona erdikten sonra serbest bırakın. Bu kontroller eşzamanlı çalışmayı yönetir; bunlar dakikalık bir kota veya yanıt süresine dair bir vaat değildir.

Bireysel bir uygulama çalışanı değil, hesabı modelleyin

Orijinal Operatör Sorgulama, orijinal numara tahsis bağlamını döndürür: orijinal olarak tahsis edilen operatör, temel operatör, numara türü ve tahsis coğrafyası. Taşıma işleminden sonraki güncel operatörü veya bir numaranın arama ya da mesaj alıp alamayacağını bildirmez. Buradaki gerçek zamanlı ifadesi, canlı bir ağ incelemesini değil, istek-yanıt iş akışını ifade eder. Original Carrier Lookup API ilgili ürün sayfasıdır ve API belgeleri güncel entegrasyon detayları için kaynak olmaya devam etmelidir.

Birkaç hizmet bir API hesabını paylaştığında, süreç başına bir semafor yetersiz kalır. İki web çalışanı, bir arka plan içe aktarma işlemi ve bir analist aracı, her biri hesabın boş yuvaları olduğuna inanabilir. Belgelenmiş genel kurallar, hesap başına beş paylaşımlı devam eden gerçek zamanlı yuvayı ve bir çoklu isteği tanımlar. Bu nedenle, müşteri tarafındaki bir denetleyici, tek bir hesap düzeyi koordinatörü veya tüm katılımcı çalışanlara bekleyen çağrılar hakkında tutarlı bir görünüm sağlayan başka bir mekanizma kullanmalıdır. Tam depolama veya kuyruk teknolojisi, müşterinin uygulama tercihidir.

Kuyruk; gönderilen E.164 tanımlayıcısını veya tanımlayıcılarını, istek modunu, uygulama iş referansını ve ekibin kuyruğa aldığı zamanı içeren bir istek zarfını tutmalıdır. Bunlar, CarrierLookup'ın yanıt şemasıyla ilgili bir iddia değil, müşteriye ait önerilen alanlardır. Kuruluşun politikası gerektirmediği ve korumadığı sürece tam numaraları veya kimlik bilgilerini günlüğe kaydetmekten kaçının.

Tekli ve çoklu çağrılara ayrı geçitler verin

Tekli bir sorgulama bir adet E.164 numarası kabul eder. Eşzamanlı çoklu sorgulama ise 1–100 arası E.164 numarasını kabul eder ve tek bir yanıtta sıralı bir sonuç döndürür. Bunların her ikisi de gerçek zamanlı kontrollerdir, ancak çoklu rota aynı zamanda hesap genelinde tek seferde bir istek kısıtlamasına sahiptir. İki geçit tasarlayın: devam eden tüm gerçek zamanlı istekler için paylaşımlı bir kapasite sayacı ve çoklu istek için özel bir geçit. Çoklu bir çağrı, belgelenmiş hesap kuralları ve özel çoklu geçit kapsamında ihtiyaç duyduğu kapasiteyi edinmelidir; uygulama, tamamlanmış bir yanıt veya terminal hatasından sonra her ikisini de birlikte serbest bırakmalıdır.

Çoklu bir isteği, eşzamansız bir toplu dosya görevi olarak ele almayın. Ayrı olan Global operatör sorgulama ürünü, TXT veya CSV dosyalarını kabul eder, tanımlayıcıları hazırlar ve daha sonra bir CSV üretir. Bu, farklı bir iş akışına aittir. CarrierLookup nasıl çalışır sayfası, okuyucuların bu modları ayırt etmesine yardımcı olur. Uygulamanın büyük bir dosya işi varsa, bir dosyayı eşzamanlı kuyruğa itmek yerine belgelenmiş toplu ürünü bilinçli olarak seçin.

Koordinatörün ayrıca adalete ihtiyacı vardır. Sürekli bir tekli istek akışı, halihazırda kuyruğa alınmış çoklu bir isteği aç bırakmamalı; aynı zamanda büyük bir içe aktarma işlemi, küçük etkileşimli kontrolleri süresiz olarak engellememelidir. Müşteriye ait bir zamanlama kuralı, sıraları varış sırasına göre rezerve edebilir veya sınırlı bir öncelik politikası kullanabilir. Bu bir iş akışı önerisidir, sağlayıcı zamanlama garantisi değildir.

Zaman aşımını ve çalışan hatasını terminal kuyruk olayları olarak ele alın

Tekli bir istek ve çoklu bir istek, genel API'de belgelenmiş zaman aşımı tavanlarına sahiptir. Normal bir tamamlanma süresi varsaymak yerine, tam değerler ve yanıt sözleşmesi için güncel API belgelerini kullanın. İstemci tarafındaki bir zaman aşımı, sunucunun çağrıyı tamamlayıp tamamlamadığı konusunda belirsizlik bırakabilir; bu nedenle bir denetleyici, bu belirsizliği tamamlanmış bir operatör sonucundan ayrı olarak kaydetmelidir. Eşzamanlı çoklu sorgulama için ürün, çoklu zaman aşımının tüm isteği kısmi sonuçlar olmadan başarısız kıldığını ve tam tutarı döndürdüğünü belgeler. Tamamlanmamış bir yanıttan satır düzeyinde başarılar üretmeyin.

Her kuyruk kiralamasının, bir uygulama çalışanı çökse bile bir serbest bırakma yoluna ihtiyacı vardır. Müşterinin denetleyicisi işi belirsiz olarak işaretleyebilir, çalışan gittiğinde yerel kapasiteyi serbest bırakabilir ve isteği bir incelemeye veya dikkatlice kontrol edilen bir yeniden deneme politikasına aktarabilir. Bir ağ olayından sonra hizmeti otomatik olarak yeniden denemelerle doldurmayın. Bir yeniden deneme seçilirse, orijinal uygulama iş referansını koruyun ve sonraki gözlemi önceki belirsiz girişimden ayırt edin.

Tamamlanmış bir sorgulama, boş operatör alanları içerebilir ve tamamlanmış, ücretlendirilebilir bir sonuç olarak kalabilir. Bu bir zaman aşımı değildir ve yalnızca boş olmayan bir operatör zorlamak için yeniden denemeyi tüketmemelidir. Tersine, reddedilen bir giriş formatı "operatör yok" sonucu değildir. Kuyruk, istek durumunu kaydeder; sorgulama anlamını yeniden yorumlamaz.

Bir hız sınırı icat etmeden kuyruğu izleyin

Faydalı müşteri tarafı metrikleri arasında devam eden tekli istekler, çoklu isteğin aktif olup olmadığı, iş sınıfına göre kuyruk yaşı, tamamlanmış yanıtlar, format reddetmeleri, zaman aşımları ve belirsiz taşıma sonuçları yer alır. Bunlar, uygulamanın eşzamanlılığa uyup uymadığını ve kullanıcıların müşteri kontrollü bir çalışanı bekleyip beklemediğini gösterir. Bunlar, genel gerçeklerin belirtmediği sabit bir dakika başına istek veya günlük kota anlamına gelmez.

Kullanıma sunmadan önce, aynı anda gönderim yapan iki web çalışanını, tekli istekler aktifken kuyruğa alınan çoklu bir isteği, yanıt öncesi çalışan çıkışını ve zaman aşımını test edin. Hesap için birden fazla çoklu isteğin aktif olmadığını ve edinilen tüm yerel geçitlerin sonunda serbest bırakıldığını onaylayın. Sonucun gönderilen kanonik numarayla eşleştiğini ve sıralı çoklu satırların iletişim kayıtları güncellenmeden önce mutabık kalındığını doğrulayın.

Son bir operasyonel not, döndürülen operatörün orijinal tahsisi tanımladığını açıklamalıdır. Hızlı bir kuyruğun hala orijinal operatör tahsisi için kesin bir etikete ihtiyacı vardır. Bunu bir kaynak ve kontrol zamanı ile saklayın, tahsis bölgesi ve şehrini bir kişinin konumundan ayrı tutun ve iletişim kurulabilirlik veya kimlik soruları için diğer kanıtları kullanın.

SSS

Ekipler, bir CarrierLookup hesabını kullanan birkaç çalışanı nasıl koordine etmelidir?

Tüm çalışanların paylaştığı, paylaşımlı gerçek zamanlı kapasite geçidine ve eşzamanlı çoklu istekler için özel bir geçide sahip, hesap genelinde bir denetleyici kullanın.

Belgelenmiş eşzamanlılık kuralı, dakika başına bir kota oluşturur mu?

Hayır. Bu, eşzamanlı devam eden işleri sınırlar ve dakika başına sabit bir istek sayısı belirtmez.

Zaman aşımına uğrayan çoklu bir istek kısmen kabul edilebilir mi?

Belgelenmiş çoklu zaman aşımı, tüm isteği kısmi sonuçlar olmadan başarısız kılar. Bunu istek düzeyinde bir hata olarak tutun ve başarılı satırlar icat etmeyin.

Boş operatör alanları otomatik bir yeniden denemeyi tetiklemeli mi?

Kendi başlarına hayır. Boş tahsis alanlarına sahip tamamlanmış bir sorgulama, tamamlanmış bir sonuç olarak kalır; ekip bu sonucu doğru bir şekilde korumalıdır.

Daha Fazla Bilgi Edinin

İş akışınızdaki bir sonraki adıma uyan ürün bilgilerini seçin.

• Ürün belgelerini görüntüleyin →
• Ekiple görüşün →