Orijinal Operatör Sorgulama Zaman Aşımı Kurtarma ve Kısmi Sonuçsuz İşlem
Veri ekipleri için belgelenmiş istek sınırları ve inceleme adımlarıyla, kısmi sonuç içermeyen operatör sorgulama zaman aşımı kurtarma rehberi.
Operatör sorgulama zaman aşımı kurtarma süreci, tamamlanmış bir sorguyu belirsiz bir iletim olayından ayırarak başlar.
Operatör sorgulama zaman aşımı kurtarma süreci, tamamlanmış bir sorguyu belirsiz bir iletim olayından ayırarak başlar. Senkronize bir tekil sorgu, normal bir sonuç olmadan sona erebilir; zaman aşımına uğrayan senkronize çoklu istek ise tek bir istek olarak başarısız olur ve kısmi satırlar döndürmez. Gönderilen orijinal tanımlayıcıları ve deneme durumunu inceleme için saklayın, ardından yalnızca açık bir müşteri politikası kapsamında yeniden deneyin. Eksik operatör alanlarını asla tahminlerle doldurmayın veya bir zaman aşımını "operatör yok" şeklinde etiketlemeyin.
Hangi aşamanın başarısız olduğunu belirleyin
Orijinal Operatör Sorgulama, bir numara aralığının orijinal olarak tahsis edildiği operatörü, numara türünü ve tahsis coğrafyasını sağlar. Tamamlanmış bir yanıt, boş operatör alanları içerebilir; bu, söz konusu değerlerin o tamamlanmış sorguda mevcut olmadığı anlamına gelir. Bu durum; bir servis zaman aşımından, reddedilen bir E.164 formatından veya istemci bağlantı hatasından farklıdır. Bir kurtarma prosedürü, başka bir istek göndermeye karar vermeden önce aşamayı sınıflandırmalıdır.
Müşterinin kendi deneme kaydıyla başlayın: istek modu, gönderilen kanonik numara veya sıralı numaralar, gönderim zamanı, yanıt alınıp alınmadığı ve uygulamanın bunu ayrıştırıp ayrıştıramadığı. Bunlar, sağlayıcı yanıt şeması değil, uygulama tarafından sahip olunan önerilen tanılardır. Tam tanımlayıcıları ve kimlik bilgilerini kurumun günlük tutma politikasına uygun olarak koruyun. Genel API, gerçek zamanlı sorgular için artı ön ekli bir E.164 numarasını kabul eder; format reddi, zaman aşımı yeniden deneme döngüsüne değil, hazırlık aşamasına geri dönmelidir.
Tekil bir istek için, belgelenmiş tamamlanmış bir yanıtı, belirsiz bir servis sonucundan ve istemci tarafından gözlemlenen yanıt yok durumundan ayırt edin. Ekip, istemci tarafındaki bir zamanlayıcının sunucunun ne yaptığını kanıtladığını varsaymamalıdır. API dokümantasyonu, kesin iş kodları ve zaman aşımı davranışı için yetkili kaynaktır.
Hata durumu tablosu kullanın
Kompakt bir karar tablosu, operasyonel etiketleri tutarlı tutar. Aşağıdaki eylemler müşteri tarafı önerileridir; otomatik CarrierLookup yeniden deneme davranışı iddiası taşımazlar.
| Gözlemlenen durum | Yorumlama | Sonraki eylem |
|---|---|---|
| Operatör bağlamı içeren tamamlanmış yanıt | Orijinal tahsis için normal sonuç | Kaynak ve sorgu zamanı ile saklayın |
| Boş operatör alanları içeren tamamlanmış yanıt | Kullanılamayan değerlerle tamamlanmış sorgu | Boş değerleri koruyun; gerekirse inceleyin |
| Reddedilen E.164 girişi | İstek giriş formatını karşılamadı | Yeni bir çağrıdan önce girişi düzeltin |
| Belirsiz servis sonucu | Normal operatör sonucu yok | Ekibin açık yeniden deneme veya inceleme kuralını izleyin |
| İstemci iletim zaman aşımı | Tamamlanma yerel olarak bilinmiyor olabilir | Denemeyi koruyun ve sonuç iddia etmekten kaçının |
| Çoklu istek zaman aşımı | Tüm çoklu istek başarısız oldu, kısmi satır yok | Kurtarma için gönderilen tüm tanımlayıcıları bir arada tutun |
Tablo, eksik bir operatörün varsayılan yorumu olarak "geçersiz numara" ifadesinden bilinçli olarak kaçınır. CarrierLookup bir numara geçerliliği veya erişilebilirlik ürünü değildir. Belirsiz veya başarısız bir sorgu, kullanıcı arayüzünde yalnızca bir durum rozeti için yer olsa bile, tamamlanmış bir sorgudan ayrı tutulmalıdır.
Çoklu isteği bir bütün olarak kurtarın
Senkronize çoklu sorgular, tek bir istekte sıralı bir E.164 numarası listesi alır. Belgelenmiş çoklu zaman aşımı, tüm isteği kısmi sonuçlar olmadan başarısız kılar ve tam tutarı döndürür. Bu nedenle bir istemci, bir ilerleme göstergesi hareket ettiği veya benzer tanımlayıcılara sahip önceki bir çağrı sonuç verdiği için ilk kısmın başarılı olduğunu varsaymamalıdır. Tam sıralı girişi ve deneme sonucunu saklayın. Müşteri politikası yeniden denemeye izin veriyorsa, aynı işe bağlı yeni bir deneme oluşturun ve tam döndürülen listeyi yalnızca o yeni yanıt geldikten sonra mutabık kılın.
Normal bir çoklu yanıt alınırsa, iletişim kayıtlarını güncellemeden önce bildirilen toplamları ve sıralı sonuçları mutabık kılın. Bireysel exists=false girişleri, o konum için normal bir sonuç olmadığını gösterir; geçersiz, bağlantısı kesilmiş veya operatörü olmayan bir numaranın kanıtı değildir. Bu bayrağı toplu CSV yorumuna kopyalamayın; toplu dosya çıktısı kendi sözleşmesini kullanır. Öğe bazlı durumu, operatör alanlarından bağımsız olarak koruyun.
Uygulama ayrıca eski yazmalara karşı da korunmalıdır. İstek iletim halindeyken bir kişinin telefon numarası değiştiyse, herhangi bir sonuç uygulamadan önce gönderilen değeri mevcut kayıtla karşılaştırın. Bir zaman aşımı kurtarma yolu, normal başarılı bir yanıt için kullanılan bütünlük kontrolünü atlamamalıdır.
Kanıt ve maliyet etrafında bir yeniden deneme politikası tanımlayın
Yeniden deneme, eski bir yanıttaki eksik değerlerin onarımı değil, yeni bir sorgu denemesidir. Hangi durumların uygun olduğunu, müşteri uygulamasının kaç denemeye izin verdiğini ve kalıcı belirsizliği kimin inceleyeceğini tanımlayın. Bunlar uygulama tercihleridir; bunları belgelenmemiş sağlayıcı sınırları veya garantileri olarak tanımlamayın. Hesabın paylaşılan gerçek zamanlı yuvaları için rekabet eden ani paralel yeniden denemelerden kaçının. Genel API eşzamanlılık kontrollerini belgeler, bu nedenle yeniden denemeler yeni işlerle aynı kuyruktan geçmelidir.
Tüm operatör alanları boş olan tamamlanmış sıfır kodlu bir sonuç yine de ücretlendirilebilir. Başarısız veya belirsiz sorgular, belgelenmiş faturalandırma gerçekleri kapsamında bir ücret tutmaz. Bu ayrım operasyonel mutabakat için yararlıdır, ancak bu makale bir tutar belirtmez veya teknik bir zaman aşımlı durumu bir satın alma iadesi vaadine dönüştürmez. Faturalandırma durumu ve sonuç anlamı ayrı ayrı incelenmelidir.
Bir olaydan sonra, deneme günlüğünü üç hata için örnekleyin: boş operatör sonuçları olarak sunulan zaman aşımları, kısmi başarılar olarak ele alınan çoklu istekler ve numarası değişen kişilere uygulanan yeniden denemeler. Eşlemeyi düzeltin ve yalnızca ekibin politikasının izin verdiği durumları tekrar oynatın. Sağlam bir kurtarma sürecinin sonucu, her numaranın sonunda bir operatör değeri vereceği iddiası değil, dürüst bir kanıt izidir.
Müşteriye yönelik durum dilini, dahili durum kadar dikkatli tutun. "Sorguyu tamamlayamadık" ifadesi, "operatör bulunamadı" ifadesinden farklıdır. Bir incelemeci, bu durumu deneme kaydına kadar takip edebilmeli, yeni bir deneme yapılıp yapılmadığını anlayabilmeli ve nihayetinde hangi sonucun kullanıldığını görebilmelidir. Bu küçük disiplin, bir iletim olayının CRM'de yanlış bir veri kalitesi sonucuna dönüşmesini engeller.
SSS
Çoklu zaman aşımı kısmi operatör sonuçları döndürür mü?
Hayır. Belgelenmiş senkronize çoklu zaman aşımı, tüm isteği kısmi sonuçlar olmadan başarısız kılar.
Boş bir operatör alanı zaman aşımı ile aynı mıdır?
Hayır. Tamamlanmış bir sorgu, kullanılamayan operatör alanlarına sahip olabilir ve yine de tamamlanmış, ücretlendirilebilir bir sonuç olabilir.
Ekipler yeniden denemeden önce neleri saklamalıdır?
Gönderilen kanonik tanımlayıcıları, modu, deneme zamanını ve gözlemlenen hata durumunu saklayın, ardından açık bir müşteri yeniden deneme politikası uygulayın.
Zaman aşımı, bir telefon numarasının operatörü olmadığını kanıtlayabilir mi?
Hayır. Normal bir operatör sonucu sağlamaz ve operatör sorgulama, numara geçerliliğini veya erişilebilirliğini belirlemez.
Daha Fazla Bilgi
İş akışınızdaki bir sonraki adıma uygun ürün bilgilerini seçin.