МЕХАНИЗМ СИНХРОНИЗАЦИИ КОМПЛЕКТА ПРИЛОЖЕНИЙ ДЛЯ ПРОДУКТИВНОЙ РАБОТЫ И БИЗНЕС-ПРИЛОЖЕНИЙ Российский патент 2011 года по МПК G06F15/16 

Уровень техники

Предусмотрен ряд комплектов программных приложений, доступных пользователям, которые включают в себя приложения для создания календаря событий, сохранения информации контактов, поддержки электронной почты, сохранения информации задач и т.д. Один пример - это Microsoft Outlook®, предлагаемый Microsoft Corporation, Редмонд, Вашингтон. Microsoft Outlook® - это часть комплекта программных приложений Microsoft Office®. Многие пользователи знакомы с такими приложениями комплектов программных приложений и используют их на регулярной основе.

Некоторые пользователи комплектов программных приложений для продуктивной работы также используют коммерческие прикладные программы или системы, разработанные для конкретных вариантов бизнес-применения (также упоминаемых в данном документе как бизнес-системы или LOB-системы). Один пример - это системы управления взаимоотношениями с клиентами (CRM), предлагаемые рядом компаний. Большая часть информации, которая управляется посредством LOB-систем, может включать в себя управление контактами, создание календаря событий и задач, помимо прочего.

Во многих случаях комплект программных приложений для продуктивной работы не может обмениваться или синхронизировать свою информацию с LOB-системой автоматически. Например, если пользователь добавляет бизнес-задачу в комплект программных приложений для продуктивной работы пользователя, информация задачи не переносится автоматически в LOB-систему. Вместо этого эта информация обнаруживается пользователем в каждой различной системе. В типичном варианте пользователи должны вводить информацию задачи второй раз в LOB-систему. Некоторые пользователи могут захотеть предоставить возможность сохранения LOB-информации в системах электронной почты и синхронизации с LOB-информацией в системах баз данных.

Сущность изобретения

В соответствии с различными аспектами раскрытых вариантов осуществления способ синхронизации выполнен с возможностью разрешать синхронизацию между клиентской машиной, которая включает в себя приложение комплекта программных приложений для продуктивной работы, и серверной машиной, которая включает в себя бизнес-приложение (LOB). Приложением комплекта программных приложений для продуктивной работы может быть приложение персональной информационной системы (PIM), такое как Outlook® (предлагается Microsoft Corporation, Редмонд, Вашингтон), или какое-либо другое приложение, такое как Lotus Notes, Star Office и т.д. Примеры приложений комплекта программных приложений для продуктивной работы включают в себя управление электронной почтой, управление назначенными встречами, управление составлением плана/календаря, управление заметками, управление задачами, управление контактами и т.п. Синхронизация может обрабатываться между элементами данных в приложении комплекта программных приложений для продуктивной работы и объектами в LOB-приложении посредством использования представлений XML-данных и сохраненной информации связывания.

В одной конкретной реализации информация, которая используется для синхронизации, сохраняется в виде XML-данных. Представление XML-данных может быть сохранено в качестве свойства элемента данных в приложении комплекта программных приложений для продуктивной работы. Представление XML-данных может быть передано в LOB-приложение, которое затем может оперировать собственным разрешением конфликтов и хранением данных для LOB-объектов. Изменение в объекты LOB-приложения затем может предоставляться как XML, который затем может быть форматирован в управляющее сообщение, которое передается в приложение комплекта программных приложений для продуктивной работы. Представления XML-данных предоставляют единообразный интерфейс, который просто управляется посредством каждого соответствующего приложения.

В другом аспекте выполняется шифрование информации на основе пользователя. Этот аспект преимущественно может помогать обеспечивать то, что информация, содержащаяся в любом PIM-элементе, которая отправляется получателю электронной почты, не может быть считана этим получателем и, тем самым, не может быть непреднамеренно совместно использована. В связанном аспекте шифрование помогает предотвращать вызывание неожиданного режима работы информацией на стороне получателя. Например, в некоторых традиционных системах информация, содержащаяся в назначениях встреч, легко может быть совместно использована посредством отправки приглашения на встречу. Таким образом, пользователь может совместно использовать информацию, даже не зная об этом. Шифрование информации предотвращает такое проявление непреднамеренного совместного использования информации. Тем не менее, в случае если пользователь имеет несколько устройств, описанное шифрование не предотвращает совместное использование информации на нескольких устройствах пользователя.

В другом аспекте информация сохраняется в персональном свойстве, уменьшая возможность перезаписи. В некоторых традиционных системах информация может неявно обмениваться с приглашенной стороной в запросе на встречу без ведома запрашивающей стороны. Когда запрашивающая и приглашенная сторона совместно используют информацию посредством отправки информации явно или неявно, есть вероятность того, что информация будет сохранена в одном свойстве. Поскольку поддерживается последняя сохраненная информация, информация от одного из пользователей может быть перезаписана. В одном аспекте настоящей заявки конкретное имя свойства назначается для того, чтобы сохранять дополнительную информацию с тем, чтобы не допускались конфликты.

В другом аспекте информация может быть перемещена на более высокий уровень и на более низкий уровень, так что элементы или атрибуты информации (т.е. которые находятся в XML) не могли быть реплицированы (дублированы) в свойства в содержащихся PIM-элементах. Например, в одной реализации стандартный UI Microsoft Outlook® может быть использован для того, чтобы отображать или обрабатывать эти значения и/или значения, которые могут быть совместно использованы с другими пользователями. В одном аспекте настоящей заявки представление XML-данных предоставляется в LOB-приложение с тем, чтобы LOB-элементы могли изменяться только посредством LOB-приложения. В другом аспекте LOB-элемент форматируется в виде XML-данных, которое затем используется для синхронизации с элементами приложений комплекта программных приложений для продуктивной работы. Поскольку XML может быть использован в качестве механизма переноса информации, могут быть реализованы упрощенные пользовательские интерфейсы для приложения комплекта программных приложений для продуктивной работы.

В другом аспекте диалоги взаимно синхронизируются между комплектом программных приложений для продуктивной работы и LOB-приложением. Диалоги могут разрабатываться на любом соответствующем языке, таком как, например, расширяемый язык разметки приложений (XAML). Синхронизация между диалогами преимущественно предоставляет возможность нескольким диалогам, показывающим один и тот же элемент, быть открытыми одновременно. Когда пользователь вводит информацию в один диалог, информация автоматически изменяется во всех остальных местах, где она показывается. Например, в реализации Microsoft Outlook®, когда одна информация показывается в диалоге Microsoft Outlook® (Inspector) и на панели задач или панели действий, она должна быть синхронизирована. Этот аспект предоставляет механизмы, которые позволяют нескольким диалогам в Microsoft Outlook® совместно использовать один экземпляр данных (будучи в процессе редактирования).

В еще одном другом аспекте приложение комплекта программных приложений для продуктивной работы в клиентской машине сконфигурировано так, чтобы отправлять запросы посредством обращения к веб-серверу, чтобы обновлять, удалять или создавать новый объект в LOB-приложении. LOB-приложение извлекает запрос из клиентской машины, при этом запрос может быть предоставлен в виде XML-данных. Серверная машина отправляет запросы посредством управляющих сообщений, которые вложены в электронную почту, чтобы обновлять, удалять или создавать элемент в приложении комплекта программных приложений для продуктивной работы, при этом элемент ассоциативно связан с LOB-объектом. Управляющие сообщения скрыты от пользователя и извлекаются клиентской машиной для оценки, разрешения конфликтов, продвижения на более высокий уровень свойств и привязки между LOB-объектом и элементом приложения комплекта программных приложений для продуктивной работы.

В дополнительном аспекте приложение может передавать LOB-идентификатор в почтовом сообщении, при этом LOB-идентификатор ассоциативно связан с предшествующей привязкой между элементом комплекта программных приложений для продуктивной работы и LOB-объектом. LOB-идентификатор может быть вложенным в почтовое сообщение в заголовке, ассоциативно связанном с почтовым сообщением. Почтовое сообщение необязательно должно содержать (вложенным или иным образом) сам LOB-объект, поскольку LOB-идентификатор ссылается на LOB-объект. После того как почтовое сообщение принято, дескриптор электронной почты для комплекта программных приложений для продуктивной работы может идентифицировать конкретный элемент комплекта программных приложений для продуктивной работы в тени синхронизации или хранилище данных синхронизации, который обращается к LOB-идентификатору. В одном примере пользователь может осуществлять доступ к элементу комплекта программных приложений для продуктивной работы посредством выбора ссылки (к примеру, URL-ссылки в любом числе форм, например, HTTP, HTTPS, FTP, FTPS, OBA и т.д.) и другой внедренной информации (к примеру, представления XML-данных или другого представления данных), которая ассоциативно связана с LOB-идентификатором в почтовом сообщении. В другом примере панель действий или панель задач может быть активирована для доступа к конкретному элементу комплекта программных приложений для продуктивной работы. Поскольку LOB-идентификатор может быть вложен в ссылку, любое требуемое действие, ассоциативно связанное с элементом комплекта программных приложений для продуктивной работы, может быть осуществлено посредством конфигурирования дескриптора (к примеру, URL-дескриптора) соответствующим образом.

Краткое описание чертежей

Неограничивающие и неисчерпывающие варианты осуществления описаны со ссылками на следующие чертежи, на которых одинаковые цифры ссылок ссылаются на одинаковые элементы в различных представлениях, если не указано иное.

Фиг.1 - это блок-схема, представляющая общее вычислительное окружение, которое может быть использовано для того, чтобы реализовать методики, описанные в данном документе, согласно варианту осуществления.

Фиг.2 иллюстрирует пример системы, в которой клиентское устройство выполнено с возможностью синхронизации с LOB-системой.

Фиг.3 иллюстрирует то, как устанавливается корреляция между привязываемым элементом и LOB-объектом, когда новый связываемый элемент создается посредством LOB-системы.

Фиг.4 иллюстрирует то, как устанавливается корреляция между привязываемым элементом и LOB-объектом, когда новый связываемый элемент создается посредством комплекта программных приложений для продуктивной работы.

