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

SOAPMessageपुष्टि नीति

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

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

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

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

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

फ़ायदे

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

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

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

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

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

नई 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: सही फ़ॉर्मैट वाला एक्सएमएल/JSON

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

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

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

अगर आपने <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"

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 या एक्सएमएल हो.

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> एलिमेंट

सिंटैक्स

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

उदाहरण

पहला: XSD की मदद से पुष्टि करना

2: एसओएपी की पुष्टि

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

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

<DisplayName>

सिंटैक्स

उदाहरण

<Element>

सिंटैक्स

उदाहरण 1

उदाहरण 2

<ResourceURL>

सिंटैक्स

उदाहरण

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

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

<SOAPMessage>

सिंटैक्स

उदाहरण

<Source>

सिंटैक्स

उदाहरण

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

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

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

स्कीमा

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

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

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`