Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

SOAPMessageपुष्टि नीति

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

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

यह टूल, किसी भी एक्सएमएल मैसेज की पुष्टि उसके XSD स्कीमा के हिसाब से करता है
यह WSDL डेफ़िनिशन के हिसाब से एसओएपी मैसेज की पुष्टि करता है
यह कुकी, JSON और XML मैसेज के सही फ़ॉर्मैट में होने का पता लगाती है

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

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

फ़ायदे

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

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

वीडियो

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

वीडियो	ब्यौरा
एक्सएमएल अनुरोध की पुष्टि करें	Message Validation नीति का इस्तेमाल करके, किसी एपीआई के लिए एक्सएमएल अनुरोध की पुष्टि करें.
JSON फ़ाइल की पुष्टि करने का अनुरोध	Message Validation नीति का इस्तेमाल करके, किसी एपीआई के लिए 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`	गलत	बहिष्कृत	इस एट्रिब्यूट के इस्तेमाल पर रोक लगा दी गई है.

उदाहरण

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

1: XSD की पुष्टि करना

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

नई 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>

अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, SOAP Message Validation नीति जोड़ें:
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>
```
अपने एपीआई प्रॉक्सी को 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>'

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

2: SOAP की पुष्टि करना

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

नई WSDL संसाधन फ़ाइल बनाएं. उदाहरण के लिए, "example-wsdl.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>

अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, SOAP मैसेज की पुष्टि करने की नीति जोड़ें:
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>
```
अपने एपीआई प्रॉक्सी को 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"
}

3: सही फ़ॉर्मैट वाला XML/JSON

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

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

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

अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, SOAP मैसेज की पुष्टि करने की नीति जोड़ें.
नीति की परिभाषा से <ResourceURL>, <SOAPMessage>, और <Element> एलिमेंट हटाएं.
नीति की परिभाषा कुछ इस तरह दिखनी चाहिए:
```
<MessageValidation async="false" continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My JSON Checker</DisplayName>
  <Properties/>
  <Source>request</Source>
</MessageValidation>
```
यहां दिए गए उदाहरण की तरह, अपने एपीआई प्रॉक्सी को 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> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

सिंटैक्स

...
  <Element namespace="element_namespace">element_to_validate</Element>
...

उदाहरण 1

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

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

उदाहरण 2

एक से ज़्यादा <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> की वैल्यू, आपके एपीआई प्रॉक्सी में मौजूद resource file की ओर ले जानी चाहिए. यह एचटीटीपी या एचटीटीपीएस पर बाहरी संसाधनों का रेफ़रंस नहीं दे सकता.

अगर आपने <ResourceURL> के लिए कोई वैल्यू नहीं दी है, तो मैसेज की जांच यह देखने के लिए की जाती है कि वह सही फ़ॉर्मैट वाले JSON या XML में है या नहीं. ऐसा तब किया जाता है, जब 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>`

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

डिफ़ॉल्ट वैल्यू	लागू नहीं
ज़रूरी है?	वैकल्पिक
समस्या	लागू नहीं
पैरंट एलिमेंट	`<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"

version

कोई नहीं

वैकल्पिक

यह नीति, SOAP मैसेज की पुष्टि करने के लिए SOAP के जिस वर्शन का इस्तेमाल करती है.

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

"1.1"
"1.2"
"1.1/1.2"

ज़्यादा जानकारी के लिए, SOAP/1.1 से SOAP वर्शन 1.2 में 9 पॉइंट लेख पढ़ें.

`<Source>`

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

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

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

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

सिंटैक्स

...
  <Source>message_to_validate</Source>
...

उदाहरण

...
<Source>request</Source>
...

"message", "request", और "response" के अलावा, <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 या एक्सएमएल हो.

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 पर उपलब्ध हैं.

SOAPMessageपुष्टि नीति

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

फ़ायदे

वीडियो

<MessageValidation> एलिमेंट

सिंटैक्स

डिफ़ॉल्ट नीति

उदाहरण

1: XSD की पुष्टि करना

2: SOAP की पुष्टि करना

3: सही फ़ॉर्मैट वाला XML/JSON

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

<DisplayName>

सिंटैक्स

उदाहरण

<Element>

सिंटैक्स

उदाहरण 1

उदाहरण 2

<ResourceURL>

सिंटैक्स

उदाहरण

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

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

<SOAPMessage>

सिंटैक्स

उदाहरण

<Source>

सिंटैक्स

उदाहरण

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

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

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

स्कीमा

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

`<MessageValidation>` एलिमेंट

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`