SOAPMessageपुष्टि नीति

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

SOAPMessageValidation नीति ये काम करती है:

  • किसी भी एक्सएमएल मैसेज की पुष्टि, उसके XSD स्कीमा के हिसाब से करता है
  • WSDL परिभाषा के हिसाब से एसओएपी मैसेज की पुष्टि करता है
  • JSON और एक्सएमएल मैसेज के सही फ़ॉर्मैट का पता लगाता है

यूज़र इंटरफ़ेस (यूआई) में इस नीति का नाम "एसओएपी मैसेज की पुष्टि करना" है. हालांकि, यह नीति सिर्फ़ एसओएपी मैसेज की ही पुष्टि नहीं करती. इस सेक्शन में, नीति को "मैसेज की पुष्टि करने की नीति" कहा गया है.

फ़ायदे

मैसेज की पुष्टि करने से ये फ़ायदे मिलते हैं:

  • अगर आपके एपीआई का इस्तेमाल करने वाले ऐप्लिकेशन डेवलपर के अनुरोध, नियमों के मुताबिक नहीं हैं या अधूरे हैं, तो उन्हें तुरंत इसकी जानकारी दी जाती है.
  • अनुरोधों में समस्याओं की जानकारी देता है. जैसे, ऐसे एक्सएमएल टैग जो ठीक से बंद नहीं किए गए हैं.
  • बैकएंड सेवाओं को सुरक्षित रखता है. इसके लिए, ऐसे एक्सएमएल या एसओएपी मैसेज को ब्लॉक किया जाता है जिनके स्ट्रक्चर की वजह से, सेवाओं के काम करने का तरीका अप्रत्याशित हो सकता है.
  • इससे समस्या हल करने, फ़ोरम खोजने या टेक्नोलॉजी सहायता टीम से सलाह लेने में कम समय लगता है.
  • डेवलपर को एक्सएमएल स्कीमा WSDL के बारे में जानने के लिए बढ़ावा देता है, ताकि पुष्टि करने से जुड़ी गड़बड़ियां खत्म की जा सकें. साथ ही, अच्छी तरह से समझे गए एक्सएमएल स्कीमा को आपके एपीआई दस्तावेज़ का मुख्य कॉम्पोनेंट बनाया जा सके.

वीडियो

मैसेज की पुष्टि करने की नीति के बारे में ज़्यादा जानने के लिए, ये वीडियो देखें:

वीडियो ब्यौरा
एक्सएमएल अनुरोध की पुष्टि करना मैसेज की पुष्टि करने की नीति का इस्तेमाल करके, किसी एपीआई के लिए एक्सएमएल अनुरोध की पुष्टि करें.
JSON अनुरोध की पुष्टि करना मैसेज की पुष्टि करने की नीति का इस्तेमाल करके, किसी एपीआई के लिए JSON अनुरोध की पुष्टि करें.

<MessageValidation> एलिमेंट

मैसेज की पुष्टि करने की नीति के बारे में बताता है.

डिफ़ॉल्ट वैल्यू नीचे डिफ़ॉल्ट नीति टैब देखें
क्या यह ज़रूरी है? वैकल्पिक
समस्या कॉम्प्लेक्स ऑब्जेक्ट
पैरंट एलिमेंट लागू नहीं
चाइल्ड एलिमेंट <DisplayName>
<Element>
<ResourceURL>
<SOAPMessage>
<Source>
सिंटैक्सडिफ़ॉल्ट नीति

<MessageValidation> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

<MessageValidation
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
    <!-- All MessageValidation child elements are optional -->
    <DisplayName>policy_display_name</DisplayName>
    <Element namespace="element_namespace">element_to_validate</Element>
    <SOAPMessage version="[ 1.1 | 1.2 | 1.1/1.2 ]"/>
    <Source>message_to_validate</Source>
    <ResourceURL>validation_WSDL_or_XSD</ResourceURL>

</MessageValidation>

यहां दिए गए उदाहरण में, Edge यूज़र इंटरफ़ेस (यूआई) में अपने फ़्लो में मैसेज की पुष्टि करने की नीति जोड़ने पर, डिफ़ॉल्ट सेटिंग दिख रही हैं:

