Механизм соавторства в MS Office 2010 + SharePoint 2010: протоколы и пакеты
Введение
Механизм соавторства появился с выходом MS Office 2010 и SharePoint 2010. Появившуюся функциональность многие называют как "давно ожидаемую", действительно, приуменьшать удобство её использования смысла нет. Но в данной статье речь пойдет о том, как этот механизм функционирует и какую пользу из этого можно извлечь. Новое поле для деятельности в конце концов!
Что интересно пользователю
В первую очередь необходимо уделить внимание тому, как выглядит работа механизма соавторства. Исследуя просторы интернета, оказалось, что достаточно подробно это уже сделали, поэтому я не буду повторяться и предлагаю ознакомиться самим.
Что интересно разработчику
Мне было интересно разобраться в том, как соотносятся действия пользователя и формируемые при этом пакеты. Научиться определять действия по пересылаемым пакетам. Это позволило бы собирать информацию по работе пользователей (а в моем случае – сотрудников) на корпоративном портале, написав HTTP Module. Такая информация становится полезной, к примеру, для увеличивая количество конверсий или отслеживании интенсивности работ по подготовки документации. Причем практика показала, что эффективнее и безопаснее прослушивать входящие на сервер пакеты, а не исходящие.
Из-за кэширования документов, задача усложняется тем, что информация на уровне протокола MS-FSSHTTP неоднозначно определяет действия пользователя в некоторых случаях. Например, когда происходит событие открытия документа впервые - идет скачивание документа и по описанию пакета это легко определить, а когда документ открывается вторично, то происходит не скачивание документа, а сравнение его в кэше с документом на сервере при его открытии, хотя семантически эти два события означают начало работы с документом.
Механизм соавторства успешно работает в Word 2010, Excel 2010, OneNote 2010, SharePoint Workspace 2010 c SharePoint Foundation 2010 или SharePoint Server 2010. Это указанно в спецификациях.
Протоколы и пакеты
Все сообщение между сервером SharePoint и пользователем MS Office 2010 происходит по средству использования протоколов MS-FSSHTTP (File Synchronization via SOAP over HTTP Protocol Specification) и MS-FSSHTTPB (Binary Requests for File Synchronization via SOAP Protocol Specification).
Для большего удобства сразу приведу ссылки на описание протоколов:
При обмене пакетами протокол MS-FSSHTTP передает информацию о сущности, с которой начинается работа (её Url), авторе, который приступает к работе с сущностью, режиме работы (Read Only и Edit требуют разного уровня привилегий). MS-FSSHTTP-часть пакета представляет собой XML, что не добавляет этому протоколу какого-то изящества. Подразделы XML в пакете нумеруются параметром SubRequestToken. Становится возможна проверка целостности пакета при помощи параметра DependsOn. Сама же сущность в рамках протоколов MS-FSSHTTP и MS-FSSHTTPB называется cell.
Структура запроса MS-FSSHTTP укладывается в следующий шаблон:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<RequestVersion …> //Информация о версиях используемого протокола
<RequestCollection …> //Указывается CorrelationID,
guid используемый для логов на сервере и синхронизации пакетов.
<Request …> //Содержит URL документа
<SubRequest …/> //Определения пакета
</SubRequest>
…
</Request>
</RequestCollection>
</s:Body>
</s:Envelope>
Некоторые пояснения к структуре протокола MS-FSSHTTP:
<Request Url="http://serverName/documentFullPath" RequestToken="1"> - обязательная структура пакета протокола, указывающая документ к которому адресован запрос.
<SubRequest Type="Coauth" SubRequestToken="1"> - объявление режима соавторства, во вложенном теге указывается какой тип соавторства используется.
<SubRequest Type="SchemaLock" SubRequestToken="2" DependsOn="1" DependencyType="OnNotSupported"> - указывается наличие блокировки документа и её тип во вложенном теге. В ответ сервер указывает,начинаете ли вы работу с документом первым или присоединяетесь как соавтор.
<SubRequest Type="Cell" SubRequestToken="3"> - несет непосредственную информацию о документе. Содержит в себе MS-FSSHTTPB-часть пакета.
<SubRequest Type="WhoAmI" SubRequestToken="2"/> - информация о пользователе
Пример MS-FSSHTTP части пакета от пользователя к серверу (request)
Пакет сообщает о том, что идет обращение к документу 2MB.docx по указанному адресу и пользователь готов получить документ. BinaryDataSize указывает длину значения внутри тега, т.е. MS-FSSHTTPB –часть.
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<RequestVersion Version="2" MinorVersion="0"
xmlns="http://schemas.microsoft.com/sharepoint/soap/"/>
<RequestCollection CorrelationId="{010F340A-ACB5-442C-B11E-95CB877EEBA5}"
xmlns="http://schemas.microsoft.com/sharepoint/soap/">
<Request Url="http://moss14/Something/2MB.docx" RequestToken="1">
<SubRequest Type="Cell" SubRequestToken="1">
<SubRequestData PartitionID="383adc0b-e66e-4438-95e6-e39ef9720122" BinaryDataSize="88">
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</SubRequestData>
</SubRequest>
<SubRequest Type="WhoAmI" SubRequestToken="2"/>
<SubRequest Type="Cell" SubRequestToken="3">
<SubRequestData PartitionID="7808f4dd-2385-49d6-b7ce-37aca5e43602" BinaryDataSize="88">
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</SubRequestData>
</SubRequest>
<SubRequest Type="ServerTime" SubRequestToken="4"/>
<SubRequest Type="Cell" SubRequestToken="5">
<SubRequestData GetFileProps="true" BinaryDataSize="88">
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</SubRequestData>
</SubRequest>
</Request>
</RequestCollection>
</s:Body>
</s:Envelope>
Исследование пакетов
Изучая спецификации так и не нашелся ответ на то, как определять начало работы с документом. Поэтому необходимо выявленные при анализе пакетов признаки проверить на различных типах документов и различных размерах документов, устроить crash-test, иначе трудно назвать любой признак правдивым, а работу оправданной. Поэтому были проанализированы все традиционно используемые форматы при размерах документов до 30Мб.
Итоги анализа:
- Максимальный размер пакета не превышает 3Мб, то есть 30Мб файл передается за 10 пакетов.
- Только анализируя MS-FSSHTTP нельзя решить задачу определения открытия документа (из-за работы Upload Center с функцией кэширования), остальные действия определяются.
- Пакеты с MS-FSSHTTP-частью обращаются по ссылке http://moss14/_vti_bin/cellstorage.svc/CellStorageService, остальные не интересны в данной задаче. То есть это будет фильтром для анализа HTTP Request’а.
Пора знакомиться с протоколом MS-FSSHTTPB. Данные представленны в кодировке Base64, а для определения структуры необходимо переводить в HEX и бинарный код. Причем BinaryDataSize равная 88 - это «пустая» MS-FSSHTTPB-часть, чистый шаблон MS-FSSHTTPB запроса. В нем присутствуют все разделы MS-FSSHTTPB запроса, но в разделах нет никакой информации.
Если говорить о распределении ролей между двумя протоколами, то MS-FSSHTTP описывает информацию которая видна снаружи документа, т.е. все что мы сможем узнать не открывая файл, а MS-FSSHTTPB информирует о том, что происходит внутри документа, какие изменения сделаны, в каком месте документа. Таким образом, информация закодированная в MS-FSSHTTPB части пакета позволяет синхронизировать состояния документов у соавторов, передавая только измененные части документа, тем самым значительно снижая нагрузку на сеть. Правда другая реализация, с моей точки зрения, была бы и не логична.
Рассмотрим передаваемую по протоколу MS-FSSTHHB строку, где значение BinaryDataSize равно 88.
Исходное значение из XML тега протокола MS-FSSHTTP: DAALAJzPKfM5l
AabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCCACUKaEPdwEWAgYAAwUAigIC
AADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
Декодированный HEX-код (см. Спецификацию MS-FSSHTTPB стр. 71-73):
0c 00 0b 00 //Protocol Version + Minimum Version
9c cf 29 f3 39 94 06 9b //Signature
06 02 00 00 //CellRequest Start
ee 02 00 00 //User Agent Start
aa 02 20 00 //User Agent GUID
7e b8 31 e7 45 dd aa 44 ab 80 0c 75 fb d1 53 0e //GUID
7a 02 08 00 //User Agent Version
94 29 a1 0f //Version
77 01 16 02 06 00 //User Agent End + Sub-request Start
03 05 //Request DI + Request Type
00 8a 02 02 00 //Priority + Query Changes
00 da 02 06 00 //Allow Fragments/Reserved + Query Changes Request Argument
03 00 00 //Include Storage Manifest + Cell ID
ca 02 08 00 //Query Changes Data Constraints
08 00 80 03 //Maximum Data Element
84 00 //Knowledge Start
41 //Knowledge End
0b 01 ac 02 //Sub-Request End + Data Element Packege Start
00 55 03 01 //Reversed+ Daat Emlement Packege End + Cell Request End
Теперь в анализ, проведенный ранее добавляется новая итерация и анализ MS-FSSHTTPB. Лишая читателя удовольствия нудных примеров, привожу результаты анализа:
- Пустой пакет является сигналом о готовности получать документ, а значит помогает определять событие открытия документа с сервера. Ключевой строчкой для фильтрующего request модуля становится:
SubRequestData GetFileProps="true" BinaryDataSize="88">
однако если документ был закеширован в Upload Center, то BinaryDataSize больше 88, т.е. будет не пустым шаблоном, потому что необходимо проверить документ на валидность. Для определения такого случая был найден другой признак.
- Пакет проверяющий кэшированный документ в Upload Center также содержит строку, указанную в п.1 данного списка. Однако значение параметра BinaryDataSize тем больше, чем больше сверяемый документ из Upload Center. Для наглядности приведу пример разбора такого пакета.
<SubRequestData GetFileProps="true" BinaryDataSize="443">DAALAJz
PKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCCACUKaEPdwEWAgYAAwUAigI
CAADaAgYAAwAAygIIAAgAgAOEACYCIAD2NXoyYQcURJaGUekAZnpNpAB4KCn1koJCYUFHqgO
vQEOf2v3CNZY9eCgp9ZKCQmFBR6oDr0BDn9r9rj3iPngoKfWSgkJhQUeqA69AQ5/a/fo+JkB
4KCn1koJCYUFHqgOvQEOf2v0+QGpBeCgp9ZKCQmFBR6oDr0BDn9r9gkGeQngmRlDki07gDrG
jv1Ojie167QDOAngmua8bdLEf8U6jv1Ojie167QBmD1ETASYCIAATHwkQgsj7QJiGZTP5NMI
dbAFw0Qz5C0E3b9GZRKbDJyMu3KcRrXsAOAAyADkAMgBGADUAMgA5AC0ANgAxADQAMgAtADQ
ANwA0ADEALQBBAEEAMAAzAC0AQQBGADQAMAA0ADMAOQBGAEQAQQBGAEQAfQAsADMALAAzAAA
AtRMBJgIgAA7pdjoygAxNud3zxlApQz5MASAoDLmvG3SxH/FOo79To4nteu1mDwClEwFBCwG
sAgBVAwE=</SubRequestData>
Декодированный HEX-код:
0c 00 0b 00 //Protocol Version + Minimum Version
9c cf 29 f3 39 94 06 9b //Signature
06 02 00 00 //CellRequest Start
ee 02 00 00 //User Agent Start
aa 02 20 00 //User Agent GUID
7e b8 31 e7 45 dd aa 44 ab 80 0c 75 fb d1 53 0e //GUID
7a 02 08 00 //User Agent Version
94 29 a1 0f //Version
77 01 16 02 06 00 //User Agent End + Sub-request Start
03 05 //Request DI + Request Type
00 8a 02 02 00 //Prioority + Query Changes
00 da 02 06 00 //Allow Fragments/Reserved + Query Changes Request Argument
03 00 00 //Include Storage Manifest + Cell ID
ca 02 08 00 //Query Changes Data Constraints
08 00 80 03 //Maximum Data Element
84 00 //Knowledge Start
\\ Обратите внимание, что до этого момента пакет полностью описывалась выше
26 02 20 00 //cell knowledge range
f6 35 7a 32 61 07 14 44 96 86 51 e9 00 66 7a 4d //GUID in cell knowlegde range
a4 00 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
c2 35 96 3d 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
ae 3d e2 3e 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
fa 3e 26 40 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
3e 40 6a 41 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
82 41 9e 42 78 26 46 50 e4 8b 4e e0 0e b1 a3 bf 53 a3 89 ed 7a ed 00
ce 02 78 26 //Pre DATA
b9 af 1b 74 b1 1f f1 4e a3 bf 53 a3 89 ed 7a ed //GUID before FROM number
00 66 0f //FROM number
51 13 01 26 02 20 00 13 1f 09 10 82 c8 fb 40 98 86 65 33 f9 34 c2 1d 6c
01 70 d1 0c f9 0b 41 37 6f d1 99 44 a6 c3 27 23 2e dc a7 11 ad
7b 00 38 00 32 00 39 00 32 00 46 00 35 00 32 00 39 00 2d 00 36 00 31
00 34 00 32 00 2d 00 34 00 37 00 34 00 31 00 2d 00 41 00 41 00 30 00
33 00 2d 00 41 00 46 00 34 00 30 00 34 00 33 00 39 00 46 00 44 00 41
00 46 00 44 00 7d 00 2c 00 33 00 2c 00 33 00 00 00
b5 13 01 26 02 20 00 0e e9 76 3a 32 80 0c 4d b9 dd f3 c6 50 29 43 3e
4c 01 20 28 0c //DATA changeset
b9 af 1b 74 b1 1f f1 4e a3 bf 53 a3 89 ed 7a ed //GUID before TO number
66 0f 00 //To number
a5 //Cell range End
13 01 //Cell End
// далее пакет соответствует шаблону пустого запроса
41 //Knowledge End
0b 01 ac 02 //Sub-Request End + Data Element Packege Start
00 55 03 //Reversed+ Data Emlement Packege End + Cell Request End
Подробнее разобрать содержание cell knowledge range (см спецификацию MS-FSSHTTPB стр. 37) не так просто. Я выделил в составе кода, передаваемого до variable FROM повторяющуюся связку Data + GUID, но она не обязательно присутствует в пакете при небольших размерах проверяемого файла, поэтому такую конструкцию за признак считать нельзя. Что касается семантики такой конструкции, то похожая конструкция описывается в пакетах response. Можно попытаться объяснить почему в request пакете используются конструкции из response, но почему описания этих конструкций нет в спецификации request запроса объяснить трудно. Теперь обратим внимание на данные, заключенные между variable FROM и variable TO. Именно тут находится краеугольный камень, а именно между словом «7b 00» и «b5 13» содержимое укладывается в регулярное выражение “\w{2}[ 00]”, но не стоит забывать что пробелы поставлены только для повышения читабельности. Этот признак подтвердил себя на всех тестах с документами. Ура товарищи!
Но можно не останавливаться и попробовать проникнуть в семантику такой конструкции. Опытный разработчик может заметить, что в таком виде представляются данные с кодировкой UTF-16 (hex). Преобразовав строку
7b 00 38 00 32 00 39 00 32 00 46 00 35 00 32 00 39 00 2d 00 36 00 31
00 34 00 32 00 2d 00 34 00 37 00 34 00 31 00 2d 00 41 00 41 00 30 00 33
00 2d 00 41 00 46 00 34 00 30 00 34 00 33 00 39 00 46 00 44 00 41 00 46
00 44 00 7d 00 2c 00 33 00 2c 00 33 00 00 00
в UTF-16 (hex) получаем
{8292f529-6142-4741-aa03-af40439fdafd},3,3
В результате обнаруживается, что в исследуемой конструкции передаются параметры: GUID и два численных параметра, что делает конструкцию осмысленной и даже дает возможность разработчику попытаться понять её семантику. Можно предположить, что GUID используется для проверки закэшированного документа на валидность. Такая версия пока выдержала всю возможную критику и кажется весьма удачной!
Заключение
В этой статье я постарался осветить механизм соавторства в MS Office 2010 + SharePoint 2010 на уровне работы протоколов. Надеюсь у меня получилось доходчиво объяснить некоторые особенности, которые не освещены в спецификациях протоколов и которым ранее не уделялось внимания. Нужно отметить, что с момента конца моего личного расследования в работе протоколов MS-FSSHTTP и MS-FSSHTTPB документация на MSDN существенно дополнилась.
В целом работа соавторства очень напоминает базовые принципы работы по редактированию документов в Unix-системах. Различия не столь существенные, чтобы назвать механизм соавторства инновационным. Этой мыслью и хотелось бы закончить статью.
Желаю вам интересных исследований!
Виталий Князев
Программист SharePoint
MAPLlab Ltd.
Оригинал статьи: Механизм соавторства в MS Office 2010 + SharePoint 2010: протоколы и пакеты | 
Модуль поддержки
Microsoft Outlook