Index for the series:
Exchange ActiveSync Building Blocks – Intro
I have referred to WBXML a couple of times in this series, but so far not going into any detail other than generically describing it as "ActiveSync language". I’m not attempting to make this seem like "magic" or anything, but when I started hacking around with the Exchange ActiveSync protocol myself I felt that I had to get comfortable with the basic concepts before going into this.
If you recall when we made our first sync attempt with the FolderSync command in a POST I included the following variable as the content of the POST:
I have no idea why I thought it logical to define the bytes with their decimal value rather than the hexadecimal value (which I have used in later WBXMLs). Still; this is a rather short and sweet snippet of WBXML so we should be able to decode it manually by using a lookup table. I’ve converted the values to hex, and "translated" each byte to the plain xml representation.
So, while originally partially cryptic we see that it makes sense.
(As explained better than me by commenter "chkan" as to why we’re using 0x56 & 0x52 instead of 0x16 & 0x12 as per the code page would seem to be the correct values: "Bit 6 Indicates whether this tag begins an element containing content. If this bit is zero, the tag contains no content and no end tag. If this bit is one, the tag is followed by any content it contains and is terminated by an END token. Without bit 6 on (ie, sending 0×16 instead of 0×56) you’re telling Exchange that there’s no content in your element, which isn’t true, so it rejects the request." )
How about another example, this time doing an encode rather than a decode? I need to build something of equal length to the above, so I decided to encode an IRM "Get Policy" request. And IRM means exactly what? It stands for Information Restriction Management. I’ve covered it before (link in top paragraph), and there is a test included in EAS MD, but I understand that it might not be on top of everyone’s to-do list. That’s ok, I just wanted some WBXML that isn’t too hardcore.
I’ve used the same "padding trick" adding 0x40 to the values indicated in the code page. Note that this does not apply to selecting which code page you’re using or the closing tags.
It becomes fairly obvious fairly quickly that it is not feasible to sit around and do this manually as we do now unless you have a masochistic streak. I’ll just show one more example where we combine manual labor, yet inserting variables dynamically.
A requirement for provisioning in Exchange 2010 SP1, (if the client indicates supporting ActiveSync Protocol version 14.1), is that the server insists the client send some information back to the server about its properties; like operating system, IMEI, Mobile Operator, etc. (Screenshot from OWA shown in EAS MD 1.0 post linked to in the background reading section.)
I’ve stripped out parts of the code and replaced it with the placeholder “(…)” – otherwise it would have taken up a lot more lines of the space here, and you could have called it slightly repetitive. It was mind-numbing to write this code as well; I had the coding window on one monitor and the code page reference on the other. If your response to this is that I must be stupid or something for doing this manually you wouldn’t be entirely wrong. But I did this for a reason – yes, it’s boring, no you wouldn’t implement a full ActiveSync client this way, but doing it the hard way means you learn it. If you want to do the exercise yourself you can fill in the missing parts so that all device properties are included. (Unrolling the loops serves no grander purpose – I just didn’t want a lot of loops as my initial feeling was that if felt less readable that way.)
Either way – whether we are comfortable with building WBXML the hard way or not it is quite clear that the current approach does not scale. When you see all the code lines required just to send some simple info to the server you get the feeling this might get out of hand quickly. The proper thing to do would be to build a library handling all the WBXML stuff, or build some methods for encoding and decoding it. While WBXML is a generic concept not specific to Exchange ActiveSync, the AS part of AS-WBXML is more specific to this context. I have seen some dlls out there for the generic flavor, but have not seen exactly what I need specifically for ActiveSync communication. The “right” thing to do would as such be to build one myself, but I have not done so. It would take a lot of time, and so far I have not had the need for it either. (EAS MD has not required me to do so yet.) If I’ll build one later? Who knows?
No code for you!
I can’t come up with any good code samples for this article (other than the snippets already shown). I guess I could have wrapped the fetching of IRM policies into a small sample app, but unless you happen to be running Exchange 2010 SP1 it doesn’t apply, and even then you’d need to have the rest of the infrastructure ready as well. If you are in control of an Exchange that does have support for this you can test it with my EAS MD utility instead, or hack together something based on the byte array I described here, along with helpings of previous code snippets in this series.