Фиг.5 иллюстрирует то, как изменяется корреляция между привязываемым элементом и LOB-объектом, когда связываемый элемент обновляется или удаляется в комплекте программных приложений для продуктивной работы.

Фиг.6 иллюстрирует то, как изменяется корреляция между привязываемым элементом и LOB-объектом, когда связываемый элемент обновляется или удаляется посредством LOB-системы.

Фиг.7 иллюстрирует примерный поток информации между клиентом и сервером в ходе операции помещения в стек.

Фиг.8 и 9 иллюстрируют операцию извлечения, которая может быть использована в другой примерной системе.

Фиг.10 иллюстрирует примерную структуру подсистемы синхронизации для комплекта программных приложений, который используется на клиентской машине.

Фиг.11 иллюстрирует еще один поток информации между клиентом и сервером.

Фиг.12 иллюстрирует примерную подсистему синхронизации.

Фиг.13 - это блок-схема последовательности операций примерного способа синхронизации.

Подробное описание изобретения

Различные варианты осуществления подробнее описываются ниже со ссылкой на прилагаемые чертежи, которые составляют их часть и которые иллюстрируют конкретные примерные варианты осуществления для использования на практике различных вариантов осуществления. Тем не менее, другие варианты осуществления могут быть реализованы во многих различных формах и не должны рассматриваться как ограничивающие вариантами осуществления, изложенными в данном документе; наоборот, эти варианты осуществления предоставляются с тем, чтобы данная сущность была всесторонней и полной. Варианты осуществления могут быть использованы на практике как способы, системы или устройства. Соответственно, варианты осуществления могут принимать форму аппаратной реализации, полностью программной реализации или реализации, комбинирующей программные и аппаратные аспекты. Нижеследующее подробное описание, следовательно, не должно рассматриваться в ограничивающем смысле.

Вкратце, способ синхронизации выполнен с возможностью предоставлять синхронизацию между клиентской машиной, которая включает в себя приложение комплекта программных приложений для продуктивной работы, и серверной машиной, которая включает в себя бизнес-приложение (LOB), такое как приложение управления взаимоотношениями с клиентами, или CRM. Клиентская машина отправляет запросы посредством обращения к веб-серверу для того, чтобы обновлять, удалять или создавать новый объект в LOB-приложении. LOB-приложение извлекает запрос, который принимается от клиентской машины, при этом запрос может быть предоставлен в виде XML-данных. Серверная машина отправляет запросы посредством управляющих сообщений, которые внедрены в электронную почту, чтобы обновлять, удалять или создавать элемент в приложении комплекта программных приложений для продуктивной работы, при этом этот элемент ассоциативно связан с LOB-объектом. Управляющие сообщения скрыты от пользователя и извлекаются клиентской машиной для оценки, разрешения конфликтов, продвижения на более высокий уровень свойств и привязки между LOB-объектом и элементом приложения комплекта программных приложений для продуктивной работы.

Логические операции различных вариантов осуществления реализуются (1) как последовательность машинореализованных этапов, выполняющихся в вычислительной системе, и/или (2) как взаимосвязанные машинные модули в рамках вычислительной системы. Реализация является предметом выбора в зависимости от требований к производительности вычислительной системы, реализующей вариант осуществления. Следовательно, логические операции, составляющие варианты осуществления, описанные в данном документе, упоминаются как альтернативно как операции, этапы или модули.

Различные модули, технологии и способы могут быть описаны в данном документе в общем контексте машиноисполняемых инструкций, таких как программные модули, исполняемые одним или более компьютерами или другими устройствами. Как правило, программные модули включают в себя процедуры, программы, объекты, компоненты, структуры данных и т.д. для выполнения конкретных задач или реализации конкретных абстрактных типов данных. В типичном варианте функциональность программных модулей может быть скомбинирована или распределена, как требуется в различных вариантах осуществления.

Осуществление таких модулей и технологий может быть сохранено или передано в некоторой форме машиночитаемого носителя. Машиночитаемый носитель может быть любым доступным носителем, к которому может быть получен доступ посредством компьютера. В качестве примера, но не ограничения, машиночитаемые носители могут содержать "компьютерные носители хранения" и "среду передачи данных".

"Компьютерный носитель" хранения включает в себя энергозависимый и энергонезависимый, съемный и несъемный носитель, реализованный любым способом или технологией для хранения информации, такой как машиночитаемые инструкции, структуры данных, программные модули или другие данные. Компьютерные носители хранения данных включают в себя, но не ограничены этим, RAM, ROM, EEPROM, флэш-память или память по другой технологии, CD-ROM, цифровые многофункциональные диски (DVD) или другие оптические носители, магнитные кассеты, магнитную ленту, магнитный носитель на диске или другие магнитные устройства хранения, либо любой другой носитель, который можно использовать для хранения желаемой информации и к которому можно обращаться с помощью компьютера.

"Среда передачи данных" в типичном варианте воплощает машиночитаемые инструкции, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как сигнал несущей или другой механизм передачи. Среда передачи также включает в себя любую среду доставки информации. Термин "модулированный информационный сигнал" означает сигнал, который обладает одной или несколькими характеристиками, заданными или измененными так, чтобы кодировать информацию в сигнале. В качестве неограничивающего примера среда передачи данных включают в себя проводную среду, такую как проводная сеть или непосредственное проводное соединение, и беспроводную среду, такую как акустическая, РЧ (радиочастотная, RF), инфракрасная и другая беспроводная среда. Сочетания любого из вышеперечисленного также следует включить в число машиночитаемого носителя.

В данном подробном описании содержится ссылка на "один вариант осуществления", "вариант осуществления" или "примерный вариант осуществления", что означает то, что конкретный описанный признак, структура или характеристика включена, по меньшей мере, в один вариант осуществления. Таким образом, использование таких фраз может относиться более чем только к одному варианту осуществления. Помимо этого описанные признаки, структуры или характеристики могут быть комбинированы любым надлежащим образом в одном или более вариантов осуществления.

Тем не менее, специалисты в данной области техники могут признавать, что варианты осуществления могут быть использованы на практике без одной или более конкретных подробностей или с другими способами, ресурсами, материалами и т.д. В других случаях широко распространенные структуры, ресурсы или операции не показаны или описаны подробно просто для того, чтобы избежать затруднений в понимании аспектов вариантов осуществления.

Примерное вычислительное окружение

Фиг.1 иллюстрирует общее вычислительное окружение 100, которое может быть использовано для осуществления методик, описанных в данном документе. Вычислительное окружение 100 является только одним примером вычислительного окружения и не имеет намерением наводить на мысль о каком бы то ни было ограничении в отношении объема использования или функциональности вычислительной и сетевой архитектур. Вычислительное окружение 100 не должно быть интерпретировано в качестве имеющего какую бы то ни было зависимость или требование, относящееся к любому одному или сочетанию из компонентов, проиллюстрированных в примерном вычислительном окружении 100.

Вычислительное окружение 100 включает в себя вычислительное устройство общего назначения в виде компьютера 102. Компоненты компьютера 102 могут включать в себя, но не ограничиваться этим, один или более процессоров или устройств 104 обработки, системную память 106 и системную шину 108, которая связывает различные компоненты системы, включающие в себя процессор 104, с системной памятью 106.

Системная шина 108 представляет один или более из каких-либо нескольких типов структур шин, включающих в себя шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессорную или локальную шину, использующую любую из множества шинных архитектур. В качестве примера такая архитектура может включать в себя шину архитектуры промышленного стандарта (ISA), шину микроканальной архитектуры (MCA), шину расширенной архитектуры ISA (EISA), локальную шину ассоциации по стандартизации в области видеотехники (VESA), шину межсоединения периферийных компонентов (PCI), также известную как "мезонинная шина", шину PCI Express, универсальную последовательную шину (USB), шину Secure Digital (SD) или шины IEEE 1394, т.е. FireWire.

Компьютер 102 может включать в себя многообразие машиночитаемых носителей. Такие носители могут быть любыми доступными носителями, которые доступны посредством компьютера 102 и включают в себя и энергозависимые и энергонезависимые носители, съемные и несъемные носители.

Системная память 106 может включать в себя машиночитаемые носители в форме энергозависимой памяти, например, оперативное запоминающее устройство (RAM); и/или энергонезависимой памяти, например, постоянное запоминающее устройство (ROM) или флеш-RAM. Базовая система 114 ввода/вывода (BIOS), содержащая базовые процедуры, которые помогают передавать информацию между элементами в пределах компьютера 102, к примеру, во время запуска, типично сохранена в ПЗУ 112 или флэш-RAM. RAM 110 типично содержит модули данных и/или программ, которые доступны непосредственно и/или, собственно, являются приводимыми в действие процессором 104.

Компьютер 102 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители хранения. В качестве примера фиг.1 иллюстрирует накопитель 116 на жестких дисках для считывания и записи на стационарный энергозависимый магнитный носитель (не показан), накопитель 118 на магнитных дисках для считывания или записи на съемный энергонезависимый магнитный диск 120 (к примеру, гибкий диск) и накопитель 122 на оптических дисках для считывания и/записи на съемный энергонезависимый оптический диск 124, такой как CD-ROM, DVD-ROM или другой оптический носитель. Привод 116 жестких дисков, привод 118 магнитных дисков и привод 122 оптических дисков каждый соединены с системной шиной 108 одним или более интерфейсами 125 носителей данных. Альтернативно, привод 116 жестких дисков, привод 118 магнитных дисков и привод 122 оптических дисков могут быть соединены с системной шиной 108 одним или более другими интерфейсами (не показаны).

Накопители на дисках и их ассоциативно связанные машиночитаемые носители предоставляют энергонезависимое хранение читаемых компьютером команд, структур данных, программных модулей и других данных для компьютера 102. Хотя пример иллюстрирует жесткий диск 116, съемный магнитный диск 120 и съемный оптический диск 124, следует понимать, что другие типы машиночитаемых носителей, которые могут хранить данные, которые доступны посредством компьютера, например, магнитные кассеты или другие магнитные устройства хранения, карты флэш-памяти, CD-ROM, цифровые многофункциональные диски (DVD) или другой оптический накопитель, оперативные запоминающие устройства (RAM), постоянные запоминающие устройства (ROM), электрически стираемое программируемое постоянное запоминающее устройство (EEPROM) и подобные могут также использоваться, чтобы осуществить примерную вычислительную систему и окружение.

