مواد پر جائیں
← بلاگ پر واپس جائیں

اس مضمون کا ماڈیول: Integration Flow Helper

Postman یا OpenAPI سے SAP CPI کے HTTP Receiver تک

OpenAPI یا Swagger spec یا Postman request کو SAP CPI کے HTTP receiver میں بدلیں: address، path اور query parameters، request headers اور expressions سے بنی JSON body۔

Postman یا OpenAPI سے SAP CPI کے HTTP Receiver تک

SAP CPI سے آپ جن REST APIs کو جوڑتے ہیں ان میں سے زیادہ تر کے ساتھ OpenAPI یا Swagger فائل، Postman collection، یا دونوں آتے ہیں۔ HTTP receiver adapter کو جو کچھ چاہیے وہ سب ان میں موجود ہے: server، path، parameters، headers اور body کی ساخت۔ کام بس یہ ہے کہ ہر حصہ کوئی حرف گرائے بغیر صحیح field میں پہنچایا جائے۔

یہ مضمون ایک OpenAPI operation اور ایک Postman request کو مرحلہ وار HTTP receiver پر map کرتا ہے، اور وہ تفصیلات بتاتا ہے جو اکثر پہلی call کو ناکام بنا دیتی ہیں۔

HTTP receiver کو کیا چاہیے

  • Address: operation کا مکمل URL۔ اس میں Simple expressions ہو سکتے ہیں، جیسے path parameter کے لیے ${property.orderId}۔
  • Query: ? کے بغیر query string، مثلاً notify=true۔
  • Method: ‏GET، POST، PUT، PATCH یا DELETE۔
  • Authentication: کوئی نہیں، Basic، Client Certificate، OAuth2 Client Credentials اور دیگر، tenant میں محفوظ credentials کے ساتھ، جو کبھی channel میں ٹائپ نہیں کیے جاتے۔
  • Request Headers: ان message headers کے نام جو API کو بھیجے جاتے ہیں، | سے الگ کیے ہوئے۔
  • Body: adapter تک پہنچتے وقت message body جو بھی ہو، عموماً Content Modifier یا mapping میں بنائی جاتی ہے۔

OpenAPI یا Swagger operation پڑھنا

یہ OpenAPI 3 operation لیں، جو کسی order کے لیے shipment بناتا ہے:

openapi: 3.0.3
servers:
  - url: https://api.example.com/v1
paths:
  /orders/{orderId}/shipments:
    post:
      parameters:
        - { name: orderId, in: path, required: true, schema: { type: string } }
        - { name: notify, in: query, schema: { type: boolean } }
        - { name: X-Request-Id, in: header, schema: { type: string } }
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                carrier: { type: string }
                trackingNumber: { type: string }
  1. Address: server URL اور path کو جوڑیں۔ Swagger 2.0 میں server، schemes، host اور basePath میں بٹا ہوتا ہے۔
  2. Path parameters جیسے {orderId}: ہر ایک کو expression سے بدلیں، مثلاً ${property.orderId}۔
  3. Query parameters (in: query): انہیں Query field میں منتقل کریں۔
  4. Header parameters (in: header): انہیں Content Modifier میں message headers کے طور پر سیٹ کریں اور ان کے نام Request Headers میں درج کریں۔
  5. Request body: requestBody کے تحت دیے گئے schema کے مطابق Content Modifier میں JSON بنائیں۔
  6. Security schemes: tenant میں متعلقہ credential بنائیں اور اسے Authentication کے تحت منتخب کریں۔

نتیجہ: ایک Content Modifier اور channel

اس operation کے لیے adapter سے پہلے والا Content Modifier اور HTTP receiver channel کچھ یوں نظر آتے ہیں:

Content Modifier
  Header   Content-Type   application/json
  Header   X-Request-Id   ${property.requestId}
  Body     {
             "carrier": "${property.carrier}",
             "trackingNumber": "${property.trackingNumber}"
           }

HTTP receiver
  Address           https://api.example.com/v1/orders/${property.orderId}/shipments
  Query             notify=true
  Method            POST
  Request Headers   Content-Type|X-Request-Id

Content Modifier، Content-Type header کو application/json پر، X-Request-Id header اور JSON body کو سیٹ کرتا ہے، جن کی values flow میں پہلے سیٹ کی گئی exchange properties سے لی جاتی ہیں۔ Request Headers میں بالکل وہی دو headers درج ہیں جو API کو ملنے چاہئیں، اس لیے باقی ہر header، tenant میں ہی رہتا ہے۔

Postman request سے

Postman request یہی معلومات مختلف جگہوں پر رکھتی ہے:

  • URL اکثر کسی Postman variable سے شروع ہوتا ہے جیسے {{baseUrl}}۔ SAP CPI میں یہی {{…}} syntax ایک externalized parameter کو ظاہر کرتا ہے، جو ڈپلائے کرتے وقت سیٹ ہوتا ہے: base URL کے لیے ایک فطری جگہ، جو test اور production میں بدلتا ہے۔
  • Path variables (:orderId) اور query parameters اوپر کی طرح Address اور Query fields پر map ہوتے ہیں۔
  • Headers tab، Content Modifier کے headers بن جاتا ہے، اور ان کے نام Request Headers میں جاتے ہیں۔
  • Raw JSON body، Content Modifier کی body بن جاتی ہے، جس میں ہر test value کی جگہ expression آتا ہے۔
  • Authorization tab بتاتا ہے کہ کون سی authentication ترتیب دینی ہے۔ Postman سے کوئی token کاپی کر کے iFlow میں نہ ڈالیں؛ credentials، tenant میں محفوظ کریں۔

