SAP CPI میں OData Receiver: $select، $filter، $expand اور $orderby بغیر typos کے

SAP CPI کا OData receiver adapter ایک Resource Path اور query options کی ایک لائن کو کسی OData سروس، جیسے SAP S/4HANA کی کسی API، کی call میں بدل دیتا ہے۔ Query options طے کرتے ہیں کہ کون سے fields، rows اور متعلقہ entities واپس آئیں، اور کسی ایک property کے نام کا غلط لکھا جانا ہی سروس کے call رد کرنے کے لیے کافی ہے۔

یہ مضمون ایک مثال کے ذریعے $select، $filter، $expand اور $orderby کو دیکھتا ہے، OData V2 اور V4 کے وہ فرق بتاتا ہے جن پر لوگ اکثر الجھتے ہیں، اور یہ بھی کہ ناموں کو درست کیسے رکھا جائے۔

OData receiver میں query options کہاں جاتے ہیں

Adapter کے Processing tab میں آپ operation منتخب کرتے ہیں، پھر Resource Path سیٹ کرتے ہیں، یعنی وہ entity set یا entity جسے آپ call کرتے ہیں، اور Query Options، یعنی URL میں ? کے بعد کا سب کچھ۔ Adapter کا query wizard سروس کے metadata سے دونوں بنا سکتا ہے اور وہ metadata، یعنی EDMX فائل، iFlow کے resources میں محفوظ کرتا ہے۔

Query options میں Simple expressions ہو سکتے ہیں، اس لیے values message سے آ سکتی ہیں، مثلاً $filter=SoldToParty eq '${property.customerId}'۔ نیچے کی مثال API_SALES_ORDER_SRV سے، جو ایک OData V2 سروس ہے، sales orders ان کے items سمیت پڑھتی ہے:

Resource Path:  A_SalesOrder
Query Options:  $select=SalesOrder,SoldToParty,CreationDate,to_Item/SalesOrderItem,to_Item/Material
                &$expand=to_Item
                &$filter=SoldToParty eq '${property.customerId}' and CreationDate ge datetime'2026-01-01T00:00:00'
                &$orderby=CreationDate desc
                &$top=50

Adapter میں query options ایک ہی لائن ہوتے ہیں؛ یہاں انہیں صرف پڑھنے میں آسانی کے لیے الگ لائنوں میں لکھا گیا ہے۔

چاروں options، ایک ایک کر کے

$top اور $skip نتیجے کو محدود کرتے اور صفحات میں بانٹتے ہیں۔ OData V2 میں expand کی گئی entity کی property کو path سے select کیا جاتا ہے، جیسے to_Item/Material، اور navigation property کا $expand میں درج ہونا بھی ضروری ہے۔

$filter کے اپنے operators ہیں: eq، ne، gt، ge، lt، le، جنہیں and، or اور not سے جوڑا جاتا ہے۔ متن والی values سنگل quotes میں جاتی ہیں، اور تاریخوں کو اس literal شکل کی ضرورت ہوتی ہے جس کی سروس کا version توقع کرتا ہے۔

OData V2 اور V4 ایک طرح نہیں لکھے جاتے

OData adapter دونوں versions کو سپورٹ کرتا ہے، اور SAP کی بہت سی APIs دونوں میں موجود ہیں۔ ایک version کی query دوسرے میں copy کرنا غلطیوں کا ایک عام ذریعہ ہے:

OData V2:  $inlinecount=allpages
           $filter=substringof('Smith',CustomerName)
           $filter=CreationDate ge datetime'2026-01-01T00:00:00'

OData V4:  $count=true
           $filter=contains(CustomerName,'Smith')
           $filter=CreatedAt ge 2026-01-01T00:00:00Z
           $expand=_Item($select=Product,Quantity)