<MessageValidation continueOnError="false" enabled="true" name="SOAP-Message-Validation-1">
  <DisplayName>SOAP Message Validation-1</DisplayName>
  <Properties/>
  <Element namespace="http://sample.com">sampleObject</Element>
  <SOAPMessage/>
  <Source>request</Source>
  <ResourceURL>wsdl://SOAP-Message-Validation-1.wsdl</ResourceURL>
</MessageValidation>

इस एलिमेंट में ये एट्रिब्यूट शामिल होते हैं, जो सभी नीतियों में शामिल हैं:

एट्रिब्यूट डिफ़ॉल्ट ज़रूरी है? ब्यौरा
name लागू नहीं ज़रूरी

नीति का अंदरूनी नाम. name एट्रिब्यूट की वैल्यू में अक्षर, संख्याएं, स्पेस, हाइफ़न, अंडरस्कोर, और फ़ुल स्टॉप का इस्तेमाल किया जा सकता है. इस वैल्यू में 255 से ज़्यादा वर्ण नहीं हो सकते.

इसके अलावा, मैनेजमेंट एलिमेंट के यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, नीति एलिमेंट को किसी अलग नाम से इस्तेमाल करने के लिए, <DisplayName> एलिमेंट का इस्तेमाल किया जा सकता है.
continueOnError गलत ज़रूरी नहीं नीति के काम न करने पर गड़बड़ी दिखाने के लिए, "गलत" पर सेट करें. ज़्यादातर नीतियों के लिए इस तरीके का इस्तेमाल किया जाना चाहिए. नीति लागू न होने के बाद भी फ़्लो चलाने के लिए, "सही" पर सेट करें.
enabled सही ज़रूरी नहीं नीति लागू करने के लिए, "सही" पर सेट करें. नीति को "बंद" करने के लिए "गलत" पर सेट करें. अगर नीति किसी फ़्लो से जुड़ी हुई हो, तो भी उसे लागू नहीं किया जाएगा.
async   गलत बहिष्कृत इस एट्रिब्यूट के इस्तेमाल पर रोक लगा दी गई है.

उदाहरण

यहां दिए गए उदाहरणों से पता चलता है कि मैसेज की पुष्टि करने की नीति का इस्तेमाल कैसे किया जा सकता है:

पहला: XSD की मदद से पुष्टि करना2: एसओएपी की पुष्टि3: सही फ़ॉर्मैट वाला एक्सएमएल/JSON

एक्सएमएल मैसेज के अनुरोध के पेलोड की पुष्टि करने के लिए, मैसेज की पुष्टि करने की नीति का इस्तेमाल किया जा सकता है. यह पुष्टि, एक्सएसडी स्कीमा के हिसाब से की जाती है.

  1. नई XSD रिसॉर्स फ़ाइल बनाएं. उदाहरण के लिए, "note-schema.xsd": 
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="note">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="to" type="xs:string"/>
        <xs:element name="from" type="xs:string"/>
        <xs:element name="heading" type="xs:string"/>
        <xs:element name="body" type="xs:string"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>
  2. अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, एसओएपी मैसेज की पुष्टि करने की नीति जोड़ें:
    1. <ResourceURL> एलिमेंट की मदद से, अपनी XSD रिसॉर्स फ़ाइल की जगह बताएं. उदाहरण के लिए: 
      ...
  <ResourceURL>xsd://note-schema.xsd</ResourceURL>
...
    2. नीति की परिभाषा से <SOAPMessage> और <Element> एलिमेंट हटाएं.

    आपकी नीति की परिभाषा कुछ इस तरह दिखनी चाहिए:

    <MessageValidation continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My XML Validator</DisplayName>
  <Properties/>
  <Source>request</Source>
  <ResourceURL>xsd://note-schema.xsd</ResourceURL>
