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 में ठीक वही दो headers लिखे हैं जो 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 गायब या गलत: कई 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 संभाल सके।
• ज़्यादातर APIs में 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 को आपके लिए संभालता है। इसे OpenAPI या Swagger फ़ाइल, JSON या YAML में, या Postman collection दें, और यह SAP Integration Suite डिज़ाइनर में उस spec से URLs, paths, query parameters, request headers और उदाहरण JSON bodies सुझाता है।

Spec आपके browser में ही रहता है: Kitegra कभी API specs नहीं सहेजता। एक्सटेंशन किसी iFlow का content कभी सहेजता, deploy या edit नहीं करता, और आपका tenant सिर्फ़ तब बदलता है जब आप चार नामित actions में से किसी एक पर क्लिक करते हैं, जिन्हें बंद भी किया जा सकता है।

अपने 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 एक्सटेंशन के साथ देखें।

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