SAP CPI میں نامعلوم headers اور properties کو خاموشی سے fail ہونے سے پہلے پکڑنا

جو header کبھی سیٹ ہی نہ ہو وہ SAP CPI کے iFlow کو نہیں روکتا۔ اسے پڑھنے والا expression خالی value واپس کرتا ہے، Router کی شرط false ہو جاتی ہے، payload کا کوئی field خالی رہ جاتا ہے، اور message آگے بڑھتا رہتا ہے۔ Error، اگر آتا بھی ہے، تو کئی steps بعد یا receiving سسٹم میں آتا ہے۔

یہ مضمون بتاتا ہے کہ غائب headers اور exchange properties خاموشی سے کیوں fail ہوتے ہیں، کون سی وجوہات بار بار سامنے آتی ہیں، اور کون سی جانچ انہیں کسی message سے پہلے پکڑ لیتی ہے۔

غائب نام error کیوں نہیں دیتا

Apache Camel غیر موجود header یا property کو غلطی نہیں بلکہ خالی سمجھتا ہے۔ اختیاری values کے لیے یہ سہولت ہے، اور یہی وجہ ہے کہ کوئی typo مہینوں تک iFlow میں رہ سکتا ہے۔ آپ کو کیا نظر آتا ہے، یہ اس پر منحصر ہے کہ نام کہاں پڑھا جا رہا ہے:

• Content Modifier کی کوئی value جیسے ${property.orderId} خالی string بن جاتی ہے۔
• Router یا Filter کی کوئی شرط جیسے ${header.orderType} = 'EXPRESS' false ہو جاتی ہے، اس لیے message کوئی دوسرا route لیتا ہے، اکثر default والا۔
• Receiver کا address جیسے /orders/${property.orderId}، /orders/ کو call کرتا ہے، اور receiving سسٹم ایسا error دیتا ہے جس میں غائب property کا ذکر ہی نہیں ہوتا۔
• Groovy script میں message.getHeader("orderId", String) null واپس کرتا ہے، اور script بعد میں null pointer error سے fail ہوتا ہے، یا payload میں null کا لفظ لکھ دیتا ہے۔

عام وجوہات

• Typo، یا property کے نام میں غلط case: exchange property کے نام case-sensitive ہیں، اس لیے orderID اور orderId دو الگ properties ہیں۔ Header کے نام case-sensitive نہیں ہیں۔
• فالتو space، مثلاً ${header.orderId }: space والا نام ایک مختلف نام ہے۔
• کوئی value جو Router کے صرف ایک route پر سیٹ ہو اور 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 پڑھے، جو header ٹیبل کو property ٹیبل سے پہلے چلاتا ہے۔

غائب value کو واضح طور پر fail کروائیں

جن values کے بغیر flow کام نہیں کر سکتا، ان کے لیے تین steps بعد نہیں بلکہ اسی جگہ fail کریں جہاں ان کی ضرورت ہے۔ 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 کی شرائط کے لیے default route کا مقصد واضح رکھیں: جب ہر message کو لازماً کسی نہ کسی route سے میل کھانا چاہیے تو default route کو Error End event پر ختم کریں، بجائے اس کے کہ message اس راستے پر چلتا رہے جو fallback کے طور پر بنایا گیا تھا۔

Testing کے دوران iFlow کا log level ‏Trace پر سیٹ کریں۔ Trace ہر step پر headers اور exchange properties دکھاتا ہے، تاکہ آپ بالکل دیکھ سکیں کہ کوئی value کہاں غائب ہوتی ہے۔

ڈپلائے کرنے سے پہلے ایک checklist