</MessageValidation>
  3. अपने एक्सएमएल को मैसेज के पेलोड के तौर पर इस्तेमाल करके, अपनी एपीआई प्रॉक्सी को POST अनुरोध भेजें. उदाहरण के लिए: 
    curl -v -X POST -H 'Content-Type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  -d '<note>
  <to>Fred Rogers</to>
  <from>Nick Danger</from>
  <heading>Greetings from my neighborhood</heading>
  <body>Just writing to say hello.</body>
</note>'

    ध्यान दें कि Content-type हेडर "application/xml" पर सेट है.

    आपके पास पेलोड के लिए डेटा फ़ाइल बनाने का विकल्प भी है. साथ ही, इस फ़ाइल का रेफ़रंस, इस तरह के निर्देश के साथ दिया जा सकता है:

    curl -v -X POST -H 'Content-type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  --data '@../examples/note-payload.xml'

आपको HTTP 200 जवाब मिल जाएगा. टारगेट किए गए एंडपॉइंट के आधार पर, आपको अनुरोध के बारे में ज़्यादा जानकारी मिल सकती है. उदाहरण के लिए, अगर टारगेट एंडपॉइंट के तौर पर http://httpbin.org/post का इस्तेमाल किया जाता है और -v (ज़्यादा जानकारी वाला) आउटपुट तय किया जाता है, तो रिस्पॉन्स इस तरह का होना चाहिए:

< HTTP/1.1 200 OK
< Date: Wed, 16 May 2018 21:24:54 GMT
< Content-Type: application/xml
< Content-Length: 431
< Connection: keep-alive
< Server: gunicorn/19.8.1
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< Via: 1.1 vegur
{
  "args":{},
  "data":"<note><to>fred</to><from>nick</from><heading>hello</heading>
    <body>Just writing to say hello.</body></note>",
  "files":{},
  "form":{},
  "headers": {
    "Accept":"*/*",
    "Connection":"close",
    "Content-Length":"106",
    "Content-Type":"application/xml",
    "Host":"httpbin.org",
    "User-Agent":"curl/7.58.0"
  },
  "json":null,
  "origin":"10.1.1.1, 104.154.179.1",
  "url":"http://httpbin.org/post"
}

यह पुष्टि करने के लिए कि आपकी XSD पुष्टि की सुविधा काम कर रही है या नहीं, अपने अनुरोध के मुख्य हिस्से में कोई दूसरा टैग डालकर देखें. उदाहरण के लिए:

curl -v -X POST -H 'Content-Type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  -d '<note>
  <to>Fred Rogers</to>
  <from>Nick Danger</from>
  <heading>Greetings from my neighborhood</heading>
  <body>Just writing to say hello.</body>
  <badTag>Not good</badTag>
</note>'

आपको पुष्टि करने से जुड़ी गड़बड़ी का मैसेज मिलेगा.

मैसेज की पुष्टि करने की नीति का इस्तेमाल करके, WSDL के हिसाब से SOAP मैसेज के अनुरोध के पेलोड की पुष्टि की जा सकती है.

  1. नई WSDL रिसॉर्स फ़ाइल बनाएं. उदाहरण के लिए, "example-wsdl.wsdl": 
    <?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="https://example.com/gateway"
    xmlns:tns="https://example.com/gateway"
    xmlns:types="https://example.com/gateway/types"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/">
  <wsdl:types>
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="https://example.com/gateway/types"
        elementFormDefault="qualified">
      <xsd:element name="MyType">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="ID" nillable="false" minOccurs="1" maxOccurs="1"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:schema>
    <schema attributeFormDefault="unqualified" elementFormDefault="qualified"
        targetNamespace="https://example.com/gateway"
        xmlns="http://www.w3.org/2001/XMLSchema">
      <xsd:import namespace="https://example.com/gateway/types"/>
      <element name="getID">
        <complexType>
          <sequence>
            <element ref="types:MyType"/>
          </sequence>
        </complexType>
      </element>
    </schema>
  </wsdl:types>

  <wsdl:message name="getRequest">
    <wsdl:part name="getRequest" element="tns:getID"/>
  </wsdl:message>
  <wsdl:message name="getResponse">
    <wsdl:part name="getResponse" element="tns:getID"/>
  </wsdl:message>

  <wsdl:portType name="PortType">
    <wsdl:operation name="get">
      <wsdl:input name="methodRequest" message="tns:getRequest"/>
      <wsdl:output name="methodResponse" message="tns:getResponse"/>
    </wsdl:operation>
  </wsdl:portType>

  <wsdl:service name="Gateway">
    <wsdl:port name="GatewaySoap" binding="tns:SoapBinding">
      <wsdlsoap:address location="https://example.com/gateway"/>
    </wsdl:port>
  </wsdl:service>

  <wsdl:binding name="SoapBinding" type="tns:PortType">
    <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

    <wsdl:operation name="get">
      <wsdlsoap:operation soapAction="get"/>
      <wsdl:input name="methodRequest"/>
      <wsdl:output name="methodResponse"/>
    </wsdl:operation>

  </wsdl:binding>
