Gelen sağlama API'si sorunlarını giderme

Giriş

Bu belge, gelen sağlama API'si ile ilgili sık karşılaşılan hataları ve sorunları ve bunların nasıl giderilirlerini kapsar.

Sorun giderme senaryoları

Geçersiz veri biçimi

Sorun açıklaması

• HTTP 400 (Hatalı İstek) yanıt koduyla hata iletisini Invalid Data Format alıyorsunuz.

Olası nedenler

1. Provisioning /bulkUpload API belirtimlerine göre geçerli bir toplu istek gönderiyorsunuz, ancak HTTP istek başlığı olan 'Content-Type'ı application/scim+json olarak ayarlamamışsınız.
2. Provisioning /bulkUpload API spesifikasyonlarıyla uyumlu olmayan bir toplu istek gönderiyorsunuz.

Çözüm:

1. HTTP İsteği'nin üst bilgisinin Content-Type değerine application/scim+jsonayarlandığından emin olun.
2. Toplu istek yükünün sağlama /bulkUpload API belirtimlerine uygun olduğundan emin olun.

Sağlama günlüklerinde hiçbir şey yok

Sorun açıklaması

• Sağlama /bulkUpload API uç noktasına bir istek gönderdiniz ve HTTP 202 yanıt kodunu aldınız, ancak sağlama günlüklerinde isteğinize karşılık gelen veri yok.

Olası nedenler

1. API temelli sağlama uygulamanız duraklatıldı.
2. Sağlama hizmeti henüz sağlama günlüklerini toplu istek işleme ayrıntılarıyla güncelleştiremedi.
3. Eğer Şirket içi Active Directory'ye /API temelli gelen kullanıcı sağlamayı çalıştırıyorsanız, şirket içi sağlama aracınızın durumu etkin değil.

Çözüm:

1. Sağlama uygulamanızın çalıştığını doğrulayın. Çalışmıyorsa, verileri işlemek için Sağlamayı başlat menü seçeneğini belirleyin.
2. Şirket içi aracısını yeniden başlatarak Şirket içi sağlama aracısı durumunuzu etkin duruma getirin.
3. İsteği işleme ile sağlama günlüklerine yazma arasında 5 dakika ile 10 dakika arasında bir gecikme olmasını bekleyin. API istemciniz sağlama /bulkUpload API uç noktasına veri gönderiyorsa, istek çağırma ve sağlama günlükleri sorgusu arasında bir süre gecikmesi oluşturun.

Yasak 403 yanıt kodu

Sorun açıklaması

• Sağlama /bulkUpload API uç noktasına bir istek gönderdiniz ve HTTP 403 (Yasak) yanıt kodunu aldınız.

Olası nedenler

• Graph izni SynchronizationData-User.Upload API istemcinize atanmamış.

Çözüm:

• API istemcinize Graph iznini SynchronizationData-User.Upload atayın ve işlemi yeniden deneyin.

Çok fazla istek 429 yanıt kodu

bulkUpload API uç noktası aşağıdaki hız sınırlama limitlerini uygular ve bu limitler aşıldığında 429 durum kodu döndürür.

• 5 saniyede 40 API çağrısı – çağrı sayısı 5 saniyelik bir aralıkta bu sınırın ötesine geçerse istemci 429 yanıt alır. Bunu önlemenin bir yolu, istemci isteği gönderme mantığındaki gecikmeleri kullanarak istek gönderimini hızlandırmaktır. 

• 24 saatlik bir süre boyunca 6.000 API çağrısı – çağrı sayısı bu sınırın ötesine geçerse istemci 429 yanıtı alır. Bunu önlemenin bir yolu, SCIM toplu yükünüzün API çağrısı başına en fazla 50 kaydı kullanacak şekilde iyileştirildiğinden emin olmaktır. Bu yaklaşımla her 24 saatte bir 300.000 kayıt gönderebilirsiniz.

Demet tam 500 yanıt kodu

Sorun açıklaması

• SCIM istemcisi HTTP 500 (İç Sunucu Hatası) iletisini alır: "Alınan verileri depolayan demet dolu, lütfen alınan verileri işlemek için eşitleme hizmetinin gelmesini bekleyin ve bu isteği yeniden deneyin."
• Büyük İK veri kümeleri sağlama /bulkUpload uç noktasına gönderildiğinde, ilk eşitleme veya tam eşitleme döngüleri sırasında bu hatayı görebilirsiniz.

Bu hatanın oluşma nedeni

• "Bucket", kaynak sağlama hizmeti tarafından gelen /bulkUpload yüklerini işlenmeden önce arabelleğe almak için kullanılan geçici alım kuyruğudur.
• Her API odaklı sağlama görevinin kendine ait bir alma kuyruğu vardır.
• Sağlama hizmeti, kuyruğa alınan yükleri sürekli işler ve ardından işlenen verileri siler. Bu işleme ve silme döngüsü yetişemezse veya durursa, kuyruğa alınan veriler kova dolana kadar birikebilir.

Olası nedenler ve çözüm

