‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מדיניות SOAPMessageValidation

אתם קוראים את מסמכי התיעוד של Apigee Edge.
למעבר אל מסמכי התיעוד של Apigee X info

המדיניות SOAPMessageValidation מבצעת את הפעולות הבאות:

מאמת כל הודעת XML מול סכימות ה-XSD שלה
אימות הודעות SOAP לפי הגדרת WSDL
קובע אם הודעות JSON ו-XML הן בפורמט תקין

למרות שהשם של המדיניות הזו בממשק המשתמש הוא "אימות הודעות SOAP", המדיניות מאמתת יותר מסתם הודעות SOAP. בקטע הזה, המדיניות נקראת "מדיניות אימות ההודעות".

מידע על המדיניות בנושא אימות הודעות

יתרונות

היתרונות של אימות הודעות:

מודיע באופן מיידי למפתחי אפליקציות שמשתמשים ב-API שלכם אם הבקשות שלהם לא תואמות או לא מלאות.
מצביע על בעיות בבקשות, כמו תגי XML שלא נסגרו כמו שצריך.
הגנה על שירותים לקצה העורפי על ידי חסימת הודעות XML או SOAP עם מבנים שעלולים לגרום להתנהגות בלתי צפויה.
חוסך זמן שהייתם משקיעים בפתרון בעיות, בחיפוש בפורומים או בהתייעצות עם התמיכה הטכנית.
מעודד את המפתחים להכיר את הגדרת ה-WSDL של סכימת ה-XML כדי למנוע שגיאות אימות, ולהפוך סכימות XML מובנות היטב לרכיב מרכזי במאמרי העזרה של ה-API.

סרטונים

כדי לקבל מידע נוסף על המדיניות בנושא אימות הודעות, כדאי לצפות בסרטונים הבאים:

וידאו	תיאור
אימות בקשת XML	אימות בקשת ה-XML ל-API באמצעות המדיניות Message Validation.
אימות בקשת JSON	אימות בקשת ה-JSON ל-API באמצעות מדיניות אימות ההודעות.

רכיב `<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>

מדיניות ברירת המחדל

בדוגמה הבאה מוצגות הגדרות ברירת המחדל כשמוסיפים מדיניות Message Validation לתהליך בממשק המשתמש של 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>` כדי להוסיף תווית למדיניות בכלי לעריכת שרת proxy של ממשק המשתמש לניהול, ולהשתמש בשם אחר בשפה טבעית.
`continueOnError`	false	אופציונלי	צריך להגדיר את הערך 'False' כדי להחזיר שגיאה כשהמדיניות נכשלת. זו התנהגות צפויה ברוב סוגי המדיניות. הערך של הפרמטר הוא TRUE כדי שביצוע הפעולות יתבצע גם אחרי שמדיניות תיכשל.
`enabled`	true	אופציונלי	כדי לאכוף את המדיניות צריך להגדיר את הערך True. מגדירים את המדיניות כ-"false" כדי "להשבית" את המדיניות. המדיניות הזו לא תיאכף גם אם היא תצורף לתהליך.
`async`	false	הוצא משימוש	המאפיין הזה הוצא משימוש.

דוגמאות

הדוגמאות הבאות מראות כמה מהדרכים שבהן אפשר להשתמש במדיניות Message Validation:

‫1: אימות XSD

אפשר להשתמש במדיניות Message Validation כדי לאמת את המטען הייעודי (payload) של בקשת הודעת XML מול סכימת XSD.

