SAP Integration Suite Monitoring: PO’dan Geçişte 7 Zor Nokta

[İlayda Okan]

SAP Process Orchestration (PO) yıllarca entegrasyon ekiplerine belli alışkanlıklar kazandırdı: NWA, Message Monitor, Adapter Engine, XPI Inspector… Bu blogda ise, PO’dan Integration Suite’e geçenlerin monitoring tarafında en çok zorlandığı 7 noktayı, gerçek saha deneyimleriyle ele alıyorum.

1.“NWA Yok, Message MonitoringYok”​

PO’da:

• NWA → Message Monitoring

• Pipeline adım adım görünür

• Adapter bazlı izleme mümkün

Integration Suite’te ise:

• Web UI üzerinden izleme

• “Mesaj” yerine iFlow execution mantığı

• Adapter detayları daha soyut

PO’daki teknik detay görünürlüğü, Integration Suite’de bilerek sadeleştirilmiş. PO gibi “her byte’ı göreyim” yaklaşımı yerine, iş adımı bazlı izlemeye alışmak gerekiyor.

2.Trace Açtım Ama Hiçbir Şey Göremiyorum​

PO’da:

• Channel trace aç → payload akar

• Hata anında trace otomatik yardımcı olur

Integration Suite’de:

• Trace açmak yetmez

• Log level, MPL, Groovy logları birlikte çalışır

Gerekirse Content Modifier / Groovy log ile payload yazdırmak mümkün

3. Mesaj ID Değil, MPL ID Takibi​

PO dünyasında:

• Message ID = her şey

Integration Suite dünyasında:

• MPL ID (Message Processing Log)

• Parent / Child execution’lar

• Retry’larda yeni MPL oluşabilir

Bu da şu soruyu doğurur: “Bu mesajın aslı hangisi?” O nedenle, Correlation ID ve Custom Header’lar hayat kurtarır.

4.Adapter Hatası mı, iFlow Hatası mı?​

PO’da:

• Adapter Engine logları çok net

• Hata adapter bazında yakalanır

Integration Suite’de:

• Adapter hatası çoğu zaman iFlow içinde patlar

• Hata mesajı daha “generic” gelir

Örnek:

• HTTP 500

• Error during message processing

Gerçek sebep çoğu zaman:

• Mapping

• Groovy

• Header eksikliği

Öneri: iFlow’u küçük ve okunur adımlar halinde tasarlamak monitoring’i ciddi kolaylaştırır.

5.Retry Mantığı PO’dan Çok Farklı​

PO’da:

• EO / EOIO

• Adapter retry ayarları

• Net senaryolar

Integration Suite’de:

• Otomatik retry

• Exception Subprocess

• JMS queue opsiyonları

Retry edilen mesaj bazen “kaybolmuş gibi” hissedilir ama aslında kuyruktadır.

6. Payload Her Zaman Görünmez (ve bu bilerek olabilir)​

PO’da payload neredeyse her zaman erişilebilirdi.

Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.

ise: Güvenlik & performans nedeniyle Payload visibility kısıtlı olabilir (Özellikle prod ortamlarda) Bu büyük hacimli sistemlerde bilinçli bir tercih Çözüm:

• Selective logging

• Hata anında payload capture

7.“Bu Hatayı Nerede Alıyorum?” Sorusu​

PO’da stack trace okumaya alışmış ekipler, Integration Suite’deki kısa hata mesajlarından rahatsız olur. Ama IS’de:

• Hata yeri genelde adım bazında

• iFlow dizaynı iyi ise hata çok hızlı bulunur

Asıl fark:

• PO = teknik debug

• IS = tasarım + akış okuma

Özetle, “PO’da debug ediyorduk, IS’de tasarlıyoruz.” demek mümkün.

Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.