SAP CPI OData receiver: $select, $filter, $expand और $orderby बिना typo के

SAP CPI का OData receiver adapter एक Resource Path और query options की एक line को OData service की call में बदल देता है, जैसे SAP S/4HANA की कोई API। Query options तय करते हैं कि कौन-से fields, rows और related entities लौटेंगे, और service को call ठुकराने के लिए एक गलत लिखा property name ही काफ़ी है।

यह लेख एक उदाहरण के साथ $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 service के metadata से दोनों बना सकता है, और वह metadata, यानी EDMX फ़ाइल, iFlow के resources में सहेजता है।

Query options में Simple expressions हो सकते हैं, इसलिए values message से आ सकती हैं, जैसे $filter=SoldToParty eq '${property.customerId}'। नीचे का उदाहरण API_SALES_ORDER_SRV से, जो एक OData V2 service है, 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 एक ही line में लिखे जाते हैं; यहाँ उन्हें सिर्फ़ पढ़ने में आसानी के लिए तोड़ा गया है।

चारों options, एक-एक करके

$top और $skip नतीजे को सीमित करते हैं और pages में बाँटते हैं। OData V2 में expand की गई entity की property को path से चुना जाता है, जैसे to_Item/Material, और navigation property का $expand में होना भी ज़रूरी है।

$filter के अपने operators हैं: eq, ne, gt, ge, lt, le, जिन्हें and, or और not से जोड़ा जाता है। Text values single quotes में लिखी जाती हैं, और तारीखों को उस literal रूप की ज़रूरत होती है जो service का version अपेक्षित करता है।

OData V2 और V4 अलग तरह से लिखे जाते हैं

OData adapter दोनों versions को support करता है, और 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।
• Text के अंदर खोजना: V2 में substringof('Smith',CustomerName), V4 में contains(CustomerName,'Smith')। ध्यान दें कि arguments का क्रम उल्टा है।
• तारीखें: V2 में datetime'2026-01-01T00:00:00' लिखा जाता है; V4 में value बिना prefix के।
• Expand की गई properties: V2 उन्हें path से चुनता है; V4 options को expand के अंदर nest करता है, जैसे $expand=_Item($select=Product,Quantity)।

HTTP 400 देने वाले typos

जब कोई query option गलत होता है, तो service आमतौर पर HTTP 400 के साथ जवाब देती है और वह हिस्सा बताती है जिसे वह पढ़ नहीं सकी। इसके पीछे की गलतियाँ लगभग हमेशा वही होती हैं:

• गलत case: OData के नाम case-sensitive होते हैं, इसलिए soldToParty और SoldToParty एक नहीं हैं।
• Navigation property की जगह entity set: $expand=to_Item की जगह $expand=A_SalesOrderItem।
• ऐसी property जो किसी दूसरी entity पर है, या सिर्फ़ service के किसी दूसरे version में है।
• Text values के आसपास quotes छूट जाना, या V4 service को V2 का date literal भेजना।
• Separator की समस्या: options & से जुड़ते हैं, और हर option का नाम $ से शुरू होता है।

Expressions अपना जोखिम जोड़ते हैं: अगर ${property.customerId} खाली है, तो filter SoldToParty eq '' बन जाता है और error देने के बजाय चुपचाप कोई row नहीं लौटाता। Simple expressions वाला लेख बताता है कि ये values कैसे पढ़ी जाती हैं।

Query और service को आपस में मेल में रखें

• नामों के लिए iFlow के resources में मौजूद EDMX को source of truth मानें, और service बदलने पर उसे refresh करें।
• केवल वही fields select करें जिन्हें आप map करते हैं; छोटा response तेज़ होता है और trace में पढ़ना आसान होता है।
• बड़े reads के लिए एक विशाल response की जगह adapter का pages में process करने वाला option इस्तेमाल करें।
• Query को एक बार उन्हीं values के साथ test करें जो असली message उसमें डालेगा।

OData service की जगह REST API call कर रहे हैं? Postman और OpenAPI वाला लेख HTTP receiver को समझाता है।

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

Kitegra browser एक्सटेंशन OData receiver channel के लिए वह EDMX पढ़ता है जो आपके iFlow में पहले से मौजूद है। डिज़ाइनर में यह उसी EDMX से Resource Path और $select, $filter, $expand और $orderby के लिए property और navigation names सुझाता है, इसलिए आप नाम टाइप करने के बजाय चुनते हैं।

इसका lint panel ऐसे OData नाम चिह्नित करता है जो EDMX में नहीं हैं, साथ ही बंद न किए गए ${ और ऐसे headers या properties जिन्हें कुछ भी सेट नहीं करता। अगर किसी channel को सुझाव नहीं मिल रहे, तो जाँचें कि उसका EDMX iFlow के resources में है। एक्सटेंशन किसी iFlow का content कभी सहेजता, deploy या edit नहीं करता, और आपका tenant सिर्फ़ तब बदलता है जब आप चार नामित actions में से किसी एक पर क्लिक करते हैं, जिन्हें बंद भी किया जा सकता है।

OData service ने असल में क्या जवाब दिया, यह जाँचने के लिए message को step by step trace करें और call के बाद की body पढ़ें।

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

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

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

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