Любое число программных модулей может быть сохранено на жестком диске 116, магнитном диске 120, оптическом диске 124, ROM 112 и/или RAM 110, включая в себя в качестве примера операционную систему 126, одну или более прикладных программ 128, другие программные модули 130 и программные данные 132. Каждое из такой операционной системы 126, одной или более прикладных программ 128, других программных модулей 130 и программных данных 132 (или некоторая их комбинация) может осуществлять все или часть резидентных компонентов, которые поддерживают распределенную файловую систему.

Пользователь может ввести команды и информацию в компьютер 102 через устройства ввода, такие как клавиатура 134 и указательные устройства 136 (к примеру, "мышь"). Другие устройства 138 ввода (не показаны конкретно) могут включать в себя микрофон, джойстик, игровую панель, спутниковую антенну, последовательный порт, сканер и/или подобное. Эти и другие устройства ввода присоединены к устройству 104 обработки через интерфейсы 140 ввода/вывода, которые присоединены к системной шине 108, но могут быть присоединены другим интерфейсом и шинными структурами, такими как параллельный порт, игровой порт или универсальная последовательная шина (USB).

Монитор 142 или другой тип устройства отображения может также быть присоединен к системной шине 108 через интерфейс, такой как видеоадаптер 144. В дополнение к монитору 142 другие периферийные устройства вывода могут включать в себя компоненты, такие как динамики (не показаны) и принтер 146, которые могут быть присоединены к компьютеру 102 через интерфейсы 140 ввода/вывода.

Компьютер 102 может работать в сетевом окружении с помощью логических соединений с одним или более удаленными компьютерами, такими как удаленное вычислительное устройство 148. В качестве примера удаленное вычислительное устройство 148 может быть персональным компьютером, переносным компьютером, сервером, маршрутизатором, сетевым компьютером, равноправным устройством или другим общим узлом сети и т.п. Удаленное вычислительное устройство 148 иллюстрировано как переносной компьютер, который может включать в себя многие или все из элементов и признаков, описанных в данном документе, соответствующих компьютеру 102. Альтернативно, компьютер 102 может функционировать в не объединенном в сеть окружении.

Логические соединения между компьютером 102 и удаленным компьютером 148 изображены как локальная вычислительная сеть (LAN) 150 и общая глобальная вычислительная сеть (WAN) 152. Такие сетевые окружения являются общепринятыми в офисах, корпоративных вычислительных сетях, интранет и Интернет.

Когда используется в сетевом окружении LAN, компьютер 102 подключен к локальное сети 150 через сетевой интерфейс или адаптер 154. Когда используется в сетевом окружении WAN, компьютер 102 типично включает в себя модем 156 или другое средство для установления связи по глобальной сети 152. Модем 156, который может быть внутренним или внешним по отношению к компьютеру 102, может быть присоединен к системной шине 108 через интерфейсы ввода/вывода или другие подходящие механизмы. Должно быть оценено, что иллюстрированные сетевые соединения являются примерными, и что могут быть применены другие средства установления, по меньшей мере, одной линии связи между компьютерами 102 и 148.

В сетевом окружении, таком как иллюстрированное с вычислительным окружением 100, программные модули, изображенные по отношению к компьютеру 102, или их части могут храниться на удаленном устройстве хранения данных. В качестве примера удаленные прикладные программы 158 находятся в запоминающем устройстве удаленного компьютера 148. В целях иллюстрации прикладные программы и другие выполняемые программные компоненты, такие как операционная система, иллюстрированы в данном документе как отдельные блоки, хотя признано, что такие программы и компоненты находятся в различные моменты времени в разных компонентах хранения вычислительного устройства 102 и выполняются, по меньшей мере, одним процессором данных компьютера.

Далее приводится описание примерных интерфейсов и конфигурации, реализованной в Microsoft Outlook® для того, чтобы поддерживать синхронизацию информации Microsoft Outlook® с LOB-системой. В других вариантах осуществления другие приложения комплекта программных приложений для продуктивной работы могут быть использованы вместо или помимо Microsoft Outlook®.

Примерная конфигурация

Фиг.2 иллюстрирует пример системы, в которой клиентское устройство выполнено с возможностью синхронизации с LOB-системой. Как показано на чертеже, комплект программных приложений для продуктивной работы (220), такой как Microsoft Outlook®, доступен на клиентском устройстве. Microsoft Outlook® содержит один или более элементов, такие как: календарные назначения встреч, контакты, электронная почта и т.д. Каждый элемент (230) комплекта программных приложений для продуктивной работы включает в себя набор стандартных свойств (231), которые относятся к комплекту программных приложений для продуктивной работы, и один или более элементов данных (LOB-данные 232), которые связаны с LOB-системой. Дополнительные свойства системы также ассоциативно связаны с элементом, как, например, может быть необходимо для связывания данных и свойств с элементом (к примеру, привязывания информации в системном свойстве 233). Вне элемента (240) имеется набор системных свойств, которые связаны с синхронизацией (242), а также хранилище данных, которое используется для того, чтобы кэшировать данные (241) синхронизации.

Один пользователь должен иметь возможность устанавливать клиентское программное обеспечение на нескольких машинах. Тем не менее, только первичная машина имеет возможность синхронизироваться с LOB-системой. Другие машины считаются вторичными машинами. LOB-система возвращает бизнес-ответ синхронно с первичной машиной. LOB-система взаимодействует со средством форматирования, чтобы предоставлять исходящие из LOB-системы "команды" на первичную машину, например, команды создания, обновления или удаления. В любое время может быть только одна первичная машина. Вторичные машины (к примеру, клиент 260), которые включают в себя собственную копию комплекта программных приложений для продуктивной работы (270), по-прежнему содержат копию информации, доступной на первичной машины, включая бизнес-состояние и состояние синхронизации связываемых элементов (к примеру, элемент 280 для продуктивной работы, включая свойства 281-283). Описанная система может быть выполнена с возможностью хранить кэш синхронизации на сервере, чтобы распространять ответы по бизнес-состоянию от сервера вторичным клиентам.

Элементы комплекта программных приложений для продуктивной работы (к примеру, элемент 230) должны содержать достаточно информации, чтобы система распознавала и воспроизводила привязываемые элементы. LOB-данные (включая перемещенные на более высокий уровень свойства) должны быть сохранены и ассоциативно связаны с элементом комплекта программных приложений для продуктивной работы. Системная информация, сохраненная в элементах комплекта программных приложений для продуктивной работы, должна быть статической. Другими словами, она не должна изменяться после того, как она задана, чтобы избегать появления "искусственных" конфликтов синхронизации. Система должна сохранять данные синхронизации и системные свойства, связанные с синхронизацией, вне элементов комплекта программных приложений для продуктивной работы. Маркер, который скрыт в свойстве, может быть использован для того, чтобы указывать то, какая машина является первичной. В некоторых случаях маркер может быть передан, с тем чтобы первичная машина могла быть изменена, например, в случае восстановления после сбоя.

Фиг.3 иллюстрирует то, как устанавливается корреляция между привязываемым элементом (330) и LOB-объектом (370), когда новый привязываемый элемент создается посредством LOB-системы. Сначала LOB-объект (370) создается в LOB-системе (360), как указано посредством этапа 1 (391), при этом LOB-объект (370) включает в себя идентификатор (LOBID 372). LOB-система (360) передает запрос (392) на сервер (340), чтобы создать LOB-объект, идентифицированный посредством LOBID 372, в качестве привязываемого элемента, как указано посредством этапа 2. Сервер (340) принимает запрос (392) и применяет средство (250) форматирования к запросу (392), приводя к передаче команды (394) в первичный клиент (310), чтобы создать привязку. Подсистема (320) синхронизации для комплекта программных приложений для продуктивной работы (к примеру, Outlook) на сервере (310) принимает команду (392) в ходе следующей синхронизации и создает привязку к элементу (350) Outlook, как указано посредством этапа 5. Привязываемый элемент имеет уникальный идентификатор (UID 332), который назначается ему, и ассоциативно связывается с LOB-объектом посредством LOBID 334.

Фиг.4 иллюстрирует то, как устанавливается корреляция между привязываемым элементом и LOB-объектом, когда новый привязываемый элемент создается посредством комплекта программных приложений для продуктивной работы. Сначала элемент (430) создается в комплекте программных приложений для продуктивной работы, как указано, посредством этапа 1 (491). Затем подсистема (420) синхронизации в комплекте программных приложений для продуктивной работы (к примеру, Outlook) передает (492) команду создания привязки в LOB-систему (460), как указано, посредством этапа 2. LOB-система (460) принимает команду создания привязки в ходе следующей синхронизации с клиентом и создает LOB-объект (470), идентифицированный посредством LOBID 472, как проиллюстрировано, посредством этапа 3 (493). LOB-система (460) необязательно передает LOBID (472) обратно клиенту (410) на этапе 4 (494), причем клиент (410) затем может ассоциативно связывать LOBID (434) с привязываемым элементом (430), как проиллюстрировано, посредством этапа 5 (495). В некоторых случаях LOBID (472) не передается обратно в комплект программных приложений для продуктивной работы.

Фиг.5 иллюстрирует то, как изменяется корреляция между привязываемым элементом и LOB-объектом, когда привязываемый элемент обновляется или удаляется в комплекте программных приложений для продуктивной работы. Сначала элемент (530) изменяется в комплекте программных приложений для продуктивной работы, как указано, посредством этапа 1 (591). Далее подсистема (520) синхронизации в комплекте программных приложений для продуктивной работы (к примеру, Outlook) передает (к примеру, посредством обращения к веб-услуге), обновить либо удалить в LOB-систему (560), как указано, посредством этапа 2 (592). LOB-система (560) принимает команду обновления/удаления привязки в ходе следующей синхронизации с клиентом (510) и модифицирует либо удаляет LOB-объект (570), идентифицированный посредством LOBID 572, как проиллюстрировано, посредством этапа 3 (593). В некоторых случаях, когда LOBID (534) неизвестен посредством комплекта программных приложений для продуктивной работы, LOB-система (560) ссылается на идентификатор привязки BIID 532, чтобы определить то, какой LOB-объект (570) модифицировать или удалять.

