Bir teknisyenin sertifikası süresi dolmadan önce, sistem bunu söyleyebiliyor mu?

Sertifika durumu asla manuel girilmiyor

Havacılık üretiminde bir özel sürecin (kaynak, NDT, ısıl işlem, kimyasal işleme) kalite sistemine uygun sayılması için, o süreci uygulayan teknisyenin sertifikasının güncel olması gerekir. Bu proje, sıfır veya daha fazla sertifikaya sahip teknisyenleri modelleyen iki seviyeli, draft özellikli bir RAP business object kuruyor — Status alanı hiçbir zaman elle set edilmiyor, her save işleminde geçerlilik tarihinden sunucu tarafında yeniden hesaplanıyor.

Neler kuruldu

• ✓

  Draft yönetimli managed RAP business object

  Composition ile bağlı Teknisyen (root) + Sertifika (child), tam create/edit/activate/discard draft yaşam döngüsüyle, strict(2) altında.

• ✓

  CDS view'lardan ayrılmış UI annotasyonları

  Tüm @UI annotasyonları, @Metadata.allowExtensions: true ile açılan ayrı Metadata Extension'larda tutuluyor — veri modeli ile UI katmanı temiz şekilde ayrılıyor.

• ✓

  Value Help ile süreç seçimi

  Sertifika oluştururken Süreç alanı serbest metin değil — NADCAP checklist referansları (AC71xx) taşıyan bir Özel Süreç ana verisinden seçiliyor.

• ✓

  Tek tıkla "Renew Certification" action'ı

  Sertifika listesindeki bir kaydı seçip tek butona basarak geçerlilik tarihini bugünden itibaren 2 yıl uzatıp Durum'u tekrar Aktif'e çeken özel bir RAP action.

• ✓

  İki seviyeli yetkilendirme

  Teknisyen root'unda global authorization, Sertifika'da authorization dependent by _Technician — RAP runtime'ın dependent authorization'da bile zorunlu tuttuğu ek handler'lar dahil (bkz. Mühendislik Notları).

Üç hook, tek behavior pool

Sertifika entity'sinin iş mantığı, RAP behavior implementation class'ında (ZBP_TEI_CERT_TECHNICIAN) üç ayrı hook türüyle uygulanıyor: kayıttan önce çalışan bir validation, her save'de otomatik çalışan bir determination, ve kullanıcının tetiklediği özel bir action.

İki seviyeli composition, bir referans entity

Teknisyen (root) sıfır veya daha fazla Sertifika'ya (child) composition ile sahip; her Sertifika ise bağımsız bir Özel Süreç referans kaydına association ile bağlı.

Her iki draft-özellikli entity'nin kendi draft tablosu var (ztei_cert_tech_d, ztei_cert_cert_d) — Özel Süreç referans entity'sinin draft'a ihtiyacı yok, sadece okunuyor.

Beş gerçek sorun, bulunup çözüldü

1. Fiori Elements preview'ı sıfır satır gösterdi, Data Preview'da veri vardı. CDS view'larda hiç @UI annotasyonu yoktu. Annotasyonları doğrudan CDS view'lara eklemek yerine, @Metadata.allowExtensions: true ile açılan ayrı Metadata Extension'lara taşındı — SAP'ın tam da bu ayrım için önerdiği pattern.

2. Hesaplanan bir Status renklendirme alanı draft tablosunu bozdu. Renk kodlu bir CriticalityStatus alanı (CASE status WHEN 'A' THEN 3 ...) planlanmıştı. strict(2) + draft altında, hesaplanan bir alan BDEF mapping'de yer alamıyor, ama draft tablosunda da eksik olamıyor — çözülemez bir kombinasyon. Bu geliştirme bilinçli olarak bırakıldı.

3. Yetkilendirme iki farklı nedenle iki kez çöktü. Önce Teknisyen'de authorization master (instance) ile — global authorization'a geçilip kendi handler'ı yazıldı. Bu Teknisyen'i düzeltti, ama Sertifika authorization dependent by _Technician olmasına rağmen aynı sınıf hatayla çöktü: RAP runtime, bağımlı entity'nin bile kendi (önemsiz de olsa) global-authorization handler'ını, sadece kendi özel action'ını yetkilendirebilmek için zorunlu tutuyor.

4. Bir karşılaştırma içindeki DATS aritmetiği sessizce derlenmiyor. ValidTo <= today + 90 geçerli değil; toplama önce ara bir değişkene atanıp, sonra karşılaştırılmalı.

5. Numaralama mantığı olmayan readonly bir key alanı boş kaydediliyordu. CertId arkasında bir numbering class olmadan readonly işaretlenmişti. Tam bir RAP numaralama sınıfı yazmak yerine, sertifika numaralarının gerçek dünyada da genelde sertifikayı veren kurumdan dışarıdan geldiği mantığıyla, alan zorunlu-kullanıcı-girişli yapıldı.

Neyle inşa edildi

Neyin gerçek, neyin gösterimsel olduğu