SOAPMessageपुष्टि नीति

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

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

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

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

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

This element has the following attributes that are common to all policies:

Attribute Default Required? Description
name N/A Required

The internal name of the policy. The value of the name attribute can contain letters, numbers, spaces, hyphens, underscores, and periods. This value cannot exceed 255 characters.

Optionally, use the <DisplayName> element to label the policy in the management UI proxy editor with a different, natural-language name.
continueOnError false Optional Set to "false" to return an error when a policy fails. This is expected behavior for most policies. Set to "true" to have flow execution continue even after a policy fails.
enabled true Optional Set to "true" to enforce the policy. Set to "false" to "turn off" the policy. The policy will not be enforced even if it remains attached to a flow.
async   false Deprecated This attribute is deprecated.

उदाहरण

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

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

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

  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>
  2. अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, 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>
  3. अपने एपीआई प्रॉक्सी को POST अनुरोध भेजें. इसमें एक्सएमएल को मैसेज पेलोड के तौर पर शामिल करें. यहां दिए गए उदाहरण में इसे दिखाया गया है: 
    curl -v -X POST -H 'Content-Type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  -d '<note>
  <to>Fred Rogers</to>
  <from>Nick Danger</from>
  <heading>Greetings from my neighborhood</heading>
  <body>Just writing to say hello.</body>
</note>'

    ध्यान दें कि Content-type हेडर को "application/xml" पर सेट किया गया है.

    आपके पास पेलोड के लिए डेटा फ़ाइल बनाने का विकल्प भी होता है. साथ ही, इसे इस तरह के कमांड से रेफ़रंस किया जा सकता है:

    curl -v -X POST -H 'Content-type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  --data '@../examples/note-payload.xml'

आपको HTTP 200 जवाब मिलेगा. आपके टारगेट एंडपॉइंट के आधार पर, आपको अनुरोध के बारे में ज़्यादा जानकारी मिल सकती है. उदाहरण के लिए, अगर आपने http://httpbin.org/post को टारगेट एंडपॉइंट के तौर पर इस्तेमाल किया है और -v (ज़्यादा जानकारी वाला) आउटपुट तय किया है, तो जवाब कुछ इस तरह का होना चाहिए:

< HTTP/1.1 200 OK
< Date: Wed, 16 May 2018 21:24:54 GMT
< Content-Type: application/xml
< Content-Length: 431
< Connection: keep-alive
< Server: gunicorn/19.8.1
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< Via: 1.1 vegur
{
  "args":{},
  "data":"<note><to>fred</to><from>nick</from><heading>hello</heading>
    <body>Just writing to say hello.</body></note>",
  "files":{},
  "form":{},
  "headers": {
    "Accept":"*/*",
    "Connection":"close",
    "Content-Length":"106",
    "Content-Type":"application/xml",
    "Host":"httpbin.org",
    "User-Agent":"curl/7.58.0"
  },
  "json":null,
  "origin":"10.1.1.1, 104.154.179.1",
  "url":"http://httpbin.org/post"
}

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

curl -v -X POST -H 'Content-Type: application/xml' http://my-test.apigee.net/v1/xsd-mock
  -d '<note>
  <to>Fred Rogers</to>
  <from>Nick Danger</from>
  <heading>Greetings from my neighborhood</heading>
  <body>Just writing to say hello.</body>
  <badTag>Not good</badTag>
</note>'

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

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

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

  1. नई WSDL संसाधन फ़ाइल बनाएं. उदाहरण के लिए, "example-wsdl.wsdl":
  2. एसओएपी मैसेज की पुष्टि करने की नीति को अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में जोड़ें:
    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>
  3. अपने एपीआई प्रॉक्सी को 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 पेलोड की जांच करने के लिए:

  1. अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, SOAP मैसेज की पुष्टि करने की नीति जोड़ें.
  2. नीति की परिभाषा से <ResourceURL>, <SOAPMessage>, और <Element> एलिमेंट हटाएं.

    नीति की परिभाषा ऐसी दिखनी चाहिए:

    <MessageValidation async="false" continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My JSON Checker</DisplayName>
  <Properties/>
  <Source>request</Source>
</MessageValidation>
  3. यहां दिए गए उदाहरण की तरह, अपने एपीआई प्रॉक्सी को POST अनुरोध भेजें: 
    curl -v -X POST -H 'Content-Type: application/json' http://my-test.apigee.net/v1/xsd-mock
  -d '{
"note": {
  "to": "Fred Rogers",
  "from": "Nick Danger",
  "header": "Greetings from my neighborhood",
  "body": "Just writing to say hello."
  }
}'

    ध्यान दें कि Content-type हेडर को "application/json" पर सेट किया गया है.

    एक्सएमएल फ़ाइल की संरचना सही है या नहीं, यह देखने के लिए, मैसेज पेलोड के तौर पर एक्सएमएल का इस्तेमाल करें. साथ ही, Content-type को "application/xml" पर सेट करें.

आपको HTTP 200 जवाब मिलेगा. अगर आपने ऐसा मैसेज पेलोड भेजा है जिसमें सही फ़ॉर्मैट वाला एक्सएमएल या JSON नहीं है, तो आपको steps.messagevalidation.Failed गड़बड़ी का मैसेज मिलेगा.

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

इस सेक्शन में, <MessageValidation> के चाइल्ड एलिमेंट के बारे में बताया गया है.

<DisplayName>

