خط مشی SOAPMessageValidation

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید .
اطلاعات

سیاست SOAPMessageValidation موارد زیر را انجام می‌دهد:

  • هر پیام XML را در برابر طرحواره‌های XSD آنها اعتبارسنجی می‌کند.
  • پیام‌های SOAP را در برابر تعریف 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>

این عنصر دارای ویژگی های زیر است که در همه سیاست ها مشترک است:

صفت پیش فرض ضروری؟ شرح
name N/A ضروری

نام داخلی سیاست. مقدار مشخصه name می تواند شامل حروف، اعداد، فاصله، خط تیره، زیرخط و نقطه باشد. این مقدار نمی تواند بیش از 255 کاراکتر باشد.

در صورت تمایل، از عنصر <DisplayName> برای برچسب گذاری خط مشی در ویرایشگر پروکسی UI مدیریت با نامی به زبان طبیعی دیگر استفاده کنید.

continueOnError نادرست اختیاری برای بازگرداندن خطا در صورت شکست خط مشی، روی "false" تنظیم کنید. این رفتار مورد انتظار برای اکثر سیاست ها است. روی "true" تنظیم کنید تا اجرای جریان حتی پس از شکست خط مشی ادامه یابد.
enabled درست است، واقعی اختیاری برای اجرای این خط‌مشی روی «درست» تنظیم کنید. برای «خاموش کردن» خط مشی، روی «نادرست» تنظیم کنید. این سیاست حتی اگر به یک جریان وابسته باشد اجرا نخواهد شد.
async نادرست منسوخ این ویژگی منسوخ شده است.

مثال‌ها

مثال‌های زیر برخی از روش‌های استفاده از سیاست اعتبارسنجی پیام را نشان می‌دهند:

۱: اعتبارسنجی XSD

شما می‌توانید از سیاست اعتبارسنجی پیام برای اعتبارسنجی بار داده‌ی درخواست پیام XML در برابر طرحواره‌ی 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. مکان فایل منبع XSD خود را با عنصر <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>
  3. همانطور که در مثال زیر نشان داده شده است، یک درخواست POST به پروکسی API خود با XML خود به عنوان payload پیام ارسال کنید:
    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" تنظیم شده است.

    همچنین می‌توانید یک فایل داده برای payload ایجاد کنید و با دستوری مشابه دستور زیر به آن ارجاع دهید:

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

شما باید یک خطای اعتبارسنجی دریافت کنید.

۲: اعتبارسنجی SOAP

شما می‌توانید از سیاست اعتبارسنجی پیام (Message Validation Policy) برای اعتبارسنجی محتوای درخواست پیام SOAP در برابر WSDL استفاده کنید.

  1. یک فایل منبع WSDL جدید ایجاد کنید. برای مثال، "example-wsdl.wsdl":
  2. سیاست اعتبارسنجی پیام SOAP را به پیش‌جریان نقطه پایانی پروکسی خود اضافه کنید:
    1. ویژگی version عنصر <SOAPMessage> را روی نسخه پروتکل SOAP که می‌خواهید اعتبارسنجی را با آن انجام دهید، تنظیم کنید. برای مثال، "1.1":
      ...
        <SOAPMessage version="1.1"/>
      ...
    2. مقدار عنصر <Element> را برابر عنصری که می‌خواهید اعتبارسنجی شود، قرار دهید:
      ...
        <Element namespace="https://example.com/gateway">getID</Element>
      ...

      <Element> اولین فرزند زیر عنصر <Body> در پوشش درخواست SOAP را مشخص می‌کند.

      ویژگی namespace را روی namespace مربوط به آن فرزند تنظیم کنید.

    3. محل فایل منبع WSDL خود را با عنصر <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>
  3. همانطور که در مثال زیر نشان داده شده است، یک درخواست POST به پروکسی API خود با پاکت 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" تنظیم شده است.

    همچنین می‌توانید یک فایل داده برای payload ایجاد کنید و با دستوری مشابه دستور زیر به آن ارجاع دهید:

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

۳: XML/JSON خوش‌فرم

