דף זה תורגם על ידי Cloud Translation API.

מדיניות SOAPMessageAuthentication

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

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

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

השם של המדיניות הזו בממשק המשתמש הוא 'SOAP Message Validation', אבל המדיניות מאמתת עובדות נוספות מאשר רק הודעות SOAP. הקטע הזה מתייחס למדיניות בתור 'המדיניות בנושא אימות הודעות'.

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

יתרונות

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

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

סרטונים

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

וידאו	תיאור
אימות ה-XML בקשה	משתמשים במדיניות לאימות הודעות כדי לאמת את בקשת ה-XML ל-API.
אימות קובץ 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>

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

בדוגמה הבאה מוצגות הגדרות ברירת המחדל בהוספת מדיניות לאימות הודעות בממשק המשתמש של 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	הוצא משימוש	המאפיין הזה הוצא משימוש.

דוגמאות

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

1: אימות XSD

אפשר להשתמש במדיניות לאימות הודעות כדי לאמת את המטען הייעודי (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 לתהליכי טרום-זרימה של נקודת הקצה של נקודת הקצה של שרת ה-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. בהתאם לנקודת הקצה שהגדרתם כיעד, יכול להיות שנשלח לך פרטים נוספים לגבי הבקשה. לדוגמה, אם משתמשים 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: אימות SOAP

אפשר להשתמש במדיניות לאימות הודעות כדי לאמת את המטען הייעודי (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 לתהליכי טרום-זרימה של נקודת הקצה של נקודת הקצה של שרת ה-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. בהתאם לנקודת הקצה שהגדרתם כיעד, יכול להיות שנשלח לך פרטים נוספים לגבי הבקשה. לדוגמה, אם משתמשים 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 בפורמט תקין

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

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

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

מוסיפים את המדיניות בנושא אימות הודעות SOAP לזרימה מראש של נקודת הקצה של נקודת הקצה של שרת ה-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 לאימות

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

מידע נוסף זמין במאמר הבא: מ-SOAP/1.1 ל-SOAP גרסה 1.2 ב-9 נקודות.

`<Source>`

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

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

ערך ברירת מחדל	בקשה
חובה?	אופציונלי
סוג	מחרוזת
רכיב הורה	`<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 סיבה תיקון

קוד שגיאה	סטטוס 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.

מדיניות SOAPMessageAuthentication

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

יתרונות

סרטונים

רכיב <MessageValidation>

תחביר

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

דוגמאות

1: אימות XSD

2: אימות SOAP

3: XML/JSON בפורמט תקין

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

<DisplayName>

תחביר

דוגמה

<Element>

תחביר

דוגמה 1

דוגמה 2

<ResourceURL>

תחביר

דוגמאות

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

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

<SOAPMessage>

תחביר

דוגמה

<Source>

תחביר

דוגמה

קודי שגיאה

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

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

סכימות

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

רכיב `<MessageValidation>`

`<DisplayName>`

`<Element>`

`<ResourceURL>`

`<SOAPMessage>`

`<Source>`