Фиг.6 иллюстрирует то, как изменяется корреляция между привязываемым элементом и LOB-объектом, когда привязываемый элемент обновляется или удаляется посредством LOB-системы. Сначала LOB-объект (670) модифицируется или удаляется в LOB-системе (660), как указано, посредством этапа 1 (691). LOB-система (660) передает запрос (692) в сервер (640), чтобы обновить или удалить LOB-объект, идентифицированный посредством, по меньшей мере, одного из LOBID (672) и BIID в запросе (692) на сервер (640). Сервер (640) принимает запрос (692) и применяет средство (650) форматирования к запросу (692), приводя к передаче команды или управляющего сообщения (694), чтобы изменить или удалить привязываемый элемент, как указано, посредством этапа 4. Подсистема (620) синхронизации комплекта программных приложений для продуктивной работы (к примеру, Outlook) на первичном клиенте (610) принимает команду в ходе следующей синхронизации и модифицирует либо удаляет привязку (к примеру, BIID 532 и LOBID 634) с соответствующим привязываемым элементом (630), как указано, посредством этапа 5 (695).

Подсистема синхронизации, описанная выше, развертывается на клиентских машинах, которые могут быть в рамках или вне корпоративной сети. Подключение по виртуальной частной сети или VPN к корпоративной сети ожидается, как и соединения удаленной синхронизации HTTP-типа, посредством серверного приложения, такого как Microsoft Exchange Server. LOB-синхронизация может выполняться как фоновый подпроцесс на клиентском устройстве, пока выполняется комплект программных приложений для продуктивной работы. Изменения, сделанные в комплекте программных приложений для продуктивной работы, предоставляются в LOB-систему посредством любого доступного RPC-механизма (к примеру, корпоративной сети, VPN, HTTP и т.д.), тогда как изменения в LOB-систему, как ожидается, выполняются только по корпоративной сети. Файловая синхронизация может обрабатываться любым надлежащим способом в корпоративной сети, например, посредством Microsoft Active Directory, которая может быть выполнена с возможностью предоставлять. NET API для этих целей.

Примерные определения интерфейсов синхронизации

Для каждого типа привязываемого элемента подсистема синхронизации выполняет различное действие в зависимости от изменения, которое возникает (создание/обновление/удаление). Помимо этого действие "Query" может быть активировано в результате обработки управляющего сообщения запроса. Ниже указывается информация, которая должна быть передана и возвращена из каждого из этих действий.

Create вызывается системой каждый раз, когда обрабатывается создание Привязываемого Элемента на стороне клиента. Параметры для Create включают в себя BoundItemID, NewItemData и CultureName. Возвращаемые значения для Create включают в себя LOBID, BusinessStatus и Description. BoundItemID - это сформированная клиентом строка уникального идентификатора для привязываемого элемента. NewItemData - это XML-документ, который задается посредством схемы для LOB-системы с тем, чтобы LOB-данные для привязываемого элемента предоставлялись надлежащим образом. CultureName - это название культуры, которая должна быть использована для бизнес-состояния, описания и всех остальных сообщений, извлекаемых из вызова Create. LOBID - это строка, которая формируется посредством LOB в качестве уникального идентификатора типа элемента (к примеру, ContactID уникально идентифицирует контакт). BusinessStatus - это строка, которая соответствует краткому имени нового бизнес-состояния, которое должно быть назначено привязываемому элементу в результате Create. Это произвольное значение, предоставляемое посредством LOB-системы, синхронизация не делает никаких допущений по содержимому этого значения. Идея заключается в том, что это значение может быть использовано для того, чтобы фильтровать элементы, которые находятся в одном состоянии. Description - это необязательная строка, которая является пояснением к BusinessStatus. Она является частью информации привязываемых элементов, так чтобы при необходимости Description могла быть предоставлена в UI.

Update вызывается системой каждый раз, когда обрабатывается обновление привязываемого элемента на стороне клиента. Параметры Update включают в себя BoundItemID, RequestID, LOBID, PreviousItemData, NewItemData и CultureName. Возвращаемые значения для Update включают в себя BusinessStatus и Description. RequestID - это уникальный идентификатор сообщения обновления, чтобы предоставить возможность LOB-системе идентифицировать копии. Такой же идентификатор запроса должен быть отправлен, если дублированное сообщение обновления отправлено. PreviousItemData - это XML-документ, который соответствует всем LOB-данным из привязываемого элемента из последнего синхронизированного состояния.

Delete вызывается системой каждый раз, когда обрабатывается обновление привязываемого элемента на стороне клиента. Параметры для Delete включают в себя BoundItemID, LOBID, PreviousItemData и CultureName. Возвращаемые значения для Delete включают в себя BusinessStatus и Description.

QueryResult вызывается системой каждый раз, когда обрабатывается управляющее сообщение запроса. Параметр QueryResult - это XML-документ, содержащий перечень идентификаторов привязываемых объектов и их соответствующий LOBID для всех существующих привязываемых объектов указанного типа. Нет возвращаемых значений для QueryResult.

Примерные определения управляющих сообщений

Данный раздел указывает информацию, которая ожидается в каждом типе управляющего сообщения. Управляющие сообщения включают в себя: Create Control Message, Update Control Message, Delete Control Message и Query Control Message.

Create Control Message включает в себя поля для: BoundItemID, LOBID, BoundItemType и LOBData. Update Control Message включает в себя поля для: LOBID, BoundItemType и LOBData. Delete Control Message включает в себя поля для: LOBID и BoundItemType. Query Control Message включает в себя поле для BoundItemType.

BoundItemID - это уникальный идентификатор, назначаемый новому привязываемому элементу. BoundItemID формируется средством форматирования, как подробнее описано ниже. BoundItemType - это строка, которая соответствует полному имени типа привязываемого элемента, включая решение и версию. BoundItemType может быть использован системой для того, чтобы находить соответствующее определение привязываемого элемента, которое описывает свойства, которые должны быть привязаны к элементу комплекта программных приложений для продуктивной работы, а также то, как элемент комплекта программных приложений для продуктивной работы должен быть синхронизирован с LOB-объектом. Как ранее описано, LOBID - это уникальный идентификатор, назначенный посредством LOB-системы привязываемому элементу, а LOB-данные - это XML-документ, содержащий все LOB-данные для привязываемого элемента.

Примерная система синхронизации

Система может быть скомпонована так, что она не основывается на событиях из комплекта программных приложений для продуктивной работы (к примеру, Microsoft Outlook), чтобы активировать и обнаруживать синхронизацию. Чтобы обнаруживать изменения (создание / обновление / удаление), система использует подход 3-сторонней синхронизации между комплектом программных приложений для продуктивной работы, хранилищем данных синхронизации (SDS) и информацией, полученной непосредственно из LOB-системы. Данные могут быть изменены из нескольких входных точек в системе. Информация может быть изменена во множестве различных мест, включая точки веб-доступа, мобильные устройства и другие клиентские машины. Изменения в итоге синхронизируются с первичной клиентской машиной (к примеру, посредством синхронизации Outlook/Exchange).

LOB-система может обнаруживать и обрабатывать дублированные запросы на основе уникального идентификатора запроса. Исходящая (клиент-сервер) связь с LOB-системой может быть осуществлена посредством веб-служб, тогда как входящие (сервер-клиент) сообщения предоставляются клиентам посредством серверного приложения (к примеру, Microsoft Exchange).

Обнаружение конфликтов также обрабатывается системой, когда один привязываемый элемент изменяется посредством LOB-системы и комплекта программных приложений для продуктивной работы. Если система обнаруживает то, что один привязываемый элемент обновлен пользователем и LOB-системы, идентифицируется конфликт, и разрешение конфликтов разрешает его соответствующим образом.

LOB-система поддерживает предоставление немедленных бизнес-ответов, когда принято синхронное обращение к веб-службе. LOB-системе не требуется принимать подтверждения или оповещения об ошибке по успешности обработки команд Create, Update, Delete или Query.

Этот раздел описывает высокоуровневые потоки информации между LOB-системой и клиентом. Следующие схемы предоставляют обзор возможных потоков информации, которые поддерживаются.

Фиг.7 иллюстрирует примерный поток информации между клиентом и сервером в ходе операции выталкивания (записи). Операция выталкивания может быть инициирована клиентом (710) или сервером (750), как описывается.

Этап 1 иллюстрирует инициированный клиентом (710) поток, в котором процесс обнаружения изменения выполняется системой на клиенте. На этапе 1 логика (730) синхронизации в системе идентифицирует новые, обновленные и удаленные привязываемые элементы и создает (791) виртуальный список запросов на изменение, которые должны быть предоставлены в LOB-систему. Виртуальный список может быть предоставлен в очереди, такой как виртуальная исходящая очередь (VOQ 712). Список обрабатывается, когда есть подключение (связность) (к примеру, обращение 792 к веб-службе) к LOB-системе (к примеру, серверу 750), на этапе 2. Если подключение к LOB-системе не идентифицировано на этапе 2, то список повторяется в следующий раз, когда выполняется процесс обнаружения изменений

При создании виртуального списка запросов система также учитывает новые поступающие управляющие сообщения (оповещения создания, обновления, удаления, исходящие из LOB-системы, из списка 714 управляющих сообщений), чтобы обнаруживать и разрешать либо вызывать конфликты соответствующим образом. Конфликт обнаруживается посредством логики (730) синхронизации, когда один элемент модифицирован в комплекте программных приложений для продуктивной работы и в LOB-системе либо когда одна сторона пытается обновить элемент, пока другая пытается удалить его. Для каждого обнаруженного изменения (создания, обновления, удаления), которое не приводит к конфликту, система предоставляет запрос в LOB-систему (к примеру, сервер 750) посредством обращения к веб-службе (792), как, к примеру, описано в определениях интерфейса синхронизации.

