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-এ মেলানো হয়েছে, এবং সেই বিষয়গুলোর তালিকা দেওয়া হয়েছে যা প্রথম call-কে সবচেয়ে বেশি fail করায়।

HTTP receiver-এর কী দরকার

• Address: operation-এর পূর্ণ URL। এতে Simple expressions থাকতে পারে, যেমন path parameter-এর জন্য ${property.orderId}।
• Query: ? ছাড়া query string, যেমন notify=true।
• Method: GET, POST, PUT, PATCH বা DELETE।
• Authentication: none, Basic, Client Certificate, OAuth2 Client Credentials ও অন্যান্য, যার credentials tenant-এ সংরক্ষিত থাকে, কখনো channel-এ লেখা হয় না।
• Request Headers: API-তে পাঠানো message headers-এর নাম, | দিয়ে আলাদা করা।
• 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. {orderId}-এর মতো path parameters: প্রতিটিকে একটি 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-এ ঠিক সেই দুটি header তালিকাভুক্ত যা API-এর পাওয়া উচিত, তাই বাকি সব headers tenant-এই থাকে।

একটি Postman request থেকে

একটি Postman request-এ একই তথ্য থাকে অন্য জায়গায়:

• URL প্রায়ই {{baseUrl}}-এর মতো একটি Postman variable দিয়ে শুরু হয়। SAP CPI-তে একই {{…}} syntax একটি externalized parameter চিহ্নিত করে, যা deploy করার সময় সেট হয়: base URL-এর জন্য এটিই স্বাভাবিক জায়গা, কারণ তা test ও production-এর মধ্যে বদলায়।
• Path variables (:orderId) ও query parameters আগের মতোই Address ও Query fields-এ যায়।
• Headers tab হয়ে যায় Content Modifier-এর headers এবং Request Headers-এ তাদের নাম।
• Raw JSON body হয়ে যায় Content Modifier-এর body, যেখানে প্রতিটি test value-এর জায়গায় একটি expression বসে।
• Authorization tab বলে দেয় কোন authentication সেট করতে হবে। Postman-এর token iFlow-এ copy করবেন না; credentials tenant-এ সংরক্ষণ করুন।

যে বিষয়গুলো প্রথম call fail করায়

• Request Headers-এ * API-তে সব message headers পাঠায়, internal headers-সহ। শুধু সেই headers তালিকাভুক্ত করুন যা API প্রত্যাশা করে।
• Content-Type header অনুপস্থিত বা ভুল: অনেক API 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 সামলাতে পারে।
• বেশিরভাগ API-তে JSON body-এর field names case-sensitive; সেগুলো মনে রেখে নয়, schema থেকে copy করুন।

এর বদলে OData service call করছেন? OData receiver নিয়ে নিবন্ধটি দেখুন। Address ও body-এর expressions-এর জন্য দেখুন SAP CPI-তে Camel Simple expressions।

Kitegra কীভাবে সাহায্য করে

Kitegra browser এক্সটেনশন আপনার হয়ে API spec সামলায়। এটিকে JSON বা YAML-এ একটি OpenAPI বা Swagger ফাইল, অথবা একটি Postman collection দিন, আর এটি SAP Integration Suite ডিজাইনারে সেই spec থেকে URLs, paths, query parameters, request headers ও উদাহরণ JSON bodies সাজেস্ট করবে।

Spec আপনার browser-এই থাকে: Kitegra কখনো API specs সংরক্ষণ করে না। এক্সটেনশনটি কখনো কোনো iFlow-এর content সংরক্ষণ, deploy বা edit করে না, এবং আপনার tenant কেবল তখনই বদলায় যখন আপনি নাম দেওয়া চারটি action-এর একটিতে ক্লিক করেন, যেগুলো বন্ধও করা যায়।

নিজের iFlow-এর HTTPS endpoint একইভাবে call করতে service key দিয়ে HTTPS iFlow টেস্ট করার নিবন্ধটি দেখুন।

Kitegra অ্যাকাউন্ট ছাড়া এটি প্রতিটি মডিউলে 5টি iFlow-এ কাজ করে। Free প্ল্যানে 50, Starter-এ 100 এবং Pro-তে 300টি iFlow অন্তর্ভুক্ত। টিম প্ল্যানে প্রতিটি সদস্য Pro পান, Startup Team-এ প্রতি মডিউলে 300টি iFlow সহ, আর Growth Team ও Scale Team-এ কোনো সীমা নেই। Kitegra লঞ্চের সময়টায়, সাইন ইন করা সবার জন্য প্রতিটি টুল খোলা, Free প্ল্যানেও। প্ল্যানগুলো তুলনা করুন।

আপনার পরবর্তী iFlow-এ চেষ্টা করুন

SAP Integration Suite ডিজাইনারে Kitegra কী করে তা পড়ুন, অথবা Kitegra-এর অন্য Chrome এক্সটেনশনগুলোর পাশে এটি দেখুন।

সাধারণ জিজ্ঞাসা