1. iFlow جو بھی header اور property پڑھتا ہے سب کی فہرست بنائیں: expressions، شرائط، adapter fields اور scripts میں۔
2. ہر ایک کے لیے وہ step تلاش کریں جو اسے سیٹ کرتا ہے، ہر اس path پر جو پڑھنے والی جگہ تک پہنچتا ہے۔
3. Spelling کا بالکل درست موازنہ کریں، properties کے case اور کسی بھی space سمیت۔
4. Sender سے آنے والے headers کے لیے چیک کریں کہ وہ Allowed Header(s) میں موجود ہیں۔
5. دوسرے iFlow سے آنے والی values کے لیے چیک کریں کہ وہ headers کے طور پر آ رہی ہیں، properties کے طور پر نہیں۔

بڑے iFlow پر یہ کام ہاتھ سے کرنے میں وقت لگتا ہے، اسی لیے یہ پہلی جانچ ہے جسے خودکار بنانا فائدہ مند ہے۔

ناموں کی عادتیں جو اس مسئلے سے بچاتی ہیں

• ایک انداز چنیں، جیسے camelCase، اور package کے ہر header اور property کے لیے وہی استعمال کریں۔
• جن values پر پورا flow منحصر ہے انہیں شروع کے قریب ایک ہی Content Modifier میں سیٹ کریں، تاکہ دیکھنے کی ایک ہی جگہ ہو۔
• SAP_ اور Camel prefixes کو SAP اور Apache Camel کے لیے چھوڑ دیں؛ اپنے ناموں کو مختلف شکل دیں۔
• Properties صرف اسی iFlow کی ضرورت والی values کے لیے، اور headers صرف ان values کے لیے استعمال کریں جنہیں iFlow سے باہر جانا ہو۔

Camel Simple expressions والا مضمون اس فہرست کے ہر نام کے پیچھے کا syntax بیان کرتا ہے۔

Kitegra کیسے مدد کرتا ہے

Kitegra براؤزر ایکسٹینشن یہی checklist، SAP Integration Suite ڈیزائنر میں چلاتی ہے۔ اس کا lint panel ڈپلائے سے پہلے ایسے headers اور properties کی نشاندہی کرتا ہے جنہیں iFlow میں کچھ بھی سیٹ نہیں کرتا، نیز expressions میں بند نہ کیے گئے ${ اور فالتو spaces کی۔

جب آپ ${ یا $ لکھتے ہیں تو یہ صرف وہی نام تجویز کرتی ہے جو iFlow متعین کرتا ہے، Groovy اور JavaScript scripts میں سیٹ کیے گئے ناموں سمیت، اور ساتھ SAP اور Camel کے standard headers، اس لیے typo کا امکان شروع ہی سے کم ہو جاتا ہے۔ جو نام صرف کچھ paths پر سیٹ ہوتا ہے اس پر «صرف کچھ راستوں پر سیٹ ہوتا ہے» کا نشان لگتا ہے۔ ایکسٹینشن کبھی کسی iFlow کا مواد محفوظ، ڈپلائے یا ایڈٹ نہیں کرتی، اور آپ کا tenant صرف تب بدلتا ہے جب آپ چار نامزد اقدامات میں سے کسی ایک پر کلک کریں، جنہیں بند کیا جا سکتا ہے۔

جب runtime پر کوئی value خالی ہو تو message کو مرحلہ وار trace کرنا ہر step سے پہلے کے headers اور properties دکھاتا ہے، اور iFlow ریویو چیک لسٹ اس کے پیچھے چھپی ڈیزائن کی غلطیوں کا احاطہ کرتی ہے۔

Kitegra اکاؤنٹ کے بغیر یہ ہر ماڈیول میں 5 iFlows پر کام کرتی ہے۔ Free پلان میں 50، Starter میں 100 اور Pro میں 300 iFlows شامل ہیں؛ Business میں کوئی حد نہیں۔ پلانز کا موازنہ کریں۔

اپنے اگلے iFlow میں آزمائیں

پڑھیں کہ Kitegra، SAP Integration Suite کے ڈیزائنر میں کیا کرتا ہے، یا اسے Kitegra کی دوسری Chrome ایکسٹینشنز کے ساتھ دیکھیں۔

اکثر پوچھے جانے والے سوالات