LOB-система (к примеру, сервер 750 с LOB-приложением 760) также может инициировать выполнение действия создания, обновления, удаления или запроса в клиенте (710), когда соответствующие действия осуществляются в LOB-системе. На этапе 3 LOB-система обращается к веб-службе (793), которая предоставляется средством (770) форматирования. В случае запросов создания средство (770) форматирования возвращает уникальный идентификатор, который используется системой для того, чтобы идентифицировать новый привязываемый элемент. Подробности по информации, отправляемой в качестве части обращения к веб-службе, см. в разделе "Определения интерфейса синхронизации", описанном в данном документе.

На этапе 4 средство (770) форматирования формирует управляющее сообщение (794) и отправляет его в указанный почтовый ящик, ассоциативно связанный с комплектом программных приложений для продуктивной работы (к примеру, почтовый ящик Outlook). Управляющие сообщения (794) отправляются от специализированной учетной записи. Когда управляющее сообщение доставляется в целевой почтовый ящик (к примеру, посредством Microsoft Exchange Server или какого-либо другого сервера 780 электронной почты и каталогов), оно автоматически перемещается в скрытую папку посредством правила на стороне сервера, с тем чтобы случайное удаление управляющих сообщений предотвращалось. Правило на стороне сервера поддерживается (создается и повторно создается) клиентом (к примеру, подробные сведения см. в техническом описании "Outlook Add-in").

На этапе 5 управляющие сообщения (795) доставляются в клиент (710) посредством механизма типа электронной почты, который отформатирован для приложения комплекта программных приложений для продуктивной работы (720). Клиент (710) обрабатывает управляющие сообщения (795) на этапе 6 (796) посредством выполнения процесса синхронизации, который создает, обновляет и удаляет привязываемые элементы при необходимости. При обработке управляющих сообщений система также учитывает локальные изменения (создание, обновление, удаление привязываемых элементов), которые должны быть переданы в LOB-систему, чтобы обнаруживать и помечать конфликты соответствующим образом.

Фиг.8 и 9 иллюстрируют операцию извлечения, которая может быть использована в другой примерной системе, причем извлечение может быть инициировано посредством веб-службы синхронизации или посредством принудительного «подталкивания», которое инициировано посредством LOB-системы.

Логика синхронизации

Привязываемые элементы могут быть изменены, поскольку пользователь изменяет их непосредственно или косвенно посредством синхронизации (к примеру, интерфейса веб-доступа). Требуется процесс, который сравнивает элементы и определяет различия между клиентом и LOB-системой, чтобы принять решение о том, должны ли изменения на одной стороне распространяться на другую сторону.

Изменение может выполняться одним из четырех способов. Во-первых, пользователь может изменить привязываемый элемент в комплекте программных приложений для продуктивной работы. Система обнаруживает и автоматически предоставляет запрос на изменения в LOB-систему. Во-вторых, изменение может быть выполнено посредством другого клиента, и это влияет и на клиента комплекта программных приложений для продуктивной работы посредством синхронизации и на LOB-систему. Изменения в комплекте программных приложений для продуктивной работы и LOB-системе могут осуществляться в любой последовательности с любой задержкой. В-третьих, изменения могут быть выполнены посредством смартфона, веб-доступа или любого другого средства и синхронизированы через сервер с комплектом программных приложений для продуктивной работы. Эти изменения должны обнаруживаться посредством процесса синхронизации. В-четвертых, изменения могут выполняться в самой LOB-системе. Каждый тип изменения должен рассматриваться посредством процесса синхронизации.

Локальное хранилище данных синхронизации (SDS) сохраняет исходную версию. SDS синхронизируется и затем используется для того, чтобы отслеживать дельты (разницы) между комплектом программных приложений для продуктивной работы и LOB-системой. Дельты затем добавляются в виртуальную очередь запросов, содержащих все служебные запросы к LOB-системе. Процедуры обновления определяют, когда изменения должны быть распространены в LOB-систему. Логика синхронизации формулирует запрос и предоставляет его в LOB-систему, когда есть подключение. При обновлении комплекта программных приложений для продуктивной работы логика синхронизации использует информацию LOB-системы для того, чтобы обновлять Outlook, а затем обновляет SDS.

Большая часть привязываемых данных содержится в двух местах: в качестве элемента в комплекте программных приложений для продуктивной работы и в LOB-системе. Предполагается, что каждая копия содержит дополнительные данные, которые отсутствуют в другой копии. Система синхронизации отвечает за синхронизацию совместно используемого поднабора свойств, хранящихся в свойстве BoundData привязываемого элемента, и наличие привязываемого элемента, к примеру, элемент может быть создан или уничтожен в результате синхронизации. Система синхронизации допускает одно определение истины: LOB-система всегда права. В то же время система синхронизация не имеет какого-либо прямого доступа к LOB-объектам и, тем самым, хранит отдельную копию в SDS того, что, как она предполагает, сохранено в LOB-системе.

Процесс синхронизации может быть разделен на несколько отдельных фаз. В фазе обзора все привязываемые элементы в почтовом ящике сравниваются с SDS. Несовпадения ссылочной целостности между почтовым ящиком и SDS обнаруживаются и сразу исправляются. Модифицированные элементы обнаруживаются и помечаются для дальнейшей обработки. Удаленные элементы далее обнаруживаются и передаются в средство синхронизации с тем, чтобы соответствующий запрос на удаление мог быть отправлен в LOB-систему. В некоторых реализациях различные фазы процесса синхронизации, описанные выше, могут быть объединены в один интегрированный процесс, где различные функции (к примеру, привязка, обзор, разрешение и т.п.) могут быть комбинированы в упрощенный алгоритм. Упрощенный алгоритм может достигать большей скорости исполнения или достигать некоторой другой большей эффективности (к примеру, снижение использования памяти/диска, устранение избыточности и т.д.).

Любые управляющие сообщения, которые идентифицированы, обрабатываются в ходе второй фазы. Далее выполняется промотирование (расширение) свойств на более высокий уровень для всех элементов, которые помечены как модифицированные. Результирующее обновленное представление XML-данных сравнивается с копией SDS, и оповещается средство синхронизации. Средство синхронизации запускается в фоновом подпроцессе и в этом варианте осуществления использует копии SDS. Средство синхронизации отвечает за предоставление запросов Create, Update и Delete, а также обработку запросов.

Копия SDS содержит те же свойства, что и упомянутые выше. В обычной ситуации EntryID, BoundltemID, BoundItemType и LOBID являются одинаковыми для элемента комплекта программных приложений для продуктивной работы и копии SDS. Все различия между элементом комплекта программных приложений для продуктивной работы и копией SDS интерпретируются как запрос на обновление LOB-объекта. Если нет, ссылочная целостность нарушается, и элемент комплекта программных приложений для продуктивной работы должен быть дополнительно проанализирован. Основные причины любых различий состоят в следующем: элемент создан пользователем, еще нет копии SDS для этого элемента, но свойство BoundData является читаемым, и элемент скопирован, перемещен либо удален пользователем, привязка между EntryID и BoundItemID нарушена; может быть нуль, один или более элементов, все из которых связаны с одной копией SDS, и их свойства BoundData являются читаемыми, обновленной запрос встречи или запрос задачи принят пользователем; были повреждены соответствующее назначение встречи или задача (привязываемый элемент). EntryID сохранился, но свойство BoundData более не читается. Копия постороннего привязываемого объекта принята от другого пользователя. Свойство BoundData не читается, и нет соответствующей копии для этого элемента в SDS. Копия или привязываемый элемент отправлен другому пользователю, а затем он отправлен обратно. Это разновидность предшествующих возможностей, и она не может рассматриваться как специальный случай. Возможно, произошло повреждение данных.

Имеется встроенное допущение, что BoundItemID является уникальным (первичный ключ), и комбинация BoundItemType+LOBID также является уникальной (вторичный ключ). Эти ограничения должны быть активированы в базе данных SDS. Разумеется, в почтовом ящике EntryID также является уникальным. Любой элемент, где свойство BoundData является нечитаемым или где дублированные свойства, сохраненные внутри, не соответствуют таким же свойствам (BoundItemID, BoundItemType и LOBID) в элементе Outlook, считается поврежденным. В качестве общего правила привязка данного поврежденного элемента автоматически отменяется. Любой дублированный элемент (где несколько элементов Outlook имеют один BoundItemID) обнаруживается и либо преобразуется в новый привязываемый элемент, либо его привязка отменяется; оригинал сопоставляется с копией SDS (в случае перемещения мы выбираем одну копию).

Поток информации

Фиг.10 иллюстрирует другой примерный поток информации между комплектом программных приложений для продуктивной работы на клиенте и LOB-системой. LOB-система (1070) может инициировать обновления в привязанных элементах посредством управляющих сообщений (Create, Update и Delete). Служба средства (1080) форматирования создает управляющие сообщения, как запрошено, посредством LOB-системы (1070). Управляющие сообщения передаются в комплект программных приложений для продуктивной работы посредством электронного сообщения в почтовом ящике (1010). Правило на стороне сервера перемещает управляющее сообщение в указанную (скрытую) папку (к примеру, папку 1020 управляющих сообщений), из которой они выбираются посредством процессора (1030) управляющих сообщений. Запросы Create, Update и Delete обрабатываются сразу, тогда как запросы Query помещаются в очередь в SDS (1050) и обрабатываются средством (1060) синхронизации. Служба средств (1040) привязки/обзора/разрешения (или службы, в зависимости от реализации) выполнена с возможностью сравнивать все привязываемые элементы в почтовом ящике (1010) с SDS (1050) и идентифицировать несовпадения/изменения в привязываемых элементах.

Хотя не очень распространенный, но при этом важный, сценарий включает в себя повторное создание LOB-системой всех привязываемых элементов для данного пользователя. Это может быть использовано для того, чтобы заполнить почтовый ящик начальными привязываемыми элементами, а также как часть восстановления после сбоя, когда некоторые элементы были потеряны или повреждены. Разновидность этого сценария может быть использована для того, чтобы обновлять существующие привязываемые элементы до нового определения (схемы) привязки. Она также может запрашивать информацию о текущем состоянии привязываемых элементов (Query). Другое распространенное использование заключается в том, чтобы отправлять обычные почтовые сообщения в почтовый ящик пользователя (1010); в этом случае система синхронизации не участвует.