</wsdl:definitions>
  2. अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, एसओएपी मैसेज की पुष्टि करने की नीति जोड़ें:
    1. <SOAPMessage> एलिमेंट के version एट्रिब्यूट को, SOAP प्रोटोकॉल के उस वर्शन पर सेट करें जिसकी आपको पुष्टि करनी है. उदाहरण के लिए, "1.1": 
      ...
  <SOAPMessage version="1.1"/>
...
    2. <Element> एलिमेंट की वैल्यू को उस एलिमेंट पर सेट करें जिसकी पुष्टि करनी है: 
      ...
  <Element namespace="https://example.com/gateway">getID</Element>
...

      <Element>, SOAP अनुरोध के लिफाफ़े में <Body> एलिमेंट के तहत पहले चाइल्ड एलिमेंट के बारे में बताता है.

      उस चाइल्ड के लिए, namespace एट्रिब्यूट को नेमस्पेस पर सेट करें.

    3. <ResourceURL> एलिमेंट की मदद से, अपनी WSDL रिसॉर्स फ़ाइल की जगह बताएं. उदाहरण के लिए: 
      ...
  <ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
...

    आपकी नीति की परिभाषा कुछ इस तरह दिखनी चाहिए:

    <MessageValidation continueOnError="false"
    enabled="true" name="validateSOAPRequest">
  <DisplayName>My SOAP Validator</DisplayName>
  <Properties/>
  <Source>request</Source>
  <SOAPMessage version="1.1"/>
  <Element namespace="https://example.com/gateway">getID</Element>
  <ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
</MessageValidation>
  3. अपनी एपीआई प्रॉक्सी को POST अनुरोध भेजें. इसमें मैसेज पेलोड के तौर पर, SOAP एनवलप का इस्तेमाल करें. उदाहरण के लिए: 
    curl -v -X POST -H 'Content-Type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  -d '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:prox="https://example.com/gateway" xmlns:typ="https://example.com/gateway/types">
  <soapenv:Header/>
  <soapenv:Body>
    <prox:getID>
      <typ:MyType>
        <typ:ID>42</typ:ID>
      </typ:MyType>
    </prox:getID>
  </soapenv:Body>
</soapenv:Envelope>'

    ध्यान दें कि Content-type हेडर "application/xml" पर सेट है.

    आपके पास पेलोड के लिए डेटा फ़ाइल बनाने का विकल्प भी है. साथ ही, इस फ़ाइल का रेफ़रंस, इस तरह के निर्देश के साथ दिया जा सकता है:

    curl -v -X POST -H 'Content-type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  --data '@../examples/soap-payload.xml'

आपको HTTP 200 जवाब मिल जाएगा. टारगेट किए गए एंडपॉइंट के आधार पर, आपको अनुरोध के बारे में ज़्यादा जानकारी मिल सकती है. उदाहरण के लिए, अगर टारगेट एंडपॉइंट के तौर पर http://httpbin.org/post का इस्तेमाल किया जाता है, तो रिस्पॉन्स कुछ ऐसा दिखना चाहिए:

