Bir parça arızalanmadan önce, veri bunu kaç ay önceden söyleyebilir?

Riski parça listesinde değil, trendde gör

Bir uçak motorunun parçaları aniden değil, aşama aşama bozulur — dönen kritik parçalar (LLP) çevrim biriktirir, egzoz gaz sıcaklığı (EGT) marjini yavaşça düşer. Bu proje, 21 gerçek motorluk bir filonun kullanım loglarını okuyup bu iki eğrinin nereye gittiğini hesaplayan uçtan uca bir SAP sistemi kuruyor: analitik CDS view katmanı, iki kestirimci ABAP OOP sınıfı ve bulguları tek ekranda toplayan bir Fiori Elements Analytical List Page.

Neler kuruldu

• ✓

  Katmanlı analitik CDS view mimarisi

  Dört view birbirinin üstüne kuruluyor: motor seviyesinde ZTEI_I_ELD_FLEET_HEALTH → parça kullanım oranını hesaplayan ZTEI_I_ELD_PART_USAGE → risk bandına çeviren ZTEI_I_ELD_PART_RISK → hepsini motor bazında birleştiren ZTEI_C_ELD_DASHBOARD.

• ✓

  Sunucu tarafı filtre, sıralama ve sayfalama

  Klasik SEGW GetEntitySet'te hiçbiri otomatik gelmiyor — IT_FILTER_SELECT_OPTIONS, IT_ORDER ve IS_PAGING elle okunup işlendi.

• ✓

  Object Page'de dört facet

  Kritik Parçalar (renkli risk göstergesi), Muayene Bulguları, Ömür Tahmini ve EGT Trend Tahmini — her biri kendi navigation property'siyle bağlı.

• ✓

  Türkçe durum ve risk metinleri

  Ham kodlar (A/R/Y) yerine Common.Text + UI.TextArrangement ile "Aktif"/"Kırmızı"/"Sarı" gösteriliyor — hem property hem entity seviyesinde annotasyon şart olduğu ortaya çıktı.

• ✓

  ALP grafik çökmesine framework seviyesinde düzeltme

  Analitik olmayan bir servise bağlı grafik, SAP'nin kendi getDrillStack() null-kontrolündeki boşluğu açığa çıkardı — Component.js'te beş satırlık bir guard ile giderildi.

• ✓

  Proje 2'nin filosuyla gerçek entegrasyon

  Yeni motor kayıtları uydurma bir filo değil, proje 2'nin gerçek 6 motor ailesi ve BOM verisine BOM_ID/NODE_ID üzerinden bağlı.

Loglardan tahmine: iki ABAP sınıfının kalbi

ZCL_TEI_ELD_FORECAST her kritik (LLP) parça için kalan çevrim ömrünü, ZCL_TEI_ELD_EGT_TREND ise her motorun EGT marjininin ne zaman Hot Section Inspection eşiğini geçeceğini hesaplıyor. İkisi de aynı temel mantığı izliyor: geçmiş kullanım logundan bir tüketim hızı çıkar, limitle arasındaki farkı bu hıza böl.

Bu iki ileriye dönük tahmin, Object Page'de iki tamamlayıcı görünümle destekleniyor: parçaların anlık risk bandı ve motorun geçmiş muayene bulguları.

Dört tablo, proje 2'nin filosuna bağlı

Yeni tablolar fiziksel, seri numaralı motor örneklerini modelliyor; ama uydurma bir filo değiller — BOM_ID ve NODE_ID üzerinden proje 2'nin gerçek ZTEI_BOM_HEAD/ZTEI_BOM_ITEM verisine bağlanıyorlar.

Mock'ta görünmeyen hatalar, gerçek backend'de yakalandı

Bu proje bilinçli olarak diğer ikisinden daha fazla test içeriyor. Sebep basit: klasik SEGW'de GetEntitySet'i redefine ettiğinde OData'nın gönderdiği filtre, sıralama ve sayfalamayı elle işlemek zorundasın — mock sunucu (@sap-ux/ui5-middleware-fe-mockserver) bunların hepsini kendisi yaptığı için, eksik kalan kısım sadece gerçek backend'e bağlanınca ortaya çıkıyor. Filtre uygulanınca tüm tablo hücreleri boşalıyor, grafikte [object Object] beliriyordu — kök neden, sunucunun sayfalama toplam sayısını ($inlinecount) hiç bildirmemesiydi.

Ayrı bir katmanda, Forecast/EgtTrend entity'leri ilk kez bir UI'ya bağlandığında üç ayrı, birbirini gizleyen hata art arda çıktı: ABAP sınıfının snake_case alan adları (engine_sn) OData'nın PascalCase alanlarıyla (EngineSn) CORRESPONDING #( ) ile eşleşmediği için satırlar sessizce boş kalıyordu — hata yoktu, sadece "kayıt yok" görünüyordu. Bu üç hata sınıfını bir daha kaçırmamak için 10 ABAP Unit testi yazıldı.

Aynı disiplin filtre tarafında da geçerli: ALP'nin tablo seviyesindeki View Settings filtresi uygulanmadan önce ve sonra.

sonra

Denedik ve vazgeçtik: native analitik

İlk plan, gerçek sunucu-tarafı analitik toplama içindi: bir @Analytics.dataCategory: #CUBE + @Analytics.query: true CDS view çifti, Fiori Elements AnalyticalTable'a bağlanacaktı. İki gerçek deneme yapıldı — cube+query view'ı temiz aktive oldu ama otomatik üretilen OData servisinin $metadata'sı sürekli boş EntityContainer döndü; SEGW'nin "Redefine → ODP Extraction" yolu ise ODP arama diyaloğunda isimle arama olmadığı için tıkandı. İkisi de bu NPL deneme sisteminin native OData-V2-üzerinden-embedded-analytics yolunun uçtan uca açık olmadığına işaret ediyordu. Zaman kaybetmek yerine düz bir GridTable + istemci tarafı grafik toplamaya geçildi — çalışan, dürüst bir çözüm. Terk edilen CDS view'ları sistemden silindi ama kaynak kodu burada:

@Analytics.dataCategory: #CUBE
define view ZTEI_I_ELD_CUBE
  as select from ZTEI_C_ELD_DASHBOARD as Engine
{
  key Engine.EngineSn             as EngineSn,
      Engine.BomId                 as BomId,
      …

      @DefaultAggregation: #SUM
      Engine.TotalFlightHours      as TotalFlightHours,

      // Kucuk sayi = daha kotu (1=Kirmizi...3=Yesil), yani
      // bir grubun "en kotu" riskini bulmak icin MIN gerekir, MAX degil.
      @DefaultAggregation: #MIN
      Engine.WorstPartRiskRank     as WorstPartRiskRank
}

Neyle inşa edildi

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