Cause	Çözünürlük
Yük işleme, yanlış eşlemeler (örneğin, şirket içi Active Directory tarafından yönetilen Microsoft Entra ID özniteliklerini güncelleştirmeye çalışma) veya geçersiz veriler nedeniyle başarısız olur. Başarısız yükler kuyrukta kalır ve bu durum zamanla kovayı doldurabilir.	Başarısız istek işlemeyi belirlemek, eşleme veya veri sorunlarını düzeltmek, sağlama işini yeniden başlatmak ve istekleri yeniden göndermek için sağlama günlüklerini gözden geçirin.
API temelli sağlama işi Duraklatıldı veya Durduruldu durumundadır. İstekler kuyruğa almaya devam eder, ancak işleme çalışmaz.	Kuyruğa alınan istekleri işleyip temizleyebilmesi için sağlama görevini yeniden başlatın.
API temelli sağlama işi uzun süre Karantinaya alınmış durumda kalır. İstekler kuyruğa almaya devam eder, ancak işleme çalışmaz.	Karantinayı kaldırmak için provizyon işini yeniden başlatın. Yeniden başlatma sırasında, kuyruğa alınan mevcut veriler temizlenir ve bu da zaman alabilir. Yaklaşık 40 dakika bekleyin, ardından SCIM /bulkUpload isteklerini yeniden gönderin.
Kaynak sistemler, SCIM verilerini sağlama görevinin işleyebileceğinden daha hızlı gönderir.	Pace isteği gönderimi. Her toplu yüklemeden sonra HTTP durum kodunu denetleyin. HTTP 500 hatasını bucket-full iletisiyle alırsanız, yeniden denemeden önce istemciyi duraklatın (örneğin, 5 ila 10 dakika).

Yetkisiz 401 yanıt kodu

Sorun açıklaması

• Sağlama /bulkUpload API uç noktasına bir istek gönderdiniz ve HTTP 401 (Yetkisiz) yanıt kodunu aldınız. Hata kodunda "InvalidAuthenticationToken" iletisiyle birlikte "Erişim belirtecinin süresi doldu veya henüz geçerli değil" iletisi görüntüleniyor.

Olası nedenler

• Erişim belirtecinizin süresi doldu.

Çözüm:

• API istemciniz için yeni bir erişim belirteci oluşturun.

İş karantina durumuna girer

Sorun açıklaması

• Tedarik uygulamasını az önce başlattınız ve uygulama karantina durumunda bulunuyor.

Olası nedenler

• İşi başlatmadan önce bildirim e-postasını ayarlamamıştınız.

Çözüm:Sağlamayı Düzenle menü öğesine gidin. Ayarlar'ın altında Hata oluştuğunda e-posta bildirimi gönder'in yanında bir onay kutusu ve Bildirim E-postanızı girmeniz için bir alan bulunur. Kutuyu işaretlediğinizden, bir e-posta adresi girdiğinizden ve değişikliği kaydettiğinizden emin olun. İşi karantinadan çıkarmak için Sağlamayı yeniden başlat'a tıklayın.

Kullanıcı oluşturma - Geçersiz UPN

Sorun açıklaması Kullanıcı sağlama hatası var. Sağlama günlükleri şu hata kodunu görüntüler: AzureActiveDirectoryInvalidUserPrincipalName.

Çözüm:

1. Öznitelik Eşlemelerini Düzenle sayfasına gidin.
2. UserPrincipalName eşlemesini seçin ve RandomString işlevini kullanacak şekilde güncelleştirin.
3. Bu ifadeyi kopyalayıp ifade kutusuna yapıştırın: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Bu ifade, Microsoft Entra Id tarafından kabul edilen UPN değerine rastgele bir sayı ekleyerek sorunu giderir.

Kullanıcı oluşturulamadı - Geçersiz etki alanı

Sorun açıklaması Kullanıcı sağlama hatası var. Sağlama günlükleri, ifadesini domain does not existiçeren bir hata iletisi görüntüler.

Çözüm:

1. Öznitelik Eşlemelerini Düzenle sayfasına gidin.
2. Eşlemeyi UserPrincipalName seçin ve bu ifadeyi kopyalayıp ifade giriş kutusuna yapıştırın: Join("", Replace([userName], , "(?<Suffix>@(.)*)", "Suffix", "", , ), RandomString(3, 3, 0, 0, 0, ), "@", DefaultDomain())

Bu ifade, Microsoft Entra Id tarafından kabul edilen UPN değerine varsayılan bir etki alanı ekleyerek sorunu giderir.

Bilinen sınırlama: çok değerli adresler, e-postalar ve telefon numaraları

Sorun açıklaması

• API temelli sağlama, type değeri home veya work dışında başka bir değer olduğunda, şu anda addresses, emails ve phoneNumbers içindeki SCIM çok değerli özniteliklerini işlemez.
• Bu sınırlama , addresses[type eq "home"]ve addresses[type eq "any-other-value"]gibi phoneNumbers[type eq "home"]ifadeler için geçerlidir.

Geçerli davranış

• Yalnızca addresses[type eq "work"]ve emails[type eq "work"]phoneNumbers[type eq "work"] değerleri işlenir.

Workaround

• Özniteliğin API odaklı sağlama tarafından işlenmesini istediğinizde, desteklenen değerleri work türünü kullanarak gönderin.

Sonraki adımlar

• API temelli gelen sağlama hakkında daha fazla bilgi edinin