< HTTP/1.1 200 OK
< Date: Wed, 16 May 2018 21:24:54 GMT
< Content-Type: application/xml
< Content-Length: 431
< Connection: keep-alive
< Server: gunicorn/19.8.1
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< Via: 1.1 vegur
{
  "args":{},
  "data":"<note><to>fred</to><from>nick</from><heading>hello</heading>
    <body>Just writing to say hello.</body></note>",
  "files":{},
  "form":{},
  "headers": {
    "Accept":"*/*",
    "Connection":"close",
    "Content-Length":"106",
    "Content-Type":"application/xml",
    "Host":"httpbin.org",
    "User-Agent":"curl/7.58.0"
  },
  "json":null,
  "origin":"10.1.1.1, 104.154.179.1",
  "url":"http://httpbin.org/post"
}

मैसेज की पुष्टि करने की नीति का इस्तेमाल करके, यह पुष्टि की जा सकती है कि JSON या एक्सएमएल मैसेज का पेलोड सही है या नहीं. यह पुष्टि करने की नीति से अलग है. इस नीति से यह पक्का होता है कि स्ट्रक्चर और कॉन्टेंट, स्वीकार किए गए मानकों के मुताबिक हो. इनमें ये शामिल हैं:

  • एक रूट एलिमेंट है
  • कॉन्टेंट में कोई गैर-कानूनी वर्ण न हो
  • ऑब्जेक्ट और टैग सही तरीके से नेस्ट किए गए हैं
  • शुरुआती और आखिरी टैग मैच करते हैं

सही फ़ॉर्मैट में मौजूद XML या JSON पेलोड की जांच करने के लिए:

  1. अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, SOAP मैसेज की पुष्टि करने की नीति जोड़ें.
  2. नीति की परिभाषा से <ResourceURL>, <SOAPMessage>, और <Element> एलिमेंट हटाएं.

    आपकी नीति की परिभाषा कुछ इस तरह दिखनी चाहिए:

    <MessageValidation async="false" continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My JSON Checker</DisplayName>
  <Properties/>
  <Source>request</Source>
</MessageValidation>
  3. अपने एपीआई प्रॉक्सी को POST अनुरोध भेजें, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है: 
    curl -v -X POST -H 'Content-Type: application/json' http://my-test.apigee.net/v1/xsd-mock
  -d '{
"note": {
  "to": "Fred Rogers",
  "from": "Nick Danger",
  "header": "Greetings from my neighborhood",
  "body": "Just writing to say hello."
  }
}'

    ध्यान दें कि Content-type हेडर "application/json" पर सेट है.

    एक्सएमएल फ़ाइल की सही तरीके से बनी हुई है या नहीं, यह देखने के लिए मैसेज के पेलोड के तौर पर एक्सएमएल का इस्तेमाल करें और Content-type को "application/xml" पर सेट करें.

आपको HTTP 200 जवाब मिल जाएगा. अगर आपने कोई ऐसा मैसेज पेलोड भेजा है जिसमें सही फ़ॉर्मैट में एक्सएमएल या JSON नहीं है, तो आपको steps.messagevalidation.Failed गड़बड़ी का मैसेज दिखेगा.

चाइल्ड एलिमेंट का रेफ़रंस

इस सेक्शन में, <MessageValidation> के चाइल्ड एलिमेंट के बारे में बताया गया है.

<DisplayName>

name एट्रिब्यूट के साथ-साथ, नीति को मैनेज करने वाले यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, नीति को किसी ऐसे नाम से लेबल करें जो सामान्य हो और सुनने में अच्छा लगे.

<DisplayName> एलिमेंट सभी नीतियों में एक जैसा होता है.

डिफ़ॉल्ट वैल्यू लागू नहीं
क्या यह ज़रूरी है? ज़रूरी नहीं. <DisplayName> को छोड़ने पर, नीति के name एट्रिब्यूट की वैल्यू का इस्तेमाल किया जाता है
स्ट्रीम किस तरह की है स्ट्रिंग
पैरंट एलिमेंट <PolicyElement>
चाइल्ड एलिमेंट कोई नहीं

<DisplayName> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

सिंटैक्सउदाहरण 
<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>
 
<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

