इस पेज का अनुवाद Cloud Translation API से किया गया है.

SOAPMessageपुष्टि नीति

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

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

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

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

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

फ़ायदे

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

अगर एपीआई का इस्तेमाल करने वाले ऐप्लिकेशन डेवलपर के अनुरोध, ज़रूरी शर्तों के मुताबिक नहीं हैं या अधूरे हैं, तो यह सुविधा तुरंत इसकी सूचना देती है.
अनुरोधों में समस्याओं का पता लगाता है. जैसे, ऐसे एक्सएमएल टैग जो ठीक से बंद नहीं किए गए हैं.
बैकएंड सेवाओं को सुरक्षित रखता है. इसके लिए, यह ऐसे स्ट्रक्चर वाले XML या 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 मैसेज की पुष्टि करने की नीति जोड़ें:
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: एसओएपी की पुष्टि

एसओएपी मैसेज के अनुरोध के पेलोड की पुष्टि, 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>

एसओएपी मैसेज की पुष्टि करने की नीति को अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में जोड़ें:
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 Message Validation नीति जोड़ें.
नीति की परिभाषा से <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>`

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

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

3: सही तरीके से बनाया गया XML/JSON

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

<DisplayName>

सिंटैक्स

उदाहरण

<Element>

सिंटैक्स

उदाहरण 1

उदाहरण 2

<ResourceURL>

सिंटैक्स

उदाहरण

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

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

<SOAPMessage>

सिंटैक्स

उदाहरण

<Source>

सिंटैक्स

उदाहरण

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

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

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

स्कीमा

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

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

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`