Идентификационные данные отправителя используются для того, чтобы отличать допустимые управляющие сообщения от неавторизованных (или ложных) управляющих сообщений. Информация в управляющем сообщении может быть зашифрована, чтобы защитить его конфиденциальность.

Первичная машина отвечает за обработку управляющих сообщений, продвижение свойств на более высокий уровень, разрешение конфликтов и предоставление обновлений в LOB. Это поддерживает SDS и почтовый ящик синхронизированными. Вторичная машина может быть использована для того, чтобы обновлять привязываемые элементы посредством UI. Она также привязывает собственную базу данных SDS с использованием синхронизации, но с некоторыми важными отличиями. Вторичная машина не обрабатывает управляющее сообщение и не выполняет продвижение (промотирование) свойств на более высокий уровень в ходе синхронизации, также вторичная машина не отправляет изменения в LOB-систему. При составлении SDS вторичная машина предполагает, что данные в почтовом ящике корректные. Все сбои по обновлению SDS вследствие проблем ссылочной целостности "тихо" игнорируются, поскольку предполагается, что первичная машина в итоге разрешит конфликт, и что разрешение будет распространено на вторичную машину. Важное следствие этих правил заключается в том, что SDS на вторичной машине не содержит полное состояние всех ожидающих выполнения изменений, а следовательно, оно не может быть расширено на первичную.

Сервер может быть выполнен с возможностью хранить кэш синхронизации (к примеру, аналогично SDS, но исключая информацию привязываемых данных) для целей распространения ответов по бизнес-состоянию от сервера в различные вторичные клиентские машины. Периодически сервер может проталкивать (записывать) изменения на вторичный клиент, так чтобы вторичные клиенты имели самую свежую копию соответствующих данных SDS.

Подсистема синхронизации

Подсистема синхронизации проиллюстрирована на фиг.11, и она состоит из следующих основных компонентов: контроллер (1102), диспетчер (1106) привязываемых элементов, средство упаковки привязываемых элементов, средство (1112) обзора, средство (1109) разрешения, процессор (1110) управляющих сообщений, поставщик (1107) данных и средство (1105) синхронизации.

Контроллер (1102) - это общедоступный компонент, используемый для того, чтобы управлять процессом синхронизации.

Диспетчер (1106) привязываемых элементов - это общедоступный компонент, который используется для того, чтобы создавать и/или непосредственно осуществлять доступ к привязываемым элементам. Средство упаковки привязываемых элементов - это общедоступное средство упаковки, которое инкапсулирует элемент комплекта программных приложений для продуктивной работы как привязываемый элемент или отменяет привязку элемента. В некоторых реализациях функциональность диспетчера (1106) привязываемых элементов может быть включена как часть контроллера (1102) или как часть другого компонента.

Средство (1112) обзора - это внутренний компонент, используемый для того, чтобы находить привязываемые элементы, которые должны быть проанализированы (поскольку они изменились с момента, когда произошла последняя синхронизация). В некоторых реализациях функциональность средства (1112) обнаружения может быть включена как часть контроллера (1102) или как часть другого компонента.

Средство (1109) разрешения - это внутренний компонент, используемый для того, чтобы анализировать привязываемые элементы и либо разрешать изменения локально (посредством расширения (распространения) свойств на более высокий уровень), и/или помечать их для полной синхронизации. В некоторых реализациях функциональность средства (1109) разрешения может быть включена как часть контроллера (1102) или как часть другого компонента.

Процессор (1110) управляющих сообщений - это внутренний компонент, используемый для того, чтобы обрабатывать управляющие сообщения из отслеживаемой указанной папки (1111) для сообщений, отправляемых средством форматирования. Управляющие сообщения обрабатываются так, чтобы обновлять элементы комплекта программных приложений для продуктивной работы в случае глаголов Create/Update/Delete либо предоставлять команды Query, которые должны быть обработаны средством синхронизации. В некоторых реализациях функциональность процессора (1110) управляющих сообщений может быть включена как часть контроллера (1102) или как часть другого компонента.

Поставщик (1107) данных - это внутренний компонент, предоставляющий доступ к таблицам (1108) данных SDS. В некоторых реализациях функциональность поставщика (1107) данных может быть включена как часть контроллера (1102) или как часть другого компонента.

Средство (1105) синхронизации - это внутренний компонент, отвечающий за: оповещение LOB-систем, когда привязываемые элементы создаются, обновляются или удаляются на клиенте, обновление хранилища данных синхронизации (SDS 1108) после успешных оповещений, обработку управляющих сообщений Query и сообщения состояния процесса синхронизации. В некоторых реализациях функциональность средства (1105) синхронизации может быть включена как часть контроллера (1102) или как часть другого компонента.

Синхронизация изменений проиллюстрирована посредством фиг.12, как следует ниже. Изменения в привязываемые элементы могут выполняться только на первичной машине (машине с поддержкой OBA) либо посредством другого внутреннего интерфейса, например, из веб-службы (к примеру, Outlook Web Access или OWA), либо каких-либо других клиентов и мобильных устройств без поддержки OBA. В зависимости от того, где проведены изменения, система синхронизирует их с помощью немного отличающихся кодовых путей.

Управление привязываемыми элементами: клиенты с поддержкой

Пользователь может создавать, обновлять и удалять привязываемые элементы в клиенте, который поддерживает синхронизацию, например, с помощью встроенного или подключаемого компонента. Система обнаруживает изменения и автоматически предоставляет запрос на изменения в LOB-систему. Запрос обрабатывается, и LOB-система отправляет обратно ответ успешности или сбоя на уровне приложения. Этот ответ принимается клиентом, и бизнес-состояние приложения привязываемого элемента обновляется. В случае новых привязываемых элементов (к примеру, созданных в Outlook) ответ из LOB-системы используется системой для того, чтобы коррелировать привязываемый элемент с LOB-объектом.

Управление привязываемыми элементами: веб-доступ

Пользователь осуществляет доступ к своему почтовому ящику посредством веб-доступа. Привязываемые элементы предоставляются пользователю как стандартные элементы. Пользователь может изменять обычным образом стандартную информацию, но не расширенную информацию. Пользователь может обновлять или удалять существующие привязываемые элементы, но не может создавать новые за исключением случая копирования существующего привязанного элемента (косвенное создание). Когда пользователь возвращается к первичной машине, изменения, сделанные посредством веб-доступа, синхронизируются посредством серверного приложения (к примеру, посредством Microsoft Exchange). Система обнаруживает изменения и автоматически предоставляет соответствующий запрос на изменения в LOB-систему.

Управление привязываемыми элементами: клиенты без поддержки

Пользователь может осуществлять доступ к своему почтовому ящику с помощью клиента комплекта программных приложений для продуктивной работы, который не имеет соответствующей поддержки (не разрешен). Привязываемые элементы отображаются как стандартные элементы. Пользователь может изменять обычным образом стандартную информацию, но не расширенную информацию. Пользователь может обновлять или удалять существующие привязываемые элементы, но не может создавать новые. После этого пользователь синхронизируется с серверным приложением (к примеру, Microsoft Exchange). Когда пользователь возвращается к первичной клиентской машине, изменения, выполненные в клиенте без поддержки, синхронизируются из серверного приложения. Система обнаруживает изменения и автоматически предоставляет соответствующий запрос на изменения в LOB-систему.

Управление привязываемыми элементами: мобильные устройства

Пользователь осуществляет доступ к своему почтовому ящику посредством мобильного устройства. Специальной поддержки мобильных устройств не предусмотрено, они трактуются как веб-доступ. Привязываемые элементы предоставляются пользователю как стандартные элементы. Пользователь может изменять обычным образом стандартную информацию, но не расширенную информацию. Пользователь может обновлять или удалять существующие привязываемые элементы, но не может создавать новые. Когда пользователь возвращается к первичной клиентской машине, изменения, сделанные на мобильном устройстве, синхронизируются посредством серверного приложения (к примеру, Microsoft Exchange). Система обнаруживает изменения и автоматически предоставляет соответствующий запрос на изменения в LOB-систему.

Управление привязываемыми элементами: множество клиентов с поддержкой

Пользователь имеет "первичную" клиентскую машину и любое количество "вторичных" клиентских машин, причем каждая машина имеет установленное клиентское приложение, которое предоставляет синхронизацию между приложениями комплекта программных приложений для продуктивной работы и LOB-системой. Пользователь может создавать, обновлять или удалять привязываемые элементы на любой машине. Изменения, сделанные на одной машине, синхронизируются с другими посредством серверного приложения (к примеру, Microsoft Exchange), но в одном варианте осуществления только первичная машина имеет возможность синхронизироваться с LOB-системой. "Первичная" машина задается во время установки; другие машины считаются "вторичными" машинами. Нет специального предела на число вторичных машин, которое может иметь пользователь. Когда возможность подключения к LOB-системе доступна на первичной машине, система автоматически отправляет требуемые запросы на изменение в LOB-систему.

Описанная система может быть скомпонована так, что кэш синхронизации поддерживается на сервере для целей распространения ответов по бизнес-состоянию от сервера в различные вторичные клиентские машины. Для этого примера кэш синхронизации сервера обновляется до или после каждого обзора первичного клиента. Кэш синхронизации сервера может состоять из всех данных из SDS за исключением BoundData. Согласно расписанию интервалов обзоров кэш синхронизации сервера может загружаться с сервера в собственную SDS каждого вторичного клиента.

Управление привязываемыми элементами: распространение изменений

Когда изменения в соответствующие бизнес-объекты выполняются в LOB-системе, серверное приложение оповещается средством форматирования. Оповещение об изменения доставляется в клиенты с поддержкой (разрешенные), которым может потребоваться применить изменения к привязываемому элементу. Поскольку оповещение об изменениях вытолкнуто (передано), клиенты не должны перебрасывать обновление и могут немедленно отвечать без ожидания в течение назначенного времени синхронизации.

Способ синхронизации

