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

SOAPMessageपुष्टि नीति

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

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

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

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

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

फ़ायदे

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

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

वीडियो

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

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

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

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

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

सिंटैक्स

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

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

</MessageValidation>

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

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

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

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

नई 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 बताएं (verbose) आउटपुट में, जवाब नीचे दिए गए विकल्पों जैसा होना चाहिए:

< 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 संसाधन फ़ाइल बनाएं. उदाहरण के लिए, "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 एट्रिब्यूट को एसओएपी प्रोटोकॉल का एक वर्शन होना चाहिए जिसके लिए आपको पुष्टि करनी है. उदाहरण के लिए, "1.1":
```
...
  <SOAPMessage version="1.1"/>
...
```
  अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
2. <Element> एलिमेंट की वैल्यू को उस एलिमेंट पर सेट करें जिसे आपको सेट करना है पुष्टि करें:
```
...
  <Element namespace="https://example.com/gateway">getID</Element>
...
```
  <Element>, <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 अनुरोध भेजें मैसेज पेलोड, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है:
```
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 पेलोड की जांच करने के लिए:

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

सोर्स मैसेज की पुष्टि करने के लिए, Xएसडी स्कीमा या WSDL की जानकारी देता है.

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

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

सिंटैक्स

...
  <ResourceURL>[wsdl|xsd]://validation_WSDL_or_XSD</ResourceURL>
...

उदाहरण

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

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

डब्लूएसडीएल के लिए:

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

<ResourceURL> का मान किसी संसाधन पर ले जाना चाहिए फ़ाइल है. यह एचटीटीपी या एचटीटीपीएस पर बाहरी संसाधन से जुड़ा हुआ नहीं हो सकता.

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

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

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

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

स्कीमा के एक से ज़्यादा उदाहरण नीचे दिए गए हैं:

<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`	कोई नहीं	वैकल्पिक	एसओएपी का वह वर्शन जिसका इस्तेमाल यह नीति, एसओएपी मैसेज की पुष्टि करने के लिए करती है. मान्य मान हैं: "1.1" "1.2" "1.1/1.2"

version

कोई नहीं

वैकल्पिक

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

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

"1.1"
"1.2"
"1.1/1.2"

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

`<Source>`

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

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

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

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

सिंटैक्स

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

उदाहरण

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

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

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

अगर कोई वैल्यू शून्य है: एज में 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: Xएसडी की पुष्टि करना

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

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

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

<DisplayName>

सिंटैक्स

उदाहरण

<Element>

सिंटैक्स

उदाहरण 1

उदाहरण 2

<ResourceURL>

सिंटैक्स

उदाहरण

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

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

<SOAPMessage>

सिंटैक्स

उदाहरण

<Source>

सिंटैक्स

उदाहरण

गड़बड़ी कोड

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

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

स्कीमा

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

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

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`