شما می‌توانید از سیاست اعتبارسنجی پیام برای تأیید صحت ساختار یک پیام JSON یا XML استفاده کنید (که با اعتبارسنجی یکسان نیست). این سیاست تضمین می‌کند که ساختار و محتوا مطابق با استانداردهای پذیرفته‌شده، از جمله موارد زیر، باشد:

  • یک عنصر ریشه واحد وجود دارد
  • هیچ کاراکتر غیرمجازی در محتوا وجود ندارد
  • اشیاء و برچسب‌ها به درستی تودرتو شده‌اند
  • تگ‌های شروع و پایان با هم مطابقت دارند

برای بررسی یک payload خوش‌فرم 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 به پروکسی API خود ارسال کنید:
    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" تنظیم شده است.

    برای بررسی صحت ساختار یک فایل XML ، از XML به عنوان payload پیام استفاده کنید و Content-type را روی "application/xml" تنظیم کنید.

شما باید یک پاسخ HTTP 200 دریافت کنید. وقتی یک payload پیام ارسال می‌کنید که حاوی XML یا JSON خوش‌فرم نیست، باید خطای steps.messagevalidation.Failed دریافت کنید.

مرجع عنصر فرزند

این بخش عناصر فرزند <MessageValidation> را شرح می‌دهد.

<DisplayName>

علاوه بر ویژگی name ، برای برچسب گذاری خط مشی در ویرایشگر پروکسی رابط کاربری مدیریت با نامی متفاوت و طبیعی تر، از آن استفاده کنید.

عنصر <DisplayName> در همه خط مشی ها مشترک است.

مقدار پیش فرض n/a
مورد نیاز؟ اختیاری. اگر <DisplayName> را حذف کنید، از مقدار ویژگی name خط مشی استفاده می شود
تایپ کنید رشته
عنصر والد < PolicyElement >
عناصر کودک هیچ کدام

عنصر <DisplayName> از نحو زیر استفاده می کند:

نحو

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

مثال

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

عنصر <DisplayName> هیچ ویژگی یا عنصر فرزند ندارد.

<Element>

عنصری را در پیام که باید اعتبارسنجی شود، مشخص می‌کند. این اولین فرزند زیر عنصر <Body> در پوشش درخواست SOAP است.

مقدار پیش‌فرض نمونه شیء
الزامی است؟ اختیاری
نوع رشته
عنصر والد <MessageValidation>
عناصر فرزند هیچکدام

عنصر <Element> از سینتکس زیر استفاده می‌کند:

نحو

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

مثال ۱

مثال زیر یک عنصر واحد را برای اعتبارسنجی تعریف می‌کند:

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

مثال ۲

شما می‌توانید با اضافه کردن چندین عنصر <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>
...

مثال‌ها

برای یک فایل XML:

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

برای یک WSDL:

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

مقدار <ResourceURL> باید به یک فایل منبع در پروکسی API شما اشاره کند. نمی‌تواند به منابع خارجی از طریق HTTP یا HTTPS اشاره کند.

اگر مقداری برای <ResourceURL> مشخص نکنید، اگر هدر Content-type به ترتیب "application/json" یا "application/xml" باشد، پیام از نظر JSON یا XML بررسی می‌شود.

عنصر <ResourceURL> هیچ عنصر فرزند یا ویژگی‌ای ندارد.

استفاده از XSD برای اعتبارسنجی

اگر فایل XML که با استفاده از سیاست اعتبارسنجی پیام (Message Validation Policy) اعتبارسنجی می‌کنید، به طرحواره‌ی دیگری ارجاع می‌دهد، باید در ویژگی schemaLocation پیشوند xsd را به فایل 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 باید حداقل یک طرحواره را تعریف کند. اگر حداقل به یک طرحواره اشاره نکند، سیاست اعتبارسنجی پیام با شکست مواجه می‌شود.

حداکثر عمق وارد کردن برای یک طرحواره ۱۰ است. اگر تعداد وارد کردن‌های تو در تو از این تعداد بیشتر شود، سیاست اعتبارسنجی پیام با شکست مواجه می‌شود.

<SOAPMessage>

نسخه SOAP را که سیاست اعتبارسنجی پیام با آن اعتبارسنجی می‌شود، تعریف می‌کند.

مقدار پیش‌فرض ناموجود
الزامی است؟ اختیاری
نوع ناموجود
عنصر والد <MessageValidation>
عناصر فرزند هیچکدام