Фиг.13 - это блок-схема последовательности операций примерного способа синхронизации. Периодически системный процесс средства обзора может находить и "помечать" привязываемые элементы, которые должны быть синхронизированы, при этом данные элементы помещаются в логический список для синхронизации (список синхронизации). Для каждого элемента в списке синхронизации запрос на создание, обновление или удаление (запрос CUD) формируется и сохраняется в исходящей очереди (к примеру, VOQ 712 с фиг.7). Обращение к веб-службе затем инициируется, с тем чтобы могло быть установлено соединение к LOB-системе. Обращение к веб-службе может завершиться успешно, ошибкой или сформировать исключение соединения.

Успешное соединение устанавливается, когда ответ получается от LOB в ответ на обращение к веб-службе. Для успешного соединения к веб-службе система обновляет копию привязываемого элемента в SDS информацией из ответа. Дополнительные запросы CUD обрабатываются аналогично для каждого элемента в списке синхронизации.

Ошибка соединения возникает, когда исключение, отличное от исключения соединения, предоставляется из LOB-системы в ответ на обращение к веб-службе. Для ошибки соединения к веб-службе запрос CUD сохраняется в исходящей очереди и помечается для повтора. Счетчик повторов запроса CUD может быть инициализирован, когда идентифицирована первая ошибка соединения. Повторы продолжаются до тех пор, пока либо не будет установлено успешное соединение, либо максимальное число попыток, разрешенных в заранее определенном интервале времени, не достигнет предела. Запрос CUD перемещается в очередь ошибочных запросов, когда максимальное число разрешенных попыток достигается без успеха. Дополнительные запросы CUD не обрабатываются до тех пор, пока успешное соединение не будет достигнуто.

Исключение соединения может возникать, когда клиент имеет допустимый куки-файл аутентификации, и передача на целевой сервер завершается ошибкой. Система переходит к следующему элементу в списке синхронизации, когда исключение соединения возникает в результате обращения к веб-службе.

Примерный поток операций синхронизации проиллюстрирован на фиг.13, как описано ниже. Обработка начинается на этапе 1301 и переходит к этапу 1305 принятия решения.

На этапе 1305 принятия решения система синхронизации комплекта программных приложений для продуктивной работы оценивает список синхронизации, чтобы идентифицировать все привязываемые элементы, которые должны быть синхронизированы между приложением комплекта программных приложений для продуктивной работы и LOB-приложением. Когда нет привязываемых элементов в списке синхронизации, обработка переходит к этапу 1310, на котором система ожидает в течение заранее определенного времени (к примеру, X минут) до повторной оценки списка синхронизации. Когда привязываемые элементы обнаружены в списке синхронизации, система определяет, достигнуто ли максимальное число ошибочных запросов, на этапе 1315. Когда максимальное число запросов достигнуто, обработка снова переходит к этапу 1310. Альтернативно, обработка переходит к этапу 1320, на котором создается запрос CUD.

Переходя к этапу 1325, запрос CUD помещается в очередь исходящих запросов, например, VOQ 712 из фиг.7. На этапе 1330 система синхронизации приложений комплекта программных приложений для продуктивной работы отправляет каждый запрос в очереди исходящих запросов в LOB-систему посредством вызова (обращения к) службе, такого как обращение к веб-службе. Переходя к этапу 1335, запрос обращения CUD оценивается для того, чтобы определить то, был ли запрос успешно предоставлен в LOB-систему. Обработка переходит от этапа 1335 к этапу 1340 (на котором обновляется хранилище данных синхронизации, или SDS), когда запрос обращения CUD является успешным. Обработка переходит от этапа 1335 принятия решения к этапу 1345, когда запрос обращения CUD завершается ошибкой. В некоторых случаях исключение подключения формируется, и обработка переходит от этапа 1335 принятия решения к этапу 1305 принятия решения.

На этапе 1345 система синхронизации приложения комплекта программных приложений для продуктивной работы пытается повторить запрос обращения CUD. На этапе 1350 система определяет то, принят ли ответ от запроса обращения. Когда ответ успешный, обработка переходит от этапа 1350 принятия решения к этапу 1340, на котором обновляется SDS. Когда ответ ошибочный, обработка переходит от этапа 1350 принятия решения к этапу 1360 принятия решения. Если ответ не принят, обработка переходит от этапа 1350 принятия решения к этапу 1355, на котором система ожидает в течение тайм-аута перед попыткой еще одного повтора на этапе 1345.

На этапе 1360 принятия решения система определяет, достигнуто ли максимальное число повторов для запроса обращения CUD. Кода максимальное число повторов достигнуто, обработка переходит к этапу 1365, на котором запрос CUD перемещается в очередь ошибок. Когда максимальное число повторов не превышено, система увеличивает внутренний счетчик повторов на этапе 1370 и переходит к этапу 1355. чтобы дождаться еще одного повтора.

Ссылка на синхронизированные элементы

Как описано выше, привязки создаются между LOB-объектами и PS-элементами. Когда система синхронизации не имеет какого-либо прямого доступа к LOB-объектам, система SDS хранит отдельную копию того, что как она считает, хранится в LOB-системе. Когда привязка между LOB-объектом и PS-элементом создана, копия синхронизированного PS-элемента может быть помещена в SDS, с тем чтобы PS-элемент мог быть индексирован с помощью LOBID, ассоциативно связанного с LOB-объектом. Другими словами, PS-элемент, который ассоциативно связан с LOB-объектом, может быть извлечен из SDS со ссылкой на LOBID. Поскольку PS-элемент может быть извлечен со ссылкой на LOBID, ряд «интересующихся» приложений, подключаемых модулей или других программных методов может быть реализован, которые могут использовать PS-элемент (к примеру, система поточной обработки баз данных).

В одном примере LOB-приложение может передавать LOB-идентификатор (к примеру, LOBID) в приложение комплекта программных приложений для продуктивной работы посредством почтового сообщения. Почтовое сообщение включает в себя внедренную информацию, которая ссылается на LOB-элемент. Например, LOBID может быть вложен в заголовок, ассоциативно связанный с почтовым сообщением. Почтовое сообщение необязательно должно содержать (вложенный или иным образом) сам LOB-объект, поскольку LOBID ссылается на LOB-объект. После того как почтовое сообщение принято, дескриптор электронной почты для комплекта программных приложений для продуктивной работы может идентифицировать конкретный элемент комплекта программных приложений для продуктивной работы в тени синхронизации или хранилище данных синхронизации, который обращается к LOB-идентификатору.

В другом примере пользователь может ссылаться на элемент комплекта программных приложений для продуктивной работы с помощью ссылки (к примеру, URL-ссылки в любом числе форм, например, HTTP, HTTPS, FTP, FTPS, OBA и т.д.), который ссылается на LOB-идентификатор, ассоциативно связанный с PS-элементом в SDS.

В еще одном примере панель действий, панель задач или другая подобная программная методология может быть активирована, когда LOB-система отправляет почтовое сообщение в систему комплекта программных приложений для продуктивной работы. После активации программная методология может извлекать элемент комплекта программных приложений для продуктивной работы из SDS посредством ссылки на LOBID и затем действовать согласно элементу комплекта программных приложений для продуктивной работы.

Действия, которые могут выполняться для элемента комплекта программных приложений для продуктивной работы в программной методологии, могут приводить к созданию, обновлению или удалению элемента комплекта программных приложений для продуктивной работы, который затем может быть синхронизирован с LOB-системой, как описано выше. LOB-система может эффективно передавать задачу пользователю комплекта программных приложений для продуктивной работы посредством ссылки на программную методологию и LOBID в почтовом сообщении.

В одной примерной программной методологии почтовое сообщение из LOB-системы может сообщать запрос пользователю, чтобы выполнить анализ (просмотр) или утверждение, ассоциативно связанное с конкретным элементом комплекта программных приложений для продуктивной работы, который синхронизирован с LOB-объектом, идентифицированным посредством LOBID. Почтовое сообщение может передаваться автоматически посредством LOB-системы, когда наступает крайний срок в LOB-системе или когда предоставляется посредством конкретного пользователя LOB-системы. Почтовое сообщение может быть создано посредством LOB-системы посредством передачи информации (к примеру, посредством представления XML-данных, посредством текста, посредством вложенных данных и т.д.) в средство форматирования, которое затем взаимодействует с сервером электронной почты и каталогов (см., к примеру, фиг.7), чтобы сформировать почтовое сообщение. Почтовое сообщение может подчеркивать необходимость завершить действие, которое ассоциативно связано с элементом комплекта программных приложений для продуктивной работы, предоставлять дополнительные пояснения и т.д., при этом почтовое сообщение может ссылаться на задачи в системе поточной обработки баз данных. Поскольку приложение комплекта программных приложений для продуктивной работы может интерпретировать ссылку, вложенную в почтовое сообщение, как задачу, фактическая информация по задаче может быть представлена автоматически. После этого пользователь может выбрать и перейти по ссылке, чтобы открыть элемент задачи в приложении комплекта программных приложений для продуктивной работы, при этом ассоциативно связанная информация системы баз данных может быть сохранена в виде XML-данных. Поскольку LOB-идентификатор может быть вложен в ссылку, любое требуемое действие, ассоциативно связанное с элементом комплекта программных приложений для продуктивной работы, может быть осуществлено посредством конфигурирования дескриптора (к примеру, URL-дескриптора) соответствующим образом.

Хотя проиллюстрированы и описаны примерные варианты осуществления и применения, следует понимать, что изобретение не ограничено точной конфигурацией и ресурсами, описанными выше. Различные модификации, изменения и вариации, очевидные специалистам в данной области техники, могут быть выполнены в структуре, работе и деталях способов и систем, раскрытых в данном документе, без отклонения от области применения заявленного изобретения. Поскольку многие варианты осуществления изобретения могут быть выполнены без отступления от духа и области применения изобретения, изобретение состоит в прилагаемой далее формуле изобретения.