יוצרים קובץ משאבים חדש בפורמט 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 Message Validation ל-pre-flow של נקודת הקצה של שרת ה-proxy:
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>
```

שולחים בקשת POST לשרת ה-proxy ל-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. בהתאם לנקודת הקצה (endpoint) של היעד, יכול להיות שתקבלו פרטים נוספים על הבקשה. לדוגמה, אם משתמשים ב-http://httpbin.org/post כנקודת הקצה (endpoint) המטורגטת ומציינים פלט -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

אפשר להשתמש במדיניות Message Validation כדי לאמת את המטען הייעודי (payload) של בקשת הודעת SOAP מול WSDL.

יוצרים קובץ משאבים חדש של 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>

מוסיפים את המדיניות SOAP Message Validation ל-pre-flow של נקודת הקצה של שרת ה-proxy:
1. מגדירים את המאפיין version של הרכיב <SOAPMessage> לגרסה של פרוטוקול SOAP שרוצים לאמת מולה. לדוגמה, "1.1":
```
...
  <SOAPMessage version="1.1"/>
...
```
2. מגדירים את הערך של הרכיב <Element> לרכיב שרוצים לאמת:
```
...
  <Element namespace="https://example.com/gateway">getID</Element>
...
```
  ‫<Element> מציין את הצאצא הראשון של הרכיב <Body> במעטפת של בקשת ה-SOAP.
  
  מגדירים את המאפיין 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>
```

שולחים בקשת POST לשרת ה-proxy ל-API עם מעטפת ה-SOAP כמטען הייעודי (payload) של ההודעה, כמו בדוגמה הבאה:

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. בהתאם לנקודת הקצה (endpoint) של היעד, יכול להיות שתקבלו פרטים נוספים על הבקשה. לדוגמה, אם משתמשים ב-http://httpbin.org/post כנקודת הקצה (endpoint) המטורגטת, התשובה אמורה להיות דומה לזו:

< 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 בפורמט תקין

אתם יכולים להשתמש במדיניות Message Validation כדי לוודא שהמטען הייעודי (payload) של הודעת JSON או XML הוא בפורמט תקין (לא זהה לאימות). המדיניות מבטיחה שהמבנה והתוכן עומדים בסטנדרטים המקובלים, כולל:

יש רכיב בסיס אחד
אין בתוכן תווים לא חוקיים
האובייקטים והתגים מסודרים נכון
תגי ההתחלה והסיום תואמים

כדי לבדוק אם המטען הייעודי (payload) של XML או JSON תקין:

מוסיפים את המדיניות "אימות הודעות SOAP" ל-pre-flow של נקודת הקצה של שרת ה-proxy.

מסירים את הרכיבים <ResourceURL>,‏ <SOAPMessage> ו-<Element> מהגדרת המדיניות.

הגדרת המדיניות אמורה להיראות כך:

<MessageValidation async="false" continueOnError="false"
    enabled="true" name="validateXMLRequest">
  <DisplayName>My JSON Checker</DisplayName>
  <Properties/>
  <Source>request</Source>
</MessageValidation>

שולחים בקשת POST לשרת ה-proxy ל-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 כדי לתייג את המדיניות בעורך ה-proxy של ממשק המשתמש לניהול בשם אחר, שנשמע טבעי יותר.

הרכיב <DisplayName> משותף לכל כללי המדיניות.

ערך ברירת המחדל	לא רלוונטי
חובה?	אופציונלי. אם משמיטים את `<DisplayName>`, המערכת משתמשת בערך של המאפיין `name` של המדיניות.
סוג	מחרוזת
רכיב הורה	<`PolicyElement`>
רכיבי צאצא	ללא

הרכיב <DisplayName> משתמש בתחביר הבא:

תחביר

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

דוגמה

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

לאלמנט <DisplayName> אין מאפיינים או אלמנטים צאצאים.

`<Element>`

מציין את הרכיב בהודעה שצריך לאמת. זהו הצאצא הראשון של הרכיב <Body> במעטפת של בקשת ה-SOAP.

ערך ברירת המחדל	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>
...

דוגמאות

בקובץ XML:

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

ל-WSDL:

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

הערך של <ResourceURL> חייב להפנות לקובץ משאבים ב-proxy ל-API. הוא לא יכול להפנות למשאבים חיצוניים דרך HTTP או HTTPS.

