Yetki · troubleshooting
Fiori OData aktivasyonu: servis açık değilse karo yalandır
Standart Fiori uygulaması UI5 kabuğu ve bir veya birkaç OData servisinden oluşur; kabuğu SICF’te açıp servisi /IWFND/MAINT_SERVICE’de bırakmak Could not open app veya boş tablo üretir. Aktivasyon uygulama kimliğiyle yürüyen bir listedir ve S_SERVICE olmadan servis aktif görünür, kullanıcı 403 yer.
/IWFND/MAINT_SERVICE’de bakılacaklar
Servisi eklerken add service sihirbazı backend modelini çeker, ICF düğümü üretir, system alias bağlar. Alias embedded senaryoda LOCAL veya yerel RFC’dir; hub’da backend SID’ye gider. Servis listesinde yeşil ICF, doğru alias ve error log’da taze 500 olmaması gerekir. Aynı servisin V2 ve V4 ailesi karıştırılmaz; Fiori Elements V4 uygulamasına V2 alias bağlamak metadata’yı kırar. /IWFND/ERROR_LOG aktivasyon sonrası ilk çağrıyı kaydeder. Fiori Apps Reference Library her uygulama için OData teknik adını verir; tahminle servis aramak yanlış ICF üretir. Fiori Teknoloji aktivasyonu Launch Pack teslimatının kapı maddesidir. Add Service sihirbazı ICF üretir ama üst yol kapalı kalabilir; SICF’te /sap/opu/odata yeşil değilse metadata 404’tür ve uygulama boş kuyruk gibi görünür, bu yüzden iki işlem kodu birlikte kapanır.
- Kaynak: Reference Library’deki OData teknik adı
- Yeşil ICF + doğru system alias + sürüm (V2/V4)
- İlk çağrı /IWFND/ERROR_LOG ile doğrulanır
S_SERVICE ve rol üretimi
Gateway, servis hash’ini S_SERVICE nesnesinde tutar. PFCG’de catalog atanınca bu hash’ler role yazılmalıdır; yazılmazsa yönetici servisi test eder, son kullanıcı açamaz. Hash, servis yeniden eklendiğinde değişebilir. Bu yüzden “dün çalışıyordu” kaydı aktivasyon tekrarından sonra sık görülür. STAUTHTRACE Launchpad’den uygulamayı açarken S_SERVICE alanlarını gösterir. SU53 tek çağrıyı kaçırır. Test kullanıcısı üretim rolünün kopyası olmalıdır. İstanbul ekiplerinde Gateway yetkisini Basis, backend nesnesini süreç ekibi sahiplenir; kopukluk kullanıcıda birleşir. Bağımsız destek bu iki kuyruğu tek kayıtta birleştirir. Catalog’dan türeyen S_SERVICE satırı rol üretilmeden transport’a girmez; test kullanıcısı eski rolü taşırsa yönetici yeşil, kullanıcı 403 görür ve kayıt “servis kapalı” diye yanlış açılır.
- S_SERVICE hash’i servis yeniden eklenince kayabilir
- Catalog ataması sonrası rolü yeniden üretin ve karşılaştırın
- Trace’i son kullanıcı senaryosuyla alın
Aktivasyon sonrası cache ve alias tuzakları
Servis taşındıktan sonra UI2 ve Gateway cache eski metadata’yı sunabilir. /UI2/DELETE_CACHE_AFTER_IMP catalog tarafını; tarayıcı ve SMICM HTTP cache metadata tarafını etkiler. Sistem kopyasında alias kaynak RFC’de kalır; servis aktif görünür, veri yanlış kutudan gelir veya hiç gelmez. My Inbox özelinde /IWPGW/TASKPROCESSING v2 ve yazılım sürümü /IWPGW/BWF ayrı kontrol edilir; genel OData yeşili Inbox’ı kanıtlamaz. Reverse proxy %2F decode ediyorsa $metadata yolu bölünür, aktivasyon “doğru” olsa da tarayıcı 404 görür. Kontrol sırası: Library adı, MAINT_SERVICE, SICF, alias, S_SERVICE, ERROR_LOG, cache. V2 servisine V4 uygulaması bağlamak annotation’ı kırar; Library’deki sürüm ailesi esas alınır, tahminle alias çoğaltmak kopya sonrasında ikinci SID’ye de sıçrar.
- Kopya: alias SID kontrolü aktivasyon kadar kritik
- Inbox servisi genel OData listesinden ayrı doğrulanır
- %2F ve cache, “servis açık ama ölü” görünümü üretir
Sık sorulanlar
Servisi Add Service ile ekledim, uygulama boş. Ne eksik?
Alias, S_SERVICE, CDS/backend yetkisi veya cache. /IWFND/ERROR_LOG ilk $metadata veya entity kümesini gösterir.
Aynı servisi iki kez eklemek gerekir mi?
Hayır. Çift kayıt alias ve ICF karmaşası doğurur. Mevcut kaydı düzeltin, yenisini silmeden önce bağımlı uygulamayı bilin.
Bu konuyu ortamınızda netleştirmek için 48 saatlik ön değerlendirme.
Lisans satmıyoruz. Destination, yetki ve model kararını yazılı notlarız.