SAP CPI'da bilinmeyen header'lar ve özellikler: sessizce bozulmadan yakalayın

Hiç ayarlanmamış bir header, SAP CPI'daki bir iFlow'u durdurmaz. Onu okuyan ifade boş bir değer döndürür, bir Router koşulu yanlış olur, yükteki bir alan boş kalır ve mesaj yoluna devam eder. Hata, ortaya çıkarsa, birkaç adım sonra veya alıcı sistemde görünür.

Bu makale eksik header'ların ve exchange property'lerin neden sessizce bozulduğunu, tekrar tekrar karşılaşılan nedenleri ve bunları bir mesaj takılmadan önce yakalayan denetimleri anlatıyor.

Eksik bir ad neden hata vermez

Apache Camel, var olmayan bir header'ı veya özelliği hata olarak değil, boş bir değer olarak ele alır. Bu, isteğe bağlı değerler için kullanışlıdır ve bir yazım hatasının bir iFlow'da aylarca yaşayabilmesinin nedeni de budur. Ne göreceğiniz, adın nerede okunduğuna bağlıdır:

• ${property.orderId} gibi bir Content Modifier değeri boş bir dizeye dönüşür.
• ${header.orderType} = 'EXPRESS' gibi bir Router veya Filter koşulu yanlış olarak değerlendirilir; mesaj başka bir rotaya, çoğu zaman varsayılan rotaya gider.
• /orders/${property.orderId} gibi bir alıcı adresi /orders/ adresini çağırır ve alıcı sistem, eksik özellikten hiç söz etmeyen bir hatayla yanıt verir.
• Bir Groovy betiğinde message.getHeader("orderId", String) null döndürür ve betik daha sonra bir null pointer hatasıyla başarısız olur ya da yüke null metnini yazar.

Yaygın nedenler

• Bir özellik adında yazım hatası veya yanlış büyük/küçük harf: exchange property adları büyük/küçük harfe duyarlıdır, bu yüzden orderID ve orderId iki ayrı özelliktir. Header adları duyarlı değildir.
• Fazladan bir boşluk, örneğin ${header.orderId }: boşluklu ad başka bir addır.
• Bir Router'ın yalnızca bir rotasında ayarlanan ve rotalar yeniden birleştikten sonra okunan bir değer.
• Göndericinin yolladığı ama içeri alınmayan bir header: HTTPS göndericisi yalnızca iFlow'un Runtime Configuration bölümündeki Allowed Header(s) alanında listelenen özel header'ları içeri alır.
• Başka bir iFlow'dan beklenen bir özellik: exchange property'ler bir ProcessDirect çağrısından geçmez, yalnızca header'lar geçer (ProcessDirect ve JMS makalesine bakın).
• Aynı Content Modifier'da oluşturulan bir özelliği okuyan bir header satırı; Content Modifier header tablosunu özellik tablosundan önce işler.

Eksik bir değerin görünür biçimde başarısız olmasını sağlayın

Akışın onlarsız çalışamayacağı değerler için, üç adım sonra değil, ihtiyaç duyuldukları noktada hata verilmesini sağlayın. Akışın başında kısa bir Groovy adımı yeterlidir:

import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def orderId = message.getProperty("orderId")
    if (orderId == null || orderId.toString().trim().isEmpty()) {
        throw new IllegalStateException("Exchange property orderId is not set")
    }
    return message
}

Mesaj bu durumda, eksik özelliği adıyla anan bir cümleyle hata durumunda sona erer ve bu, mesaj işleme günlüğünde görünür. Router koşullarında varsayılan rotaya net bir amaç verin: Mesajın her zaman rotalardan birine uyması gerekiyorsa, mesajın yedek olarak düşünülmüş bir yoldan devam etmesine izin vermek yerine rotayı bir Error End olayıyla sonlandırın.

Test ederken iFlow'un günlük düzeyini Trace olarak ayarlayın. Trace her adımdaki header'ları ve exchange property'leri gösterir; böylece bir değerin tam olarak nerede kaybolduğunu görebilirsiniz.

Dağıtmadan önce bir kontrol listesi

1. iFlow'un okuduğu her header'ı ve özelliği listeleyin: ifadelerde, koşullarda, adaptör alanlarında ve betiklerde.
2. Her biri için, okunduğu noktaya ulaşan her yolda onu ayarlayan adımı bulun.
3. Özelliklerde büyük/küçük harf ve tüm boşluklar dahil, tam yazımı karşılaştırın.
4. Göndericiden gelen header'ların Allowed Header(s) içinde olduğunu kontrol edin.
5. Başka bir iFlow'dan gelen değerlerin özellik olarak değil, header olarak taşındığını kontrol edin.

Elle yapıldığında bu denetim büyük bir iFlow'da epey zaman alır; bu yüzden otomatikleştirmeye değecek ilk denetim budur.

Sorunu önleyen adlandırma alışkanlıkları

• camelCase gibi tek bir stil seçin ve paketteki tüm header'larda ve özelliklerde kullanın.
• Tüm akışın bağlı olduğu değerleri başlangıca yakın tek bir Content Modifier'da ayarlayın; böylece bakılacak tek bir yer olur.
• SAP_ ve Camel öneklerini SAP ve Apache Camel'e bırakın; kendi adlarınıza farklı bir biçim verin.
• Yalnızca bu iFlow'un ihtiyaç duyduğu değerler için özellik, yalnızca iFlow'dan çıkması gereken değerler için header kullanın.

Camel Simple ifadeleri makalesi, bu listedeki her adın arkasındaki söz dizimini açıklar.

Kitegra nasıl yardımcı olur

Kitegra tarayıcı uzantısı bu kontrol listesini SAP Integration Suite tasarımcısında uygular. Lint paneli, siz dağıtmadan önce iFlow'da hiçbir şeyin ayarlamadığı header'ları ve özellikleri, kapatılmamış bir ${ ifadesini ve ifadelerdeki fazla boşlukları işaretler.

${ veya $ yazdığınızda yalnızca iFlow'un ayarladığı adları (Groovy ve JavaScript betiklerinde ayarlananlar dahil) ve SAP ile Camel'in standart header'larını önerir; böylece yazım hatası daha baştan daha az olasıdır. Yalnızca bazı yollarda ayarlanan bir ad “Yalnızca bazı yollarda ayarlanır” olarak işaretlenir. Uzantı bir iFlow'un içeriğini asla kaydetmez, dağıtmaz veya düzenlemez; tenant'ınız yalnızca, kapatılabilen ve adı belli dört işlemden birine tıkladığınızda değişir.

Bir değer çalışma zamanında boşsa mesajı adım adım trace etmek her adımdan önceki header'ları ve özellikleri gösterir; iFlow inceleme kontrol listesi ise bunun arkasındaki tasarım hatalarını ele alır.

Kitegra hesabı olmadan modül başına 5 iFlow'da çalışır. Free planı 50, Starter 100 ve Pro 300 iFlow'u kapsar; Business'ta sınır yoktur. Planları karşılaştırın.

Bir sonraki iFlow'unuzda deneyin

Kitegra'ın SAP Integration Suite tasarımcısında neler yaptığını okuyun veya onu Kitegra'in diğer Chrome uzantılarıyla birlikte görün.

Sık sorulan sorular