SAP CPI में अज्ञात headers और properties: चुपचाप fail होने से पहले पकड़ें

जो header कभी सेट ही नहीं हुआ, वह SAP CPI के iFlow को नहीं रोकता। उसे पढ़ने वाला expression खाली value लौटाता है, Router condition false हो जाती है, payload का कोई field खाली रह जाता है, और message आगे बढ़ जाता है। error, अगर आता भी है, तो कई steps बाद या receiving system में आता है।

यह लेख बताता है कि गायब headers और exchange properties चुपचाप क्यों fail होते हैं, कौन-से कारण बार-बार सामने आते हैं, और कौन-सी जाँचें उन्हें किसी message से पहले पकड़ लेती हैं।

गायब नाम error क्यों नहीं देता

Apache Camel किसी header या property के न होने को error नहीं, बल्कि खाली value मानता है। optional values के लिए यह सुविधाजनक है, और यही वजह है कि कोई typo महीनों तक iFlow में बना रह सकता है। आपको क्या दिखेगा, यह इस पर निर्भर करता है कि नाम कहाँ पढ़ा जाता है:

• ${property.orderId} जैसी Content Modifier value खाली string बन जाती है।
• ${header.orderType} = 'EXPRESS' जैसी Router या Filter condition false निकलती है, इसलिए message कोई दूसरा route लेता है, अक्सर default route।
• /orders/${property.orderId} जैसा receiver address /orders/ को call करता है, और receiving system ऐसे error के साथ जवाब देता है जिसमें गायब property का कोई ज़िक्र नहीं होता।
• Groovy script में message.getHeader("orderId", String) null लौटाता है, और script बाद में null pointer error के साथ fail होता है या payload में null शब्द लिख देता है।

आम कारण

• Property के नाम में typo या गलत case: exchange property के नाम case-sensitive होते हैं, इसलिए orderID और orderId दो अलग properties हैं। Header के नाम case-sensitive नहीं होते।
• एक फ़ालतू space, जैसे ${header.orderId }: space वाला नाम एक अलग नाम है।
• Router के सिर्फ़ एक route पर सेट की गई value, जिसे routes के फिर से मिलने के बाद पढ़ा जाता है।
• Caller (कॉल करने वाले) का भेजा header जिसे अंदर आने की अनुमति नहीं मिली: HTTPS sender केवल वही custom headers आने देता है जो iFlow की Runtime Configuration में Allowed Header(s) में लिखे हों।
• दूसरे iFlow से अपेक्षित property: exchange properties ProcessDirect call को पार नहीं करतीं, केवल headers करते हैं (ProcessDirect और JMS वाला लेख देखें)।
• Header row जो उसी Content Modifier में बनी property पढ़ती है, जबकि Content Modifier header table को property table से पहले चलाता है।

गायब value को साफ़ तौर पर fail कराएँ

जिन values के बिना flow काम नहीं कर सकता, उनके लिए वहीं fail करें जहाँ उनकी ज़रूरत है, तीन steps बाद नहीं। flow की शुरुआत में एक छोटा Groovy step काफ़ी है:

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
}

तब message ऐसे error के साथ खत्म होता है जिसमें गायब property का नाम होता है, और यह message processing log में दिखता है। Router conditions के लिए default route को एक साफ़ मकसद दें: जब हर message को किसी न किसी route से ज़रूर मेल खाना चाहिए, तो default route को Error End event पर खत्म करें, बजाय इसके कि message fallback के लिए बने रास्ते पर चला जाए।

Test करते समय iFlow का log level Trace पर रखें। Trace हर step पर headers और exchange properties दिखाता है, इसलिए आप ठीक-ठीक देख सकते हैं कि value कहाँ गायब होती है।

Deploy से पहले की checklist

1. iFlow जो भी header और property पढ़ता है, उन सबकी सूची बनाएँ: expressions, conditions, adapter fields और scripts में।
2. हर एक के लिए वह step खोजें जो उसे सेट करता है, उस हर route पर जो पढ़ने वाली जगह तक पहुँचता है।
3. सटीक spelling मिलाएँ, जिसमें properties का case और कोई भी space शामिल है।
4. Sender से आने वाले headers के लिए जाँचें कि वे Allowed Header(s) में हैं।
5. दूसरे iFlow से आने वाली values के लिए जाँचें कि वे properties नहीं, headers के रूप में आ रही हैं।

बड़े iFlow पर हाथ से यह जाँच करने में काफ़ी समय लगता है, इसीलिए यह पहली जाँच है जिसे automate करना फ़ायदेमंद है।

नामकरण की आदतें जो इस समस्या से बचाती हैं

• एक style चुनें, जैसे camelCase, और package के हर header और property में उसी का इस्तेमाल करें।
• जिन values पर पूरा flow निर्भर है, उन्हें शुरुआत के पास एक ही Content Modifier में सेट करें, ताकि देखने के लिए एक ही जगह हो।
• SAP_ और Camel prefixes SAP और Apache Camel के लिए छोड़ दें; अपने नामों को अलग रूप दें।
• जिन values की ज़रूरत सिर्फ़ इसी iFlow को है उनके लिए properties इस्तेमाल करें, और headers सिर्फ़ उन values के लिए जिन्हें बाहर जाना है।

Camel Simple expressions वाला लेख इस सूची के हर नाम के पीछे का syntax समझाता है।

Kitegra कैसे मदद करता है

Kitegra browser एक्सटेंशन यह checklist SAP Integration Suite डिज़ाइनर के अंदर ही चलाता है। इसका lint panel deploy से पहले ऐसे headers और properties जिन्हें iFlow में कुछ भी सेट नहीं करता, बंद न किए गए ${ और expressions में फ़ालतू spaces को चिह्नित करता है।

जब आप ${ या $ लिखते हैं, तो यह केवल वही नाम सुझाता है जो iFlow सेट करता है, जिनमें Groovy और JavaScript scripts में सेट किए गए नाम भी शामिल हैं, साथ में SAP और Camel के standard headers, इसलिए शुरू से ही typo की संभावना कम रहती है। जो नाम सिर्फ़ कुछ paths पर सेट होता है, उस पर "केवल कुछ पाथ पर सेट" का निशान लगा होता है। एक्सटेंशन किसी iFlow का content कभी सहेजता, deploy या edit नहीं करता, और आपका tenant सिर्फ़ तब बदलता है जब आप चार नामित actions में से किसी एक पर क्लिक करते हैं, जिन्हें बंद भी किया जा सकता है।

जब runtime पर कोई value खाली मिले, तो message को step by step trace करना हर step से पहले के headers और properties दिखाता है, और iFlow review checklist उसके पीछे की design गलतियों को कवर करती है।

Kitegra खाते के बिना यह हर मॉड्यूल में 5 iFlows पर काम करता है। Free प्लान में 50, Starter में 100 और Pro में 300 iFlows शामिल हैं; Business में कोई सीमा नहीं। प्लान की तुलना करें।

अपने अगले iFlow में आज़माएँ

पढ़ें कि Kitegra, SAP Integration Suite के डिज़ाइनर में क्या करता है, या इसे Kitegra के बाकी Chrome एक्सटेंशन के साथ देखें।

अक्सर पूछे जाने वाले प्रश्न