Изобретение относится к средствам синхронизации бизнес-приложений. Техническим результатом является повышение скорости синхронизации приложений. Способ синхронизации выполнен с возможностью предоставлять синхронизацию между приложением комплекта программных приложений для продуктивной работы и бизнес-приложением, таким как приложение управления взаимоотношениями с клиентами. Запросы отправляются из приложения комплекта программных приложений для продуктивной работы в бизнес-приложения посредством обращения к веб-службе, чтобы обновлять, удалять или создавать новый объект в этом приложении. Бизнес-приложение извлекает каждый запрос из принимаемых обращений к веб-службе, при этом запрос может быть предоставлен в виде XML-данных. Запросы отправляются в приложение комплекта программных приложений для продуктивной работы посредством управляющих сообщений, которые внедрены в сообщение электронной почты, чтобы обновлять, удалять или создавать элемент в приложении комплекта программных приложений для продуктивной работы, при этом элемент ассоциативно связан с объектом бизенс-приложения. Управляющие сообщения скрыты от пользователя и извлекаются из почтового сообщения для оценки, разрешения конфликтов, продвижения на более высокий уровень свойств и привязки между объектом бизнес-приложения и элементом приложения комплекта программных приложений для продуктивной работы. 3 н. и 17 з.п. ф-лы, 13 ил.

1. Машиночитаемый носитель, имеющий машиноисполняемые инструкции для синхронизации информации между бизнес-приложением (LOB) и приложением комплекта программных приложений для продуктивной работы, при этом инструкции содержат этапы, на которых:
принимают передаваемое в режиме выталкивания сообщение электронной почты с помощью приложения (720) комплекта программных приложений для продуктивной работы, при этом управляющее сообщение (795) внедрено в передаваемое в режиме выталкивания сообщение электронной почты, причем управляющее сообщение - это представление (793) XML-данных из LOB-приложения (760), которое задает изменения в LOB-объекте;
извлекают управляющее сообщение (795) из сообщения электронной почты с помощью приложения (720) комплекта программных приложений для продуктивной работы на клиентской машине (710); и
идентифицируют изменения для привязываемого элемента в ответ на извлеченное управляющее сообщение (795) в ходе процесса (796) синхронизации, так чтобы привязываемый элемент был ассоциативно связан как с элементом (230) комплекта программных приложений для продуктивной работы, так и LOB-объектом (251), при этом управляющее сообщение (795) указывает по меньшей мере одно из: создания LOB-объекта, обновления LOB-объекта и удаления (214) LOB-объекта.

2. Машиночитаемый носитель по п.1, в котором инструкции дополнительно содержат этап, на котором:
аутентифицируют сообщение электронной почты до извлечения управляющего сообщения (795), с тем чтобы предотвращалась имитация доступа от неавторизованных отправителей.

3. Машиночитаемый носитель по п.1, в котором инструкции дополнительно содержат этап, на котором:
предоставляют оповещение пользователю, когда управляющее сообщение (795) извлечено из сообщения электронной почты.

4. Машиночитаемый носитель по п.1, в котором инструкции дополнительно содержат этап, на котором:
автоматически помещают извлеченное управляющее сообщение (795) по меньшей мере в одно из: скрытой папки и очереди (714) входящих сообщений.

5. Машиночитаемый носитель по п.1, в котором инструкции дополнительно содержат этап, на котором:
сохраняют каждый привязываемый элемент в хранилище данных синхронизации (SDS, 1050) на клиентской машине (710).

6. Машиночитаемый носитель по п.5, в котором инструкции дополнительно содержат этап, на котором:
идентифицируют изменения между элементами (230) приложения комплекта программных приложений для продуктивной работы и ассоциативно связанными LOB-объектами (251) с помощью SDS (1050) и помещают запросы на идентифицированные изменения в виртуальную очередь (712) запросов для синхронизации с LOB-системой (250).

7. Машиночитаемый носитель по п.5, в котором инструкции дополнительно содержат этап, на котором:
сравнивают все привязываемые элементы в почтовом ящике (1010) для приложения (720) комплекта программных приложений для продуктивной работы с SDS (1050) и обнаруживают и фиксируют ссылочную целостность между почтовым ящиком (1010) и SDS (1050).

8. Машиночитаемый носитель по п.7, в котором инструкции дополнительно содержат этапы, на которых:
помечают модифицированные элементы для последующей обработки, повышают уровень свойств помеченных элементов; и
сравнивают результирующее обновленное представление XML-данных с SDS-копией.

9. Машиночитаемый носитель по п.1, в котором процесс синхронизации содержит по меньшей мере одно из следующего: идентификация и разрешение конфликтов (1230), ассоциативно связанных с привязываемым элементом, повышение уровня свойства, ассоциативно связанного с привязываемым элементом, понижение уровня свойства, ассоциативно связанного с привязываемым элементом, и обновление привязываемых элементов без повышения уровня свойств, когда приложение комплекта программных приложений для продуктивной работы назначено вторичной машине (260).

10. Машиночитаемый носитель по п.1, в котором инструкции дополнительно содержат этапы, на которых:
создают исходящий запрос (212) в ответ на изменение элемента комплекта программных приложений для продуктивной работы на клиентской машине (210), при этом исходящий запрос содержит по меньшей мере одно из:
создания, обновления и удаления (212), ассоциативно связанных с элементом (230) комплекта программных приложений для продуктивной работы;
помещают исходящий запрос в исходящую очередь (712) для синхронизации с LOB-приложением (760);
инициируют обращение (792) к веб-службе для запроса в очереди к LOB-приложению (760) в первый момент времени, с тем чтобы LOB-приложение (760) могло извлечь исходящий запрос из веб-службы, когда веб-служба успешно подключается к LOB-приложению (760); и
удаляют исходящий запрос из исходящей очереди (712) и обновляют хранилище данных синхронизации (SDS, 1050), когда веб-служба успешно подключается к LOB-приложению (760).

11. Машиночитаемый носитель по п.10, в котором инструкции дополнительно содержат этап, на котором:
инициируют второе обращение (792) к веб-службе для исходящего запроса в исходящей очереди (712) во второй момент времени, когда веб-служба первоначально не смогла успешно подключиться к LOB-приложению.

12. Машиночитаемый носитель по п.10, в котором инструкции дополнительно содержат этап, на котором:
кодируют запрос в представление XML-данных для приема посредством LOB-приложения (760).

13. Устройство для синхронизации информации между бизнес-приложением (LOB) и приложением комплекта программных приложений для продуктивной работы, при этом устройство содержит:
процессор (104);
машиночитаемый носитель (116, 118, 120, 122, 124);
операционное окружение (126), сохраненное на машиночитаемом носителе и выполняемое в процессоре (104); и
приложение (128, 130), работающее под управлением операционного окружения (126) и выполненное с возможностью выполнять действие, при этом приложение (128, 130) выполнено с возможностью:
создавать запрос (214) в ответ на изменение LOB-объекта (251), при этом запрос содержит по меньшей мере одно из инструкции создать LOB-объект, обновить LOB-объект и удалить LOB-объект;
формировать представление (793) XML-данных, ассоциативно связанное с изменением LOB-объекта (251);
форматировать представление (770) XML-данных в управляющее сообщение (794), которое кодировано в сообщении электронной почты (780); и
передают в режиме проталкивания сообщение электронной почты (780) в приложение (720) комплекта программных приложений для продуктивной работы, с тем чтобы изменения в LOB-объекте (251) могли быть синхронизированы (730) с элементами приложения комплекта программных приложений для продуктивной работы, посредством извлечения управляющего сообщения (795) из сообщения электронной почты.

14. Устройство по п.13, в котором приложение дополнительно сконфигурировано так, чтобы передавать в режиме проталкивания сообщение электронной почты в другое приложение (270) комплекта программных приложений для продуктивной работы, которое имеется на вторичном клиенте (260).

15. Устройство по п.13, в котором приложение дополнительно сконфигурировано так, чтобы:
принимать обращение (792) к веб-службе;
извлекать запрос (791) обновления из обращения (792) к веб-службе, при этом запрос (791) обновления ассоциативно связан с изменением элемента приложения комплекта программных приложений для продуктивной работы; и
обновлять LOB-объект в ответ на извлеченный запрос обновления, причем извлеченный запрос обновления соответствует по меньшей мере одному из инструкции создавать элемент приложения комплекта программных приложений для продуктивной работы, обновлять элемент приложения комплекта программных приложений для продуктивной работы и удалять элемент приложения комплекта программных приложений для продуктивной работы.

16. Устройство по п.15, в котором запрос обновления от обращения (792) к веб-службе является другим представлением XML-данных.

17. Устройство по п.13, в котором приложение дополнительно сконфигурировано так, чтобы:
принимать обращение (792) к веб-службе из приложения (720) комплекта программных приложений для продуктивной работы,
извлекать запрос из обращения к веб-службе, и
создавать LOB-объект в ответ на извлеченный запрос.

18. Способ синхронизации информации между бизнес-приложением (LOB) и приложением комплекта программных приложений для продуктивной работы, при этом способ содержит этапы, на которых:
принимают представление (793) XML-данных из LOB-приложения (760), при этом представление (793) XML-данных идентифицирует изменения, ассоциативно связанные с по меньшей мере одним объектом в LOB-приложении (760);
форматируют (770) представление (793) XML-данных в управляющее сообщение (740);
внедряют управляющее сообщение (794) в сообщение электронной почты (780); и
передают в режиме выталкивания сообщение электронной почты (795) в приложение (720) комплекта программных приложений для продуктивной работы, с тем чтобы изменения, ассоциативно связанные по меньшей мере с одним объектом в LOB-приложении (760), могли быть синхронизированы с приложением (720) комплекта программных приложений для продуктивной работы.

19. Способ по п.18, дополнительно содержащий этапы, на которых:
принимают другое представление (792) XML-данных из приложения (720) комплекта программных приложений для продуктивной работы;
идентифицируют изменения, ассоциативно связанные с по меньшей мере одним элементом в приложении комплекта программных приложений для продуктивной работы, из другого представления (792) XML-данных; и
обновляют по меньшей мере один объект в LOB-приложении (760) на основе идентифицированных изменений, с тем чтобы упомянутый по меньшей мере один объект в LOB-приложении был привязан к по меньшей мере одному элементу в приложении комплекта программных приложений для продуктивной работы.

20. Способ по п.19, в которой обновление содержит по меньшей мере одно из: создания, модификации и удаления по меньшей мере одного объекта в LOB-приложении.