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

SOAPMessageपुष्टि नीति

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

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

यह एक्सएसडी स्कीमा के हिसाब से, किसी भी एक्सएमएल मैसेज की पुष्टि करता है
यह डब्ल्यूएसडीएल डेफ़िनिशन के हिसाब से, SOAP मैसेज की पुष्टि करता है
इससे JSON और एक्सएमएल मैसेज के सही फ़ॉर्मैट में होने का पता चलता है

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

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

फ़ायदे

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

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

वीडियो

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

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

उदाहरण

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

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>

अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, SOAP मैसेज की पुष्टि करने की नीति जोड़ें:
1. <ResourceURL> एलिमेंट की मदद से, अपनी एक्सएसडी रिसॉर्स फ़ाइल की जगह की जानकारी दें. उदाहरण के लिए:
```
...
  <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"
}

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

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 की पुष्टि

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

नई WSDL resource file बनाएं. उदाहरण के लिए, "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>

अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, 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> एलिमेंट की मदद से, अपनी डब्ल्यूएसडीएल रिसॉर्स फ़ाइल की जगह की जानकारी दें. उदाहरण के लिए:
```
...
  <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 या एक्सएमएल मैसेज का पेलोड सही तरीके से फ़ॉर्मैट किया गया हो. हालांकि, यह पुष्टि करने जैसा नहीं है. इस नीति से यह पक्का होता है कि स्ट्रक्चर और कॉन्टेंट, स्वीकार किए गए मानकों के मुताबिक हो. इनमें ये शामिल हैं:

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

एक्सएमएल या 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 या एक्सएमएल सही फ़ॉर्मैट में है या नहीं. ऐसा तब होता है, जब Content-type हेडर "application/json" या "application/xml" हो.

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

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

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

नीचे दिए गए उदाहरण स्कीमा में कई 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 में कम से कम एक स्कीमा तय करना ज़रूरी है. अगर यह कम से कम एक स्कीमा का रेफ़रंस नहीं देता है, तो मैसेज की पुष्टि करने की नीति लागू नहीं हो पाती.

किसी स्कीमा के लिए, ज़्यादा से ज़्यादा 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 में नौ पॉइंट देखें.

`<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: एक्सएसडी की पुष्टि करना

2: SOAP की पुष्टि

3: सही तरीके से फ़ॉर्मैट किया गया एक्सएमएल/JSON

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

<DisplayName>

सिंटैक्स

उदाहरण

<Element>

सिंटैक्स

उदाहरण 1

उदाहरण 2

<ResourceURL>

सिंटैक्स

उदाहरण

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

पुष्टि करने के लिए डब्ल्यूएसडीएल का इस्तेमाल करना

<SOAPMessage>

सिंटैक्स

उदाहरण

<Source>

सिंटैक्स

उदाहरण

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

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

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

स्कीमा

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

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

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`