عنصر <SOAPMessage> از سینتکس زیر استفاده می‌کند:

نحو

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

مثال

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

عنصر <SOAPMessage> دارای ویژگی‌های زیر است:

ویژگی پیش‌فرض الزامی است؟ توضیحات
version هیچکدام اختیاری نسخه SOAP که این خط‌مشی برای اعتبارسنجی پیام‌های SOAP استفاده می‌کند.

مقادیر معتبر عبارتند از:

  • «۱.۱»
  • «۱.۲»
  • «۱.۱/۱.۲»

برای اطلاعات بیشتر، به «از SOAP/1.1 تا SOAP نسخه 1.2» در 9 نکته مراجعه کنید.

<Source>

پیام منبعی که باید اعتبارسنجی شود را شناسایی می‌کند. مقدار این عنصر، نام پیامی است که می‌خواهید اعتبارسنجی شود.

اگر <Source> را تنظیم نکنید، این خط‌مشی به صورت پیش‌فرض روی "message" تنظیم می‌شود که به پیام کامل درخواست (در یک جریان درخواست) یا پیام پاسخ (در یک جریان پاسخ)، شامل هرگونه محتوای داده، اشاره دارد. همچنین می‌توانید آن را به صراحت روی "request" یا "response" تنظیم کنید تا به درخواست یا پاسخ اشاره کند.

مقدار پیش‌فرض درخواست
الزامی است؟ اختیاری
نوع رشته
عنصر والد <MessageValidation>
عناصر فرزند هیچکدام

عنصر <Source> از سینتکس زیر استفاده می‌کند:

نحو

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

مثال

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

علاوه بر "پیام"، "درخواست" و "پاسخ"، می‌توانید مقدار <Source> را روی نام هر پیامی در جریان خود تنظیم کنید. با این حال، اگر این کار را انجام دهید، باید قبل از اجرای این خط‌مشی، یک پیام سفارشی با آن نام در جریان خود ایجاد کنید. در غیر این صورت، با خطا مواجه خواهید شد.

اگر مقدار <Source> در جریان پیام قابل تفسیر نباشد یا به نوعی غیر از پیام تفسیر شود، یکی از موارد زیر رخ می‌دهد:

  • اگر مقدار null باشد: Edge خطای steps.messagevalidation.SourceMessageNotAvailable را نمایش می‌دهد.
  • اگر نوع داده غیر از نوع پیام باشد: Edge خطای steps.messagevalidation.NonMessageVariable را نمایش می‌دهد.

عنصر <Source> هیچ ویژگی یا عنصر فرزندی ندارد.

کدهای خطا

خطاهایی که از سیاست‌های Edge برگردانده می‌شوند، از یک قالب ثابت پیروی می‌کنند، همانطور که در مرجع کد خطا توضیح داده شده است.

این بخش کدهای خطا و پیام‌های خطایی را که برگردانده می‌شوند و متغیرهای خطا را که توسط Edge تنظیم می‌شوند، هنگامی که این خط‌مشی خطا را راه‌اندازی می‌کند، توضیح می‌دهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.

خطاهای زمان اجرا

این خطاها ممکن است هنگام اجرای سیاست رخ دهند.

کد خطا وضعیت HTTP علت ثابت
steps.messagevalidation.SourceMessageNotAvailable 500

این خطا در صورتی رخ می دهد که متغیری که در عنصر <Source> خط مشی مشخص شده است یکی از این موارد باشد:

  • خارج از محدوده (در جریان خاصی که سیاست در آن اجرا می شود موجود نیست)
  • یا
  • قابل حل نیست (تعریف نشده است)
steps.messagevalidation.NonMessageVariable 500

اگر عنصر <Source> در خط مشی SOAPMessageValidation روی متغیری تنظیم شود که از نوع پیام نیست، این خطا رخ می دهد.

متغیرهای نوع پیام، کل درخواست‌ها و پاسخ‌های HTTP را نشان می‌دهند. متغیرهای جریان لبه داخلی request ، response و message از نوع پیام هستند. برای کسب اطلاعات بیشتر در مورد متغیرهای پیام، به مرجع متغیرها مراجعه کنید.