אם לא מציינים ערך ל-<ResourceURL>, ההודעה נבדקת כדי לוודא שהיא בפורמט JSON או XML תקין, אם הכותרת Content-type היא "application/json" או "application/xml", בהתאמה.

לאלמנט <ResourceURL> אין אלמנטים או מאפיינים של צאצאים.

שימוש ב-XSD לאימות

אם המטען הייעודי (payload) של ה-XML שאתם מאמתים באמצעות המדיניות Message Validation מפנה לסכימה אחרת, אתם צריכים להוסיף את הקידומת 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"

version

ללא

אופציונלי

גרסת ה-SOAP שבה המדיניות הזו משתמשת כדי לאמת הודעות SOAP.

הערכים החוקיים כוללים:

"1.1"
"1.2"
"1.1/1.2"

מידע נוסף זמין במאמר From SOAP/1.1 to SOAP Version 1.2 in 9 points.

`<Source>`

מזהה את הודעת המקור שצריך לאמת. הערך של הרכיב הזה הוא שם ההודעה שרוצים לאמת.

אם לא מגדירים את <Source>, ברירת המחדל של המדיניות הזו היא "message", שמתייחסת להודעת הבקשה המלאה (בתהליך בקשה) או להודעת התגובה המלאה (בתהליך תגובה), כולל המטען הייעודי (payload). אפשר גם להגדיר אותו באופן מפורש ל-"request" או ל-"response" כדי להתייחס לבקשה או לתגובה.

ערך ברירת המחדל	בקשה
חובה?	אופציונלי
סוג	מחרוזת
רכיב הורה	`<MessageValidation>`
רכיבי צאצא	ללא

הרכיב <Source> משתמש בתחביר הבא:

תחביר

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

דוגמה

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

בנוסף ל-"message",‏ "request" ו-"response", אתם יכולים להגדיר את הערך של <Source> לשם של כל הודעה בתהליך. אבל אם עושים את זה, צריך ליצור הודעה בהתאמה אישית עם השם הזה בתהליך לפני שהמדיניות הזו מופעלת. אחרת, תופיע הודעת שגיאה.

אם אי אפשר לפתור את הערך של <Source> בתהליך ההודעה או שהוא נפתר לסוג שהוא לא הודעה, מתרחש אחד מהמקרים הבאים:

אם הערך הוא null: הדפדפן Edge מקפיץ שגיאת steps.messagevalidation.SourceMessageNotAvailable.
אם זה לא סוג של הודעה: Edge מחזיר שגיאת steps.messagevalidation.NonMessageVariable.

לאלמנט <Source> אין מאפיינים או אלמנטים צאצאים.

קודי שגיאה

השגיאות שמוחזרות ממדיניות Edge הן בפורמט עקבי, כמו שמתואר בהפניה לקודי שגיאה.

בקטע הזה מתוארים קודי התקלות והודעות השגיאה שמוחזרים, ומשתני השגיאה שמוגדרים על ידי Edge כשהמדיניות הזו גורמת לשגיאה. חשוב לדעת אם אתם מפתחים כללים לתיקון תקלות. מידע נוסף זמין במאמר מה צריך לדעת על שגיאות מדיניות ועל טיפול בפגמים.

שגיאות בזמן ריצה

השגיאות האלה יכולות להתרחש כשהמדיניות מופעלת.

קוד שגיאה סטטוס HTTP סיבה תיקון