• Rows گننا: V2 میں $inlinecount=allpages، V4 میں $count=true۔
• متن کے اندر تلاش: V2 میں substringof('Smith',CustomerName)، V4 میں contains(CustomerName,'Smith')۔ دھیان دیں کہ arguments کی ترتیب الٹی ہے۔
• تاریخیں: V2 لکھتا ہے datetime'2026-01-01T00:00:00'؛ V4 یہ value بغیر prefix کے لکھتا ہے۔
• Expand کی گئی properties: V2 انہیں path سے select کرتا ہے؛ V4 options کو expand کے اندر رکھتا ہے، جیسے $expand=_Item($select=Product,Quantity)۔

وہ typos جو HTTP 400 کا سبب بنتے ہیں

جب کوئی query option غلط ہو تو سروس عموماً HTTP 400 کے ساتھ جواب دیتی ہے اور وہ حصہ بتاتی ہے جو وہ پڑھ نہیں سکی۔ اس کے پیچھے غلطیاں تقریباً ہمیشہ ایک جیسی ہوتی ہیں:

• غلط case: OData کے نام case-sensitive ہیں، اس لیے soldToParty اور SoldToParty ایک نہیں۔
• Navigation property کی جگہ entity set: $expand=to_Item کی بجائے $expand=A_SalesOrderItem۔
• ایسی property جو کسی دوسری entity میں، یا صرف سروس کے کسی دوسرے version میں موجود ہو۔
• متن والی values کے گرد quotes کا نہ ہونا، یا V4 سروس کو V2 کا date literal بھیجنا۔
• Separator کا مسئلہ: options کو & سے جوڑا جاتا ہے، اور ہر option کا نام $ سے شروع ہوتا ہے۔

Expressions اپنا الگ خطرہ لاتے ہیں: اگر ${property.customerId} خالی ہو تو filter بن جاتا ہے SoldToParty eq '' اور error کی بجائے خاموشی سے کوئی row واپس نہیں کرتا۔ Simple expressions والا مضمون بتاتا ہے کہ یہ values کیسے پڑھی جاتی ہیں۔

Query اور سروس کو ہم آہنگ رکھیں

• iFlow کے resources میں موجود EDMX کو ناموں کا مستند ذریعہ سمجھیں، اور سروس بدلنے پر اسے refresh کریں۔
• صرف وہی fields select کریں جنہیں آپ map کرتے ہیں؛ چھوٹا response تیز ہوتا ہے اور trace میں پڑھنا آسان۔
• بڑی reads کے لیے adapter کا وہ option استعمال کریں جو ایک بہت بڑے response کی بجائے صفحات میں process کرتا ہے۔
• Query کو ایک بار انہی values کے ساتھ test کریں جو کوئی حقیقی message اس میں ڈالے گا۔

OData سروس کی بجائے REST API کو call کر رہے ہیں؟ Postman اور OpenAPI والا مضمون HTTP receiver کا احاطہ کرتا ہے۔

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

Kitegra براؤزر ایکسٹینشن وہ EDMX پڑھتی ہے جو آپ کے iFlow میں OData receiver channel کے لیے پہلے سے موجود ہے۔ ڈیزائنر میں یہ اسی EDMX سے Resource Path، اور $select، $filter، $expand اور $orderby کے لیے property اور navigation کے نام تجویز کرتی ہے، تاکہ آپ نام ٹائپ کرنے کی بجائے منتخب کریں۔

اس کا lint panel ایسے OData ناموں کی نشاندہی کرتا ہے جو EDMX میں موجود نہیں، ساتھ ہی بند نہ کیے گئے ${ اور ایسے headers یا properties کی جنہیں کچھ بھی سیٹ نہیں کرتا۔ اگر کسی channel کو تجاویز نہ ملیں تو چیک کریں کہ اس کا EDMX، iFlow کے resources میں موجود ہے۔ ایکسٹینشن کبھی کسی iFlow کا مواد محفوظ، ڈپلائے یا ایڈٹ نہیں کرتی، اور آپ کا tenant صرف تب بدلتا ہے جب آپ چار نامزد اقدامات میں سے کسی ایک پر کلک کریں، جنہیں بند کیا جا سکتا ہے۔

OData service نے اصل میں کیا جواب دیا، یہ چیک کرنے کے لیے message کو مرحلہ وار trace کریں اور call کے بعد کی body پڑھیں۔

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

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

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

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