इस एट्रिब्यूट का इस्तेमाल, name एट्रिब्यूट के साथ किया जाता है. इससे, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) के प्रॉक्सी एडिटर में नीति को लेबल किया जा सकता है. इसके लिए, किसी दूसरे और ज़्यादा स्वाभाविक नाम का इस्तेमाल किया जाता है.

<DisplayName> एलिमेंट, सभी नीतियों में शामिल होता है.

डिफ़ॉल्ट वैल्यू लागू नहीं
ज़रूरी है? ज़रूरी नहीं. <DisplayName> को शामिल न करने पर, नीति के name एट्रिब्यूट की वैल्यू का इस्तेमाल किया जाता है
टाइप स्ट्रिंग
पैरंट एलिमेंट <PolicyElement>
चाइल्ड एलिमेंट कोई नहीं

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

सिंटैक्स

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

उदाहरण

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

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

<Element>

इस पैरामीटर से, मैसेज में मौजूद उस एलिमेंट के बारे में पता चलता है जिसकी पुष्टि करनी है. यह SOAP अनुरोध के एनवलप में मौजूद <Body> एलिमेंट का पहला चाइल्ड है.

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

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

सिंटैक्स

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

उदाहरण 1

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

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

उदाहरण 2

एक से ज़्यादा एलिमेंट की पुष्टि करने के लिए, एक से ज़्यादा <Element> एलिमेंट जोड़े जा सकते हैं:

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

<Element> एलिमेंट में ये एट्रिब्यूट होते हैं:

एट्रिब्यूट डिफ़ॉल्ट ज़रूरी है? ब्यौरा
namespace "http://sample.com" वैकल्पिक यह एट्रिब्यूट, पुष्टि किए जाने वाले एलिमेंट के नेमस्पेस के बारे में बताता है.

<ResourceURL>

यह XSD स्कीमा या WSDL की परिभाषा की पहचान करता है. इसका इस्तेमाल सोर्स मैसेज की पुष्टि करने के लिए किया जाता है.

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

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

सिंटैक्स

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

उदाहरण

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

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

WSDL के लिए:

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

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

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

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

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

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

यहां दिए गए स्कीमा के उदाहरण में कई XSD शामिल हैं:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:include schemaLocation="xsd://note-schema.xsd"/>
  <xs:include schemaLocation="xsd://letter-schema.xsd"/>
  <xs:include schemaLocation="xsd://user-schema.xsd"/>
</xs:schema>

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

WSDL में कम से कम एक स्कीमा तय किया जाना चाहिए. अगर इसमें कम से कम एक स्कीमा का रेफ़रंस नहीं दिया गया है, तो मैसेज की पुष्टि करने से जुड़ी नीति का उल्लंघन होता है.

किसी स्कीमा के लिए, इंपोर्ट करने की ज़्यादा से ज़्यादा सीमा 10 है. अगर नेस्ट किए गए इंपोर्ट की संख्या इससे ज़्यादा होती है, तो मैसेज की पुष्टि करने से जुड़ी नीति का उल्लंघन होता है.

<SOAPMessage>

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

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

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

सिंटैक्स

...
  <SOAPMessage version="[ 1.1 | 1.2 | 1.1/1.2 ]"/>
...

उदाहरण

...
<SOAPMessage version="1.1"/>
...

<SOAPMessage> एलिमेंट में ये एट्रिब्यूट होते हैं:

एट्रिब्यूट डिफ़ॉल्ट ज़रूरी है? ब्यौरा
version कोई नहीं वैकल्पिक यह नीति, SOAP मैसेज की पुष्टि करने के लिए SOAP के जिस वर्शन का इस्तेमाल करती है.

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

  • "1.1"
  • "1.2"
  • "1.1/1.2"

ज़्यादा जानकारी के लिए, 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 की नीतियों से मिली गड़बड़ियों का फ़ॉर्मैट एक जैसा होता है. इसके बारे में गड़बड़ी के कोड का रेफ़रंस में बताया गया है.

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code HTTP status Cause Fix
steps.messagevalidation.SourceMessageNotAvailable 500

This error occurs if a variable specified in the <Source> element of the policy is either:

  • out of scope (not available in the specific flow where the policy is being executed)
    • or
  • can't be resolved (is not defined)
steps.messagevalidation.NonMessageVariable 500

This error occurs if the <Source> element in the SOAPMessageValidation policy is set to a variable which is not of type message.

Message type variables represent entire HTTP requests and responses. The built-in Edge flow variables request, response, and message are of type message. To learn more about message variables, see the Variables reference.
steps.messagevalidation.Failed 500 This error occurs if the SOAPMessageValidation policy fails to validate the input message payload against the XSD schema or WSDL definition. It will also occur if there is malformed JSON or XML in the payload message.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Error name Cause Fix
InvalidResourceType The <ResourceURL> element in the SOAPMessageValidation policy is set to a resource type not supported by the policy.
ResourceCompileFailed The resource script referenced in the <ResourceURL> element of the SOAPMessageValidation policy contains an error that prevents it from compiling.
RootElementNameUnspecified The <Element> element in the SOAPMessageValidation policy does not contain the root element's name.
InvalidRootElementName The <Element> element in the SOAPMessageValidation policy contains a root element name that does not adhere to XML rules for valid element naming.

स्कीमा

नीति के हर टाइप को एक्सएमएल स्कीमा (.xsd) के ज़रिए तय किया जाता है. रेफ़रंस के लिए, नीति के स्कीमा GitHub पर उपलब्ध हैं.

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