Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
Apigee X के दस्तावेज़. जानकारी पर जाएं
![](https://docs.apigee.com/static/api-platform/images/icon_policy_mediation.jpg?hl=hi)
SOAPMessageValidation नीति ये काम करती है:
- किसी भी एक्सएमएल मैसेज की उनके XSD स्कीमा के ख़िलाफ़ पुष्टि करता है
- WSDL की परिभाषा के ख़िलाफ़ एसओएपी मैसेज की पुष्टि करता है
- यह तय करता है कि 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 |
लागू नहीं | ज़रूरी |
नीति का अंदरूनी नाम. इसके अलावा, मैनेजमेंट एलिमेंट के यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, नीति एलिमेंट को किसी अलग नाम से इस्तेमाल करने के लिए, |
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>
- अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, एसओएपी मैसेज की पुष्टि करने से जुड़ी नीति जोड़ें:
<ResourceURL>
एलिमेंट का इस्तेमाल करके, अपनी एक्सएसडी रिसॉर्स फ़ाइल की जगह बताएं. उदाहरण के लिए:... <ResourceURL>xsd://note-schema.xsd</ResourceURL> ...
- नीति की परिभाषा से
<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
हेडर "ऐप्लिकेशन/एक्सएमएल" पर सेट है.आपके पास पेलोड के लिए डेटा फ़ाइल बनाने और इसकी जानकारी देने के लिए, नीचे दिए गए निर्देशों से मिलते-जुलते निर्देश देने का विकल्प भी है:
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: एसओएपी पुष्टि
मैसेज की पुष्टि करने से जुड़ी नीति का इस्तेमाल करके, WSDL के लिए एसओएपी मैसेज के अनुरोध के पेलोड की पुष्टि की जा सकती है.
- नई WSDL संसाधन फ़ाइल बनाएं. उदाहरण के लिए, "example-wsdl.wsdl":
- अपने प्रॉक्सी एंडपॉइंट के प्री-फ़्लो में, एसओएपी मैसेज की पुष्टि करने से जुड़ी नीति जोड़ें:
<SOAPMessage>
एलिमेंट केversion
एट्रिब्यूट को उस एसओएपी प्रोटोकॉल के वर्शन पर सेट करें जिसकी पुष्टि करनी है. उदाहरण के लिए, "1.1":... <SOAPMessage version="1.1"/> ...
<Element>
एलिमेंट की वैल्यू को उस एलिमेंट पर सेट करें जिसकी आपको पुष्टि करनी है:... <Element namespace="https://example.com/gateway">getID</Element> ...
<Element>
एसओएपी अनुरोध के एन्वेलप में<Body>
एलिमेंट में पहले चाइल्ड के बारे में बताता है.namespace
एट्रिब्यूट को उस बच्चे के नेमस्पेस पर सेट करें.<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
हेडर "ऐप्लिकेशन/एक्सएमएल" पर सेट है.आपके पास पेलोड के लिए डेटा फ़ाइल बनाने और इसकी जानकारी देने के लिए, नीचे दिए गए निर्देशों से मिलते-जुलते निर्देश देने का विकल्प भी है:
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
Messages की पुष्टि करने से जुड़ी नीति का इस्तेमाल करके, यह पुष्टि की जा सकती है कि 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
हेडर, "ऐप्लिकेशन/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>
पुष्टि करने के लिए, मैसेज का एलिमेंट तय करता है. एसओएपी अनुरोध के एन्वेलप में,
<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>
एलिमेंट में कोई चाइल्ड एलिमेंट या एट्रिब्यूट नहीं है.
पुष्टि करने के लिए एक्सएसडी का इस्तेमाल करना
अगर Message Verified नीति की मदद से पुष्टि किए जाने वाले एक्सएमएल पेलोड की पुष्टि किसी दूसरे स्कीमा के साथ की जाती है, तो आपको 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 का इस्तेमाल करना
WSDL को कम से कम एक स्कीमा तय करना चाहिए. अगर यह कम से कम एक स्कीमा का रेफ़रंस नहीं देती है, तो मैसेज की पुष्टि करने की नीति काम नहीं करती है.
किसी स्कीमा के लिए, इंपोर्ट डेप्थ ज़्यादा से ज़्यादा 10 हो सकते हैं. अगर नेस्ट किए गए इंपोर्ट की संख्या पार हो जाने पर, मैसेज की पुष्टि करने की नीति काम नहीं करती, तो यह काम नहीं करती.
<SOAPMessage>
यह उस एसओएपी वर्शन के बारे में बताता है जिसके हिसाब से मैसेज की पुष्टि करने की नीति की पुष्टि होती है.
डिफ़ॉल्ट वैल्यू | लागू नहीं |
ज़रूरी है? | ज़रूरी नहीं |
स्ट्रीम किस तरह की है | लागू नहीं |
पैरंट एलिमेंट |
<MessageValidation>
|
बच्चों के एलिमेंट | कभी नहीं |
<SOAPMessage>
एलिमेंट इस सिंटैक्स का इस्तेमाल करता है:
सिंटैक्स
... <SOAPMessage version="[ 1.1 | 1.2 | 1.1/1.2 ]"/> ...
उदाहरण
... <SOAPMessage version="1.1"/> ...
<SOAPMessage>
एलिमेंट में ये एट्रिब्यूट शामिल होते हैं:
एट्रिब्यूट | डिफ़ॉल्ट | ज़रूरी है? | जानकारी |
---|---|---|---|
version |
कभी नहीं | ज़रूरी नहीं | एसओएपी वर्शन, जिसका इस्तेमाल यह नीति एसओएपी मैसेज की पुष्टि करने के लिए करती है.
मान्य मान हैं:
|
ज़्यादा जानकारी के लिए, 9 पॉइंट में SOAP/1.1 से SOAP वर्शन 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 |
यह गड़बड़ी तब होती है, जब नीति के
|
build |
steps.messagevalidation.NonMessageVariable |
500 |
यह गड़बड़ी तब होती है, जब SOAPMessage verification
नीति में मैसेज टाइप वैरिएबल से पूरे एचटीटीपी अनुरोध और उनके जवाब दिखते हैं. बिल्ट-इन Edge फ़्लो वैरिएबल |
build |
steps.messagevalidation.Failed |
500 | यह गड़बड़ी तब होती है, जब SOAPMessageValidation की नीति, XSD स्कीमा या WSDL की परिभाषा के हिसाब से इनपुट मैसेज पेलोड की पुष्टि नहीं कर पाती. ऐसा तब भी होगा, जब पेलोड मैसेज में गलत JSON या एक्सएमएल हो. | build |
डिप्लॉयमेंट से जुड़ी गड़बड़ियां
ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाले किसी प्रॉक्सी को डिप्लॉय किया जाता है.
गड़बड़ी का नाम | वजह | समाधान |
---|---|---|
InvalidResourceType |
SOAPMessageValidation नीति में <ResourceURL> एलिमेंट को ऐसे संसाधन प्रकार पर सेट किया गया है जो नीति के साथ काम नहीं करता.
|
build |
ResourceCompileFailed |
SOAPMessageTerms नीति के <ResourceURL> एलिमेंट में रेफ़र की गई संसाधन स्क्रिप्ट में, एक ऐसी गड़बड़ी है जो उसे कंपाइल करने से रोकती है.
|
build |
RootElementNameUnspecified |
SOAPMessageDescription नीति के <Element> एलिमेंट में रूट एलिमेंट का नाम शामिल नहीं है. |
build |
InvalidRootElementName |
SOAPMessage Verification नीति के <Element> एलिमेंट में रूट एलिमेंट का नाम शामिल है, जो मान्य एलिमेंट के नाम के लिए एक्सएमएल के नियमों का पालन नहीं करता है. |
build |
स्कीमा
हर तरह की नीति को एक्सएमएल स्कीमा (.xsd
) से तय किया जाता है. रेफ़रंस के लिए, नीति स्कीमा GitHub पर उपलब्ध हैं.