קוד שגיאה	סטטוס HTTP	סיבה
`steps.messagevalidation.SourceMessageNotAvailable`	500	השגיאה הזו מתרחשת אם משתנה שצוין ברכיב `<Source>` של המדיניות הוא: מחוץ להיקף (לא זמין בתהליך הספציפי שבו המדיניות מיושמת) או לא ניתן לפענח (אינו מוגדר)
`steps.messagevalidation.NonMessageVariable`	500	השגיאה הזו מתרחשת אם הרכיב `<Source>` במדיניות SOAPMessageAuthentication מוגדר למשתנה שאינו מסוג message. משתנים של סוגי הודעות מייצגים את כל הבקשות והתגובות של HTTP. משתני הזרימה המובנים של Edge `request`, `response` ו-`message` הם מסוג הודעה. מידע נוסף על משתני הודעות זמין בחומר העזר בנושא משתנים.
`steps.messagevalidation.Failed`	500	השגיאה הזו מתרחשת אם המדיניות SOAPMessageValidation לא מאמתת את המטען הייעודי (payload) של הודעת הקלט מול סכימת XSD או ההגדרה של WSDL. זה יקרה גם אם בהודעת המטען הייעודי (payload) יש JSON או XML לא תקינים.

steps.messagevalidation.SourceMessageNotAvailable

500

השגיאה הזו מתרחשת אם משתנה שצוין ברכיב <Source> של המדיניות הוא:

מחוץ להיקף (לא זמין בתהליך הספציפי שבו המדיניות מיושמת)
לא ניתן לפענח (אינו מוגדר)

steps.messagevalidation.NonMessageVariable

500

השגיאה הזו מתרחשת אם הרכיב <Source> במדיניות SOAPMessageAuthentication מוגדר למשתנה שאינו מסוג message.

משתנים של סוגי הודעות מייצגים את כל הבקשות והתגובות של HTTP. משתני הזרימה המובנים של Edge request, response ו-message הם מסוג הודעה. מידע נוסף על משתני הודעות זמין בחומר העזר בנושא משתנים.

steps.messagevalidation.Failed 500 השגיאה הזו מתרחשת אם המדיניות SOAPMessageValidation לא מאמתת את המטען הייעודי (payload) של הודעת הקלט מול סכימת XSD או ההגדרה של WSDL. זה יקרה גם אם בהודעת המטען הייעודי (payload) יש JSON או XML לא תקינים.

שגיאות בפריסה

השגיאות האלה יכולות להתרחש כשפורסים שרת proxy שכולל את המדיניות הזו.

שם השגיאה	סיבה	תיקון
`InvalidResourceType`	הרכיב `<ResourceURL>` במדיניות SOAPMessageValidation מוגדר לסוג משאב שלא נתמך במדיניות.
`ResourceCompileFailed`	סקריפט המשאב שמפנה לרכיב `<ResourceURL>` במדיניות SOAPMessageValidation מכיל שגיאה שמונעת את ההידור שלו.
`RootElementNameUnspecified`	הרכיב `<Element>` במדיניות SOAPMessageValidation לא מכיל את השם של רכיב הבסיס.
`InvalidRootElementName`	הרכיב `<Element>` במדיניות SOAPMessageValidation מכיל שם של רכיב בסיס שלא תואם לכללי ה-XML למתן שמות חוקיים לרכיבים.

סכימות

כל סוג מדיניות מוגדר על ידי סכימת XML‏ (.xsd). סכימות המדיניות זמינות ב-GitHub.

מדיניות SOAPMessageValidation

מידע על המדיניות בנושא אימות הודעות

יתרונות

סרטונים

רכיב <MessageValidation>

תחביר

מדיניות ברירת המחדל

דוגמאות

‫1: אימות XSD

‫2: אימות SOAP

‫3: קובץ XML או JSON בפורמט תקין

הפניה לרכיב צאצא

<DisplayName>

תחביר

דוגמה

<Element>

תחביר

דוגמה 1

דוגמה 2

<ResourceURL>

תחביר

דוגמאות

שימוש ב-XSD לאימות

שימוש ב-WSDL לאימות

<SOAPMessage>

תחביר

דוגמה

<Source>

תחביר

דוגמה

קודי שגיאה

שגיאות בזמן ריצה

שגיאות בפריסה

סכימות

נושאים קשורים

רכיב `<MessageValidation>`

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`