<DisplayName> एलिमेंट में कोई एट्रिब्यूट या चाइल्ड एलिमेंट नहीं है.

<Element>

मैसेज में मौजूद उस एलिमेंट की जानकारी देता है जिसकी पुष्टि करनी है. यह SOAP अनुरोध के लिफाफ़े में, <Body> एलिमेंट के तहत मौजूद पहला चाइल्ड एलिमेंट है.

डिफ़ॉल्ट वैल्यू sampleObject
क्या यह ज़रूरी है? वैकल्पिक
समस्या स्ट्रिंग
पैरंट एलिमेंट <MessageValidation>
चाइल्ड एलिमेंट कोई नहीं

<Element> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

सिंटैक्सउदाहरण 1उदाहरण 2 
...
  <Element namespace="element_namespace">element_to_validate</Element>
...

यहां दिए गए उदाहरण में, पुष्टि किए जाने वाले एक एलिमेंट के बारे में बताया गया है:

...
<Element namespace="https://example.com/gateway">getID</Element>
...

पुष्टि करने के लिए, एक से ज़्यादा एलिमेंट तय किए जा सकते हैं. इसके लिए, एक से ज़्यादा <Element> एलिमेंट जोड़ें:

...
<Element namespace="https://example.com/gateway">getID</Element>
<Element namespace="https://example.com/gateway">getDetails</Element>
...

<Element> एलिमेंट में ये एट्रिब्यूट होते हैं:

एट्रिब्यूट डिफ़ॉल्ट ज़रूरी है? ब्यौरा
namespace "http://sample.com" वैकल्पिक पुष्टि किए जाने वाले एलिमेंट का नेमस्पेस तय करता है.

<ResourceURL>

सोर्स मैसेज की पुष्टि करने के लिए इस्तेमाल किए जाने वाले XSD स्कीमा या WSDL डेफ़िनिशन की पहचान करता है.

डिफ़ॉल्ट वैल्यू wsdl://display_name.wsdl
क्या यह ज़रूरी है? वैकल्पिक
समस्या स्ट्रिंग
पैरंट एलिमेंट <MessageValidation>
चाइल्ड एलिमेंट कोई नहीं

<ResourceURL> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

सिंटैक्सउदाहरण 
...
  <ResourceURL>[wsdl|xsd]://validation_WSDL_or_XSD</ResourceURL>
...

एक्सएमएल फ़ाइल के लिए:

...
<ResourceURL>xsd://note-schema.xsd</ResourceURL>
...

WSDL के लिए:

...
<ResourceURL>wsdl://example-wsdl.wsdl</ResourceURL>
...

<ResourceURL> की वैल्यू, आपकी एपीआई प्रॉक्सी में मौजूद रिसॉर्स फ़ाइल पर ले जानी चाहिए. यह एचटीटीपी या एचटीटीपीएस पर, बाहरी संसाधनों का रेफ़रंस नहीं दे सकता.

अगर आपने <ResourceURL> के लिए कोई वैल्यू नहीं दी है, तो मैसेज में सही फ़ॉर्मैट में JSON या एक्सएमएल होने की जांच की जाती है. ऐसा तब किया जाता है, जब Content-type हेडर "application/json" या "application/xml" हो.

<ResourceURL> एलिमेंट में कोई चाइल्ड एलिमेंट या एट्रिब्यूट नहीं है.

पुष्टि करने के लिए XSD का इस्तेमाल करना

अगर मैसेज की पुष्टि करने की नीति की मदद से पुष्टि किया गया एक्सएमएल पेलोड, किसी दूसरे स्कीमा का रेफ़रंस देता है, तो आपको शामिल की गई XSD फ़ाइल के नाम के आगे xsd का प्रीफ़िक्स जोड़ना होगा. ऐसा, schemaLocation एट्रिब्यूट में करना होगा.

यहां दिए गए उदाहरण के स्कीमा में कई XSD शामिल हैं:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:include schemaLocation="xsd://note-schema.xsd"/>
  <xs:include schemaLocation="xsd://letter-schema.xsd"/>
  <xs:include schemaLocation="xsd://user-schema.xsd"/>