تفصیلات جو پہلی call کو ناکام بناتی ہیں

  • Request Headers کو * پر سیٹ کرنا ہر message header، اندرونی headers سمیت، API کو بھیج دیتا ہے۔ صرف وہی headers درج کریں جن کی API توقع کرتی ہے۔
  • غائب یا غلط Content-Type header: بہت سی APIs، application/json کے بغیر JSON body کو رد کر دیتی ہیں۔
  • URL میں values کا URL-safe ہونا ضروری ہے: spaces یا slashes والی ID کو address میں ڈالنے سے پہلے encode کرنا ہوتا ہے۔
  • Error responses: Throw Exception on Failure بند ہو تو flow جاری رہتا ہے اور ${header.CamelHttpResponseCode} میں status code ہوتا ہے، اس لیے Router errors کو سنبھال سکتا ہے۔
  • JSON body میں field کے نام زیادہ تر APIs کے لیے case-sensitive ہوتے ہیں؛ انہیں یادداشت سے نہیں بلکہ schema سے کاپی کریں۔

اس کی بجائے OData سروس کو call کر رہے ہیں؟ OData receiver والا مضمون دیکھیں۔ Address اور body میں استعمال ہونے والے expressions کے لیے SAP CPI میں Camel Simple expressions دیکھیں۔

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

Kitegra براؤزر ایکسٹینشن API specification آپ کی طرف سے پڑھ لیتی ہے۔ اسے JSON یا YAML میں OpenAPI یا Swagger فائل، یا Postman collection دیں، اور یہ SAP Integration Suite ڈیزائنر میں اسی specification سے URLs، paths، query parameters، request headers اور مثالی JSON bodies تجویز کرتی ہے۔

Specification آپ کے براؤزر ہی میں رہتی ہے: Kitegra کبھی API specs محفوظ نہیں کرتا۔ ایکسٹینشن کبھی کسی iFlow کا مواد محفوظ، ڈپلائے یا ایڈٹ نہیں کرتی، اور آپ کا tenant صرف تب بدلتا ہے جب آپ چار نامزد اقدامات میں سے کسی ایک پر کلک کریں، جنہیں بند کیا جا سکتا ہے۔

اپنے iFlow کے HTTPS endpoint کو اسی طرح call کرنے کے لیے service key کے ساتھ HTTPS iFlow ٹیسٹ کرنا دیکھیں۔

Kitegra اکاؤنٹ کے بغیر یہ ہر ماڈیول میں 5 iFlows پر کام کرتی ہے۔ Free پلان میں 50، Starter میں 100 اور Pro میں 300 iFlows شامل ہیں۔ ٹیم پلانز پر ہر رکن کو Pro ملتا ہے، Startup Team پر ہر ماڈیول میں 300 iFlows کے ساتھ، اور Growth Team اور Scale Team پر کوئی حد نہیں۔ Kitegra کے لانچ کے دوران، سائن اِن کرنے والے ہر شخص کے لیے ہر ٹول کھلا ہے، Free پلان پر بھی۔ پلانز کا موازنہ کریں۔

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

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

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

کیا SAP CPI کسی OpenAPI فائل کو HTTP receiver میں import کر سکتا ہے؟

HTTP receiver channel ایک ایک field کر کے ترتیب دیا جاتا ہے: address، query، method، authentication اور request headers۔ Spec بتاتا ہے کہ ہر field میں کیا جائے گا، اور body، Content Modifier یا mapping میں بنائی جاتی ہے۔

HTTP receiver کے address میں path parameter کیسے ڈالوں؟

Parameter کو expression سے بدلیں، مثلاً https://api.example.com/v1/orders/${property.orderId}/shipments۔

API کو custom header کیسے بھیجوں؟

اسے Content Modifier میں message header کے طور پر سیٹ کریں اور اس کا نام HTTP receiver کے Request Headers میں شامل کریں۔ کئی نام | سے الگ کیے جاتے ہیں۔

کیا Request Headers میں * استعمال کروں؟

صرف اس صورت میں جب API کو ہر message header ملنا چاہیے۔ ضروری headers درج کرنے سے اندرونی headers بھیجنے سے بچا جا سکتا ہے۔

SAP CPI میں {{baseUrl}} جیسے Postman variables کیا بنتے ہیں؟

اچھا متبادل ایک externalized parameter ہے، جو یہی {{…}} syntax استعمال کرتا ہے اور ڈپلائے کے وقت سیٹ ہوتا ہے، تاکہ test اور production مختلف URLs استعمال کر سکیں۔

Call کے بعد HTTP status code کیسے پڑھوں؟

Throw Exception on Failure بند کریں اور ${header.CamelHttpResponseCode} پڑھیں، مثلاً کسی Router شرط میں۔

ڈیزائنر چھوڑے بغیر iFlows پر کام کریں

Kitegra کو Chrome یا Microsoft Edge میں شامل کریں۔ مفت شروع کریں، کسی اکاؤنٹ کی ضرورت نہیں۔