The request failed schema validation… But why?

If you’re particularly proud of your (XML) writing skills or happen to be one of the adventurous sorts who likes to speak to Exchange Web Services using your own SOAP requests, you might encounter a situation or two in which you stumble upon the error when (as always) you’re least expecting it…

The request failed schema validation: The element <CalendarItem/Contact/…> in namespace 'https://schemas.microsoft.com/exchange/services/2006/types' has invalid child element 'ReminderMinutesBeforeStart/ExtendedProperty/…' in namespace 'https://schemas.microsoft.com/exchange/services/2006/types'. List of possible elements expected: <List of elements related to your ItemType> in namespace  'https://schemas.microsoft.com/exchange/services/2006/types'.

*Text in this colour may vary from one situation to another

Let’s say this was the request that you had sent:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:CreateItem MessageDisposition="SendOnly">
      <m:Items>
        <t:Message>
          <t:ToRecipients>
            <t:Mailbox>
              <t:EmailAddress>user1@org1.com</t:EmailAddress>
            </t:Mailbox>
            <t:Mailbox>
              <t:EmailAddress>user2@org2.com</t:EmailAddress>
            </t:Mailbox>
          </t:ToRecipients>
          <t:Subject>Subject of Email</t:Subject>
          <t:Body BodyType="HTML">This is the Body</t:Body>
        </t:Message>
      </m:Items>
    </m:CreateItem>
  </soap:Body>
</soap:Envelope>

and the response you received wasn’t quite the CreateItemResponse with the blissful “NoError” Response Code but instead a  “The request failed schema validation”…

If you were to attempt performing the same action but leveraging an API such as the Exchange Web Services Managed API, you’d find a very similar looking call generated.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:m="https://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:CreateItem MessageDisposition="SendOnly">
      <m:Items>
        <t:Message>
          <t:Subject>Subject of Email</t:Subject>
          <t:Body BodyType="HTML">This is the Body</t:Body>
          <t:ToRecipients>
            <t:Mailbox>
              <t:EmailAddress>user1@org1.com</t:EmailAddress>
            </t:Mailbox>
            <t:Mailbox>
              <t:EmailAddress>user2@org2.com</t:EmailAddress>
            </t:Mailbox>
          </t:ToRecipients>
        </t:Message>
      </m:Items>
    </m:CreateItem>
  </soap:Body>
</soap:Envelope>

So what’s different, really? The answer is hidden in the subtlety of the ordering of the elements in your call. Specifically, whereas in the manually authored XML request, we specified our elements of choice in the sequence ToRecipients, Subject and Body, EWS Managed API decided to re-order it to Subject, Body and ToRecipients.

So who/what is it that decides which ordering is correct and which isn’t? What happens if we decide to include other elements, such as CCRecipients, BCCRecipients, Attachments? Where do we fit them in?

The answer to the above question lies in… Documentation!

Glance through the XML syntax for an Exchange e-mail message, and you’ll find that the XML elements in XML Request 2 corresponds more closely to the ones in XML Request 1. Moreover, if you sift through the XML Response of a successful call that returns some items, you’ll find them in the exact ordering as in the documentation.

You can find the orderings for Contact, Calendar Items, Task and many more in the MSDN documentation.

So should you come across this error message, fret not. The solution is as simple as 1 – 2 – 3 (instead of 1 – 3 – 2 or 2 – 1 – 3 or… well, you get the idea…)

Cheers!