steps.messagevalidation.Failed 500 این خطا در صورتی رخ می دهد که خط مشی SOAPMessageValidation نتواند بار پیام ورودی را در برابر طرح XSD یا تعریف WSDL تأیید کند. همچنین اگر JSON یا XML نادرست در پیام بارگذاری وجود داشته باشد، رخ می دهد.

خطاهای استقرار

این خطاها ممکن است زمانی رخ دهند که یک پروکسی حاوی این خط مشی را مستقر می کنید.

نام خطا علت ثابت
InvalidResourceType عنصر <ResourceURL> در خط مشی SOAPMessageValidation روی یک نوع منبع تنظیم شده است که توسط این خط مشی پشتیبانی نمی شود.
ResourceCompileFailed اسکریپت منبع ارجاع شده در عنصر <ResourceURL> خط مشی SOAPMessageValidation حاوی خطایی است که از کامپایل آن جلوگیری می کند.
RootElementNameUnspecified عنصر <Element> در خط مشی SOAPMessageValidation حاوی نام عنصر ریشه نیست.
InvalidRootElementName عنصر <Element> در خط مشی SOAPMessageValidation حاوی یک نام عنصر ریشه است که برای نامگذاری عنصر معتبر به قوانین XML پایبند نیست.
،

این بخش کدهای خطا و پیام‌های خطایی را که برگردانده می‌شوند و متغیرهای خطا را که توسط Edge تنظیم می‌شوند، هنگامی که این خط‌مشی خطا را راه‌اندازی می‌کند، توضیح می‌دهد. این اطلاعات برای دانستن اینکه آیا در حال توسعه قوانین خطا برای رسیدگی به خطاها هستید، مهم است. برای کسب اطلاعات بیشتر، آنچه را که باید در مورد خطاهای خط مشی و مدیریت خطاها بدانید را ببینید.

خطاهای زمان اجرا

این خطاها ممکن است هنگام اجرای سیاست رخ دهند.

کد خطا وضعیت HTTP علت ثابت
steps.messagevalidation.SourceMessageNotAvailable 500

این خطا در صورتی رخ می دهد که متغیری که در عنصر <Source> خط مشی مشخص شده است یکی از این موارد باشد:

  • خارج از محدوده (در جریان خاصی که سیاست در آن اجرا می شود موجود نیست)
  • یا
  • قابل حل نیست (تعریف نشده است)
steps.messagevalidation.NonMessageVariable 500

اگر عنصر <Source> در خط مشی SOAPMessageValidation روی متغیری تنظیم شود که از نوع پیام نیست، این خطا رخ می دهد.

متغیرهای نوع پیام، کل درخواست‌ها و پاسخ‌های HTTP را نشان می‌دهند. متغیرهای جریان لبه داخلی request ، response و message از نوع پیام هستند. برای کسب اطلاعات بیشتر در مورد متغیرهای پیام، به مرجع متغیرها مراجعه کنید.

steps.messagevalidation.Failed 500 این خطا در صورتی رخ می دهد که خط مشی SOAPMessageValidation نتواند بار پیام ورودی را در برابر طرح XSD یا تعریف WSDL تأیید کند. همچنین اگر JSON یا XML نادرست در پیام بارگذاری وجود داشته باشد، رخ می دهد.

خطاهای استقرار

این خطاها ممکن است زمانی رخ دهند که یک پروکسی حاوی این خط مشی را مستقر می کنید.

نام خطا علت ثابت
InvalidResourceType عنصر <ResourceURL> در خط مشی SOAPMessageValidation روی یک نوع منبع تنظیم شده است که توسط این خط مشی پشتیبانی نمی شود.
ResourceCompileFailed اسکریپت منبع ارجاع شده در عنصر <ResourceURL> خط مشی SOAPMessageValidation حاوی خطایی است که از کامپایل آن جلوگیری می کند.
RootElementNameUnspecified عنصر <Element> در خط مشی SOAPMessageValidation حاوی نام عنصر ریشه نیست.
InvalidRootElementName عنصر <Element> در خط مشی SOAPMessageValidation حاوی یک نام عنصر ریشه است که برای نامگذاری عنصر معتبر به قوانین XML پایبند نیست.

طرحواره‌ها

هر نوع سیاست توسط یک طرح XML ( .xsd ) تعریف می‌شود. برای مرجع، طرح‌های سیاست در GitHub موجود است.

مباحث مرتبط