Elements · informational
Fiori Object Page: bir kaydın iş ekranı nasıl kurulur?
Object Page, Fiori Elements’te tek bir iş nesnesinin başlık, facet ve aksiyonlarını gösteren floorplan’dir; List Report kuyruktur, Object Page karardır. Facet düzeni XML sayfası değil UI.Facets annotation’ıdır ve draft olmadan kaydet-kaybet çatışması GUI’deki gibi geri gelir.
Header, facet ve navigasyon
Header facet kimlik, durum ve ana tutarı taşır. UI.Facets alttaki sekmeleri veya bölümleri diziler: genel veri, kalemler, onay geçmişi, ekler. DataFieldForIntentBasedNavigation başka nesneye (örneğin siparişten teslimata) geçer; kırık semantic object Could not open app üretir. Hidden facet yetkiyle değil annotation ile gizlenir; hassas bölümü gizlemek için CDS yetkisi de gerekir. Fiori Horizon başlık yoğunluğunu değiştirir ama facet anlamını değiştirmez. İstanbul finans ekipleri Object Page’i “her şeyi tek ekrana yığma” diye kullanır; görev süresi düşer, kaydırma artar. Üç ila beş facet, nadir bilgi için ayrı intent daha okunur. Facet sayısını artırdıkça kaydet side effect’leri çoğalır; her bölüm için CDS association ve yetki ayrı düşünülmezse kullanıcı kaydırır, görev tamamlamaz ve GUI’ye döner.
- Header kimlik ve durum, facet görev bölümleridir
- Intent navigasyonu Object Page’den Object Page’e gider
- Gizleme annotation + CDS yetkisi birlikte düşünülür
Draft, kaydet ve eşzamanlı düzenleme
RAP draft, kullanıcının yarım kaydını sunucuda tutar. Object Page bu durumu Edit, Save, Discard ile gösterir. Draft yoksa her alan güncellemesi hemen backend’e gider; ağ hatası yarım belge bırakır. Exclusive lock ve etag çakışmayı yakalar; Fiori mesajı /IWFND/ERROR_LOG’daki business exception ile okunmalıdır. Side effect annotation bir alan değişince başka alanı yeniler; bunu UI5 event’ine yazmak Elements’i terk etmektir. Test senaryosu iki kullanıcının aynı Object Page’i açmasını içerir. Fiori Teknoloji draft’ı “konfor” değil veri bütünlüğü olarak kurar. Lisans satılmaz; behavior definition ortamınızda yazılır. Draft kuyruğu List Report’a sızmamalıdır, aksi halde onaycı yarım belgeyi işler; behavior tanımı ve UI annotation bu kuralı birlikte tutar, XML event ile tutulmaz.
- Draft yarım belgeyi sunucuda tutar
- Etag ve lock mesajı ERROR_LOG ile eşlenir
- Side effect annotation’dadır, custom event’te değil
Action, belirleme ve in-app alan
RAP action Object Page araç çubuğunda veya overflow’da durur. Onay, reddet, gönder gibi durum geçişleri kuyruk action’ından daha fazla bağlam ister; confirmation ve critical action annotation’ı yanlış tıklamayı keser. Custom field in-app extensibility ile header veya facet’e düşer; Adaptation Project aynı alanı başka bölüme taşıyabilir. İkisi de orijinal uygulamayı modify etmez. Z-view ile Object Page klonlamak yükseltmede çift bakım doğurur. Kabul kriteri: yetkisiz action gizli veya 403, yetkili action Object Page’i yeniler, taslak kaydı List Report’a yansımaz. Bu üçü yazılmadan Object Page “bitti” sayılmaz. Critical action confirmation olmadan yanlış tıklama belgesi geri alınamaz duruma getirir; test senaryosu yetkisiz 403, yetkili yenileme ve çakışan iki oturumu kapsar.
- Durum geçişi RAP action + confirmation
- Custom field in-app; yer değişimi Adaptation
- Kabul: 403, yenileme, draft’ın listeye sızmaması
Sık sorulanlar
Object Page’siz yalnızca List Report yeter mi?
Salt izleme kuyruğu için evet. Değişiklik, onay ve kalem bakışı için Object Page veya GUI gerekir.
Draft her uygulamada açılmalı mı?
Uzun form ve çok kullanıcılı belgelerde evet. Tek alanlı hızlı onayda draft maliyeti gereksiz olabilir; RAP’de bilinçli kapatılır.
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.