</xs:schema>

पुष्टि करने के लिए WSDL का इस्तेमाल करना

WSDL में कम से कम एक स्कीमा होना चाहिए. अगर इसमें कम से कम एक स्कीमा का रेफ़रंस नहीं दिया गया है, तो मैसेज की पुष्टि करने की नीति लागू नहीं होगी.

किसी स्कीमा को ज़्यादा से ज़्यादा 10 लेवल तक इंपोर्ट किया जा सकता है. नेस्ट किए गए इंपोर्ट की संख्या ज़्यादा होने पर, मैसेज की पुष्टि करने की नीति लागू नहीं होती.

<SOAPMessage>

एसओएपी के उस वर्शन के बारे में बताता है जिसकी पुष्टि, मैसेज की पुष्टि करने की नीति करती है.

डिफ़ॉल्ट वैल्यू लागू नहीं
क्या यह ज़रूरी है? वैकल्पिक
समस्या लागू नहीं
पैरंट एलिमेंट <MessageValidation>
चाइल्ड एलिमेंट कोई नहीं

<SOAPMessage> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

सिंटैक्सउदाहरण 
...
  <SOAPMessage version="[ 1.1 | 1.2 | 1.1/1.2 ]"/>
...
 
...
<SOAPMessage version="1.1"/>
...

<SOAPMessage> एलिमेंट में ये एट्रिब्यूट होते हैं:

एट्रिब्यूट डिफ़ॉल्ट ज़रूरी है? ब्यौरा
version कोई नहीं वैकल्पिक SOAP का वह वर्शन जिसका इस्तेमाल इस नीति में, SOAP मैसेज की पुष्टि करने के लिए किया जाता है.

मान्य मान हैं:

  • "1.1"
  • "1.2"
  • "1.1/1.2"

ज़्यादा जानकारी के लिए, SOAP/1.1 से SOAP वर्शन 1.2 पर जाने के बारे में नौ बातें देखें.

<Source>

पुष्टि किए जाने वाले सोर्स मैसेज की पहचान करता है. इस एलिमेंट की वैल्यू, उस मैसेज का नाम होता है जिसकी पुष्टि करनी है.

अगर <Source> सेट नहीं किया जाता है, तो यह नीति डिफ़ॉल्ट रूप से "मैसेज" पर सेट हो जाती है. इसका मतलब है कि किसी अनुरोध फ़्लो में पूरा अनुरोध मैसेज या जवाब फ़्लो में पूरा जवाब मैसेज, जिसमें कोई भी पेलोड शामिल है. अनुरोध या जवाब के बारे में बताने के लिए, इसे साफ़ तौर पर "अनुरोध" या "जवाब" पर भी सेट किया जा सकता है.

डिफ़ॉल्ट वैल्यू CANNOT TRANSLATE
क्या यह ज़रूरी है? वैकल्पिक
समस्या स्ट्रिंग
पैरंट एलिमेंट <MessageValidation>
चाइल्ड एलिमेंट कोई नहीं

<Source> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

सिंटैक्सउदाहरण 
...
  <Source>message_to_validate</Source>
...
 
...
<Source>request</Source>
...

"मैसेज", "अनुरोध", और "रिस्पॉन्स" के अलावा, अपने फ़्लो में किसी भी मैसेज के नाम पर <Source> की वैल्यू सेट की जा सकती है. हालांकि, ऐसा करने पर, आपको इस नीति के लागू होने से पहले, अपने फ़्लो में उस नाम के साथ एक कस्टम मैसेज बनाना होगा. ऐसा न करने पर, आपको एक गड़बड़ी का मैसेज मिलेगा.

अगर मैसेज फ़्लो में <Source> की वैल्यू को हल नहीं किया जा सकता या यह किसी मैसेज टाइप के बजाय किसी दूसरे टाइप के तौर पर हल होती है, तो इनमें से कोई एक समस्या होती है:

  • अगर कोई वैल्यू नहीं है, तो: Edge एक steps.messagevalidation.SourceMessageNotAvailable गड़बड़ी दिखाता है.
  • अगर कोई ऐसा मैसेज नहीं है: Edge, steps.messagevalidation.NonMessageVariable गड़बड़ी का मैसेज दिखाता है.

