SAP CPI OData alıcısı: yazım hatası olmadan $select, $filter, $expand ve $orderby

SAP CPI'daki OData alıcı adaptörü, bir Resource Path'i ve bir satırlık sorgu seçeneklerini bir SAP S/4HANA API'si gibi bir OData hizmetine yapılan çağrıya dönüştürür. Sorgu seçenekleri hangi alanların, satırların ve ilişkili varlıkların döneceğini belirler ve tek bir yanlış yazılmış özellik adı, hizmetin çağrıyı reddetmesine yeter.

Bu makale $select, $filter, $expand ve $orderby seçeneklerini bir örnekle, birçok kişinin kafasını karıştıran OData V2 ile V4 farklarını ve adları doğru tutmanın yollarını ele alıyor.

OData alıcısında sorgu seçenekleri nereye yazılır

Adaptörün Processing sekmesinde işlemi seçer, ardından çağırdığınız entity set veya varlık olan Resource Path'i ve URL'de ? işaretinden sonra gelen her şey olan Query Options'ı ayarlarsınız. Adaptörün sorgu sihirbazı ikisini de hizmetin meta verilerinden oluşturabilir ve bu meta verileri, yani EDMX dosyasını, iFlow'un kaynaklarına kaydeder.

Sorgu seçenekleri Simple ifadeleri içerebilir; böylece değerler mesajdan gelebilir, örneğin $filter=SoldToParty eq '${property.customerId}'. Aşağıdaki örnek, bir OData V2 hizmeti olan API_SALES_ORDER_SRV üzerinden satış siparişlerini kalemleriyle birlikte okur:

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

Adaptörde sorgu seçenekleri tek bir satırda yer alır; burada yalnızca okunabilirlik için bölünmüştür.

Dört seçenek, tek tek

$top ve $skip sonucu sınırlar ve sayfalara böler. OData V2'de genişletilmiş bir varlığın özelliği to_Item/Material gibi bir yolla seçilir ve gezinme özelliğinin $expand içinde de yer alması gerekir.

$filter seçeneğinin kendi operatörleri vardır: eq, ne, gt, ge, lt, le; bunlar and, or ve not ile birleştirilir. Metin değerleri tek tırnak içine alınır ve tarihler, hizmet sürümünün beklediği literal biçimi gerektirir.

OData V2 ve V4 aynı şekilde yazılmaz

OData adaptörü her iki sürümü de destekler ve birçok SAP API'si her ikisinde de bulunur. Bir sorguyu bir sürümden diğerine kopyalamak sık görülen bir hata kaynağıdır:

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)

• Satır sayma: V2'de $inlinecount=allpages, V4'te $count=true.
• Metin içinde arama: V2'de substringof('Smith',CustomerName), V4'te contains(CustomerName,'Smith'). Bağımsız değişkenlerin ters sırada olduğuna dikkat edin.
• Tarihler: V2 datetime'2026-01-01T00:00:00' yazar; V4 değeri önek olmadan yazar.
• Genişletilmiş özellikler: V2 bunları bir yolla seçer; V4 ise seçenekleri $expand=_Item($select=Product,Quantity) örneğindeki gibi expand'in içine yerleştirir.

HTTP 400'e yol açan yazım hataları

Bir sorgu seçeneği hatalı olduğunda hizmet genellikle HTTP 400 ile yanıt verir ve okuyamadığı kısmı belirtir. Bunun arkasındaki hatalar neredeyse hep aynıdır:

• Yanlış büyük/küçük harf: OData adları büyük/küçük harfe duyarlıdır, yani soldToParty, SoldToParty değildir.
• Gezinme özelliği gereken yerde bir entity set: $expand=to_Item yerine $expand=A_SalesOrderItem.
• Başka bir varlıkta veya yalnızca hizmetin başka bir sürümünde bulunan bir özellik.
• Metin değerlerinin etrafında tırnak eksik ya da bir V4 hizmetine V2 tarih literali gönderilmiş.
• Ayırıcı sorunu: seçenekler & ile birleştirilir ve her seçeneğin adı $ ile başlar.

İfadeler kendi risklerini de getirir: ${property.customerId} boşsa filtre SoldToParty eq '' olur ve hata vermek yerine sessizce hiç satır döndürmez. Simple ifadeleri makalesi, bu değerlerin nasıl okunduğunu açıklar.

Sorguyu ve hizmeti uyumlu tutun

• Adlar için doğruluk kaynağı olarak iFlow kaynaklarındaki EDMX'i kullanın ve hizmet değiştiğinde onu güncelleyin.
• Yalnızca eşlediğiniz alanları seçin; daha küçük bir yanıt daha hızlıdır ve trace içinde daha kolay okunur.
• Büyük okumalarda tek ve devasa bir yanıt yerine adaptörün sayfalar halinde işleme seçeneğini kullanın.
• Sorguyu, gerçek bir mesajın içine koyacağı değerlerin tam aynısıyla bir kez test edin.

OData hizmeti yerine bir REST API mi çağırıyorsunuz? Postman ve OpenAPI makalesi HTTP alıcısını ele alıyor.

Kitegra nasıl yardımcı olur

Kitegra tarayıcı uzantısı, iFlow'unuzun bir OData alıcı kanalı için zaten içerdiği EDMX'i okur. Tasarımcıda bu EDMX'ten Resource Path'i ve $select, $filter, $expand ve $orderby için özellik ve gezinme adlarını önerir; böylece adları yazmak yerine seçersiniz.

Lint paneli EDMX'te bulunmayan OData adlarını, ayrıca kapatılmamış ${ ifadelerini ve hiçbir şeyin ayarlamadığı header'ları veya özellikleri işaretler. Bir kanal öneri almıyorsa, EDMX'inin iFlow kaynaklarında olup olmadığını kontrol edin. 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.

OData hizmetinin gerçekte ne yanıt verdiğini kontrol etmek için mesajı adım adım trace edin ve çağrıdan sonraki gövdeyi okuyun.

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