<Source> एलिमेंट में कोई एट्रिब्यूट या चाइल्ड एलिमेंट नहीं है.

गड़बड़ी के कोड

Edge की नीतियों से मिली गड़बड़ियां, गड़बड़ी के कोड के रेफ़रंस में बताए गए फ़ॉर्मैट के मुताबिक होती हैं.

यह सेक्शन गड़बड़ी के कोड और दिखाए गए गड़बड़ी के मैसेज के बारे में बताता है. साथ ही, इस नीति के ट्रिगर होने पर Edge की मदद से सेट की गई गड़बड़ी के वैरिएबल के बारे में बताता है. यह जानकारी जानना ज़रूरी है कि क्या गड़बड़ियों को ठीक करने के लिए, गड़बड़ी से जुड़े नियम बनाए जा रहे हैं. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी और गड़बड़ियों को ठीक करने के तरीके देखें.

रनटाइम से जुड़ी गड़बड़ियां

नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.

गड़बड़ी का कोड एचटीटीपी कोड स्थिति वजह समाधान
steps.messagevalidation.SourceMessageNotAvailable 500

यह गड़बड़ी तब होती है, जब नीति के <Source> एलिमेंट में बताया गया कोई वैरिएबल इनमें से कोई एक हो:

  • आउट ऑफ़ स्कोप (यह सुविधा उस फ़्लो में उपलब्ध नहीं होती है जहां नीति का इस्तेमाल किया जा रहा है)
    • या
  • रिज़ॉल्व नहीं किया जा सकता (तय नहीं किया गया है)
steps.messagevalidation.NonMessageVariable 500

यह गड़बड़ी तब होती है, जब SOAPMessage verification नीति में <Source> एलिमेंट को किसी ऐसे वैरिएबल पर सेट किया गया हो जो मैसेज टाइप का न हो.

मैसेज टाइप वैरिएबल से पूरे एचटीटीपी अनुरोध और उनके जवाब दिखते हैं. बिल्ट-इन Edge फ़्लो वैरिएबल request, response, और message टाइप मैसेज हैं. मैसेज वैरिएबल के बारे में ज़्यादा जानने के लिए, वैरिएबल का रेफ़रंस देखें.
steps.messagevalidation.Failed 500 यह गड़बड़ी तब होती है, जब SOAPMessageValidation की नीति, XSD स्कीमा या WSDL की परिभाषा के हिसाब से इनपुट मैसेज पेलोड की पुष्टि नहीं कर पाती. ऐसा तब भी होगा, जब पेलोड मैसेज में गलत JSON या एक्सएमएल हो.

डिप्लॉयमेंट से जुड़ी गड़बड़ियां

ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाले किसी प्रॉक्सी को डिप्लॉय किया जाता है.

गड़बड़ी का नाम वजह समाधान
InvalidResourceType SOAPMessageValidation नीति में <ResourceURL> एलिमेंट को ऐसे संसाधन प्रकार पर सेट किया गया है जो नीति के साथ काम नहीं करता.
ResourceCompileFailed SOAPMessageTerms नीति के <ResourceURL> एलिमेंट में रेफ़र की गई संसाधन स्क्रिप्ट में, एक ऐसी गड़बड़ी है जो उसे कंपाइल करने से रोकती है.
RootElementNameUnspecified SOAPMessageDescription नीति के <Element> एलिमेंट में रूट एलिमेंट का नाम शामिल नहीं है.
InvalidRootElementName SOAPMessage Verification नीति के <Element> एलिमेंट में रूट एलिमेंट का नाम शामिल है, जो मान्य एलिमेंट के नाम के लिए एक्सएमएल के नियमों का पालन नहीं करता है.

स्कीमा

हर तरह की नीति को एक्सएमएल स्कीमा (.xsd) से तय किया जाता है. रेफ़रंस के लिए, GitHub पर नीति के स्कीमा उपलब्ध हैं.

मिलते-जुलते विषय