RU2605047C2 - Method for synchronisation of objects of personal information manager and external server - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: invention relates to data synchronisation. Objects describing workflow are stored in personal information manager Microsoft Outlook in form of Outlook objects. Two continuous processes check whether there are changes in Outlook objects and whether said changes are saved. MICROSOFT storage objects are used to store information on changed fields of Outlook objects in computer memory and fields of Outlook objects which were stored on hard disk. Information on changed and stored fields is sent on an external server. Notification on successful storage of fields on external server is then received. Information on changes to field on external server is received. Fields changed on external server are saved in Microsoft Outlook Objects.

EFFECT: technical result consists in providing data synchronisation between Miscrosoft Outlook and an external server with constant data update.

15 cl, 8 dwg

Description

The invention relates to data synchronization methods, and in particular, to a system and method for synchronizing specialized objects between MICROSOFT Outlook and similar email clients and an external server.

Microsoft Outlook has become the primary email application used by millions of users around the world. Microsoft Outlook allows you to effectively work with a large number of business objects (including specialized objects, which will be described below), such as mail, tasks, meetings, events, etc. However, Microsoft Outlook initially does not allow you to work with business objects behind which there is an expanded workflow (such as, for example, applications, projects, business processes, customer complaints, requests, etc.). These workflows are performed on an external server. Given the popularity of Microsoft Outlook as an email client, as well as the lack of built-in support for business objects based on workflows, it is desirable to be able to support working with business objects with a workflow from the Microsoft Outlook interface.

Thus, there is a technical need for a system and method for synchronizing data between Microsoft Outlook and an external server, where the data is stored in such a way as to allow constant updating.

The following is a detailed reference to preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

In the present description, Microsoft Outlook 2010 is used as an example, although the invention can be applied to any client email application (mail user agent (MUA)) that allows you to design a specialized interface and display relevant data such as a desktop application, which is used to work with e-mail and accessories, such as contacts, tasks, calendar, etc. You can also use a special email client to manage specialized Elements, if it supports, as stated above, the design of specialized forms and the display of our data in it. Microsoft Outlook 2010 is used as an example in the description, as it is one of the most popular email clients and meets the requirements. Lotus Notes is another example, although the invention is not limited to any particular email client.

Specialized Objects can be converted and saved in MICROSOFT Outlook as Outlook Elements. According to the example under consideration, special processes continuously check whether there are changes in the Outlook Elements and whether these changes are stored in the data store, for example, on the hard disk. MICROSOFT Storage Elements (112, FIG. 1) are used to store information about the fields of Outlook Elements that have been changed in RAM (142, FIG. 1) and about the fields of Outlook Elements that have been stored in the user data store (140, FIG. 1 ), such as a hard drive.

Information reflecting the changed and saved fields is sent to an external server. Subsequently, a notification arrives that the field was successfully saved on the external server. Also, information about the changed field on the external server is sent back. Fields that are modified on the external server are saved in Outlook Objects. Thus, two-way synchronization between Microsoft Outlook and an external server is achieved.

Thus, according to the considered example, in this invention, synchronization is realized through the Microsoft Outlook plug-in, developed using the MICROSOFT Office Utilities. Communication with an external server is carried out through the application programming interface (API). The API works as follows:

but. The MICROSOFT Outlook add-in forms a list of all objects stored in Microsoft Outlook. In addition, some objects contain additional information about editing a field or deleting an object, as shown below:

Object 1 Object 2 Object 3 Object 4 Object 5 Object 8 Object 9 Field 3: New Value Removed Field 3: New Value Field 9: New Value Field7: NewValue Field 6: New Value Field 9: New Value “Deleted” means that the object has been deleted. "Field #: NewValue" means that the Value of Field # in the relevant object has been changed to "NewValue".

b. After receiving the data, the external server applies the changes to objects stored on the external server. If a conflict occurs (for example, when the data on the external server is different from the data in MICROSOFT Outlook), the data on the external server does not change, and the error message is sent to the MICROSOFT Outlook Add-in. Data in MICROSOFT Outlook is restored to the previous one, since data on an external server is considered more correct than data in Microsoft Outlook, although the user can change this option through the settings.

at. An external server generates a response for sending to the MICROSOFT Outlook Add-in. All fields of all changed objects are sent, i.e. objects that were changed in MICROSOFT Outlook (as mentioned in the previous paragraph), and objects that were changed on an external server. A confirmation is also sent to the MICROSOFT Outlook Add-in on the application of changes to objects stored on an external server, i.e. confirmation of updating saved objects. Information about the time of the last successful synchronization is stored in the MICROSOFT Outlook Add-in. The external server also sends the following information to the MICROSOFT Outlook Add-in:

d. Comments and Attachments are synchronized as well as Objects, and two additional lists are formed:

i. For all comments added to all objects,

ii. For all attachments added to all objects.

In case of attaching a file in the MICROSOFT Outlook Extension, this attachment is downloaded directly to the external server and the link to this attachment is sent as the value of the "Attachment Link" field to the external server. When attaching a file on an external server, the link is also sent as the value of the Attach Link field to the MICROSOFT Outlook Extension and MICROSOFT Extension Outlook downloads the attached file and attaches it to the MICROSOFT Outlook Element. The keyword "Deleted" is also used to indicate that the attachment has been removed.

In FIG. 1 shows a method for synchronizing specialized objects between MICROSOFT Outlook and an external server. MICROSOFT Outlook 110 elements are standard MICROSOFT Outlook objects that are used to store all MICROSOFT Outlook entities (such as, for example, letters, contacts, tasks, schedules, appointments, etc.). MICROSOFT Outlook items are stored in RAM for permanent storage and have associated entries in the data store (for example, on a hard drive) of a computer system. At block 125, the process checks for changes to the MICROSOFT Outlook Items.

Block process 125 uses MICROSOFT Outlook events to log all changes made to the MICROSOFT Outlook Elements. Then, if changes were detected in block 130, then in block 145, the process writes them to the list of changed fields in RAM. The list of fields that have been changed in the MICROSOFT Outlook Elements is recorded in “Storage Elements Stored in RAM” 142, which are part of Storage Elements 112. It should be noted that only the list of changed fields is recorded (not the actual field values). A list of changed fields can be represented by an array. It is worth noting that the list of changed fields can be updated after each change in the Microsoft Outlook Element. A list of changed fields can be created for each Microsoft Outlook Item after the Item is open. It is worth noting that the list of changed fields can be cleared or deleted for the current Microsoft Outlook Element if the user or the system (for example, in case of a critical error) does not save the changes for this Element.

It is also worth noting that the list of changed fields is optional, since the changed fields can be written to “Storage Elements Stored in RAM” 142.

Storage Elements 112 are the standard MICROSOFT Outlook objects that are used to store information that cannot be stored in Outlook Elements. In an illustrative embodiment, Storage Elements 112 are used to store information about changed fields and stored fields (discussed below).

If no new changes were found in block 130, the process continues to check the Outlook Items for the Change Item in block 125. Then, in block 115, the process checks for the presence of the saved Outlook Items. Thus, if stored changes are detected in block 120, in block 135, the process writes information about the stored fields. According to an illustrative embodiment, this process uses MICROSOFT Outlook events to log changes saving events in Storage Elements 112.

The process records the fact that the fields were stored in the Storage Elements. In one embodiment of the invention, technically this means adding a Boolean type variable to an array of modified fields stored in the Storage Elements. In another embodiment of the invention, after the changes have been saved, “Storage Items Stored in RAM” 142 update “Storage Items Stored in Data Warehouse” 140 with the latest changes made since the last save. Thus, the last saved changes can be erased from the "Storage Elements stored in RAM" 142. If in block 120 the new saved changes were not registered, then in block 115 the process continues to check for saving events in the Outlook Elements. In block 150, the process checks for changes in the "Storage Elements stored in the data warehouse" 140. The process continuously checks the "Storage Elements stored in the data warehouse" 140 for information about new stored fields (which were marked as stored in block 135). In fact, in block 150, the synchronization process begins.

If new changed and saved fields are detected in block 155, in block 160, the process retrieves the actual values for the changed fields. The process reads the MICROSOFT Outlook Elements and retrieves the actual values for the fields that were identified as stored in block 155. For each field designated as saved, the updated field value is taken (the actual value that was obtained from the MICROSOFT Outlook Elements) and sent in block 165 to an external server. If in block 155 no new stored fields are detected, then in block 150 the process continues to check for new stored fields in the "Storage Elements stored in the data warehouse" 140.

In block 170, the process receives information about the updated and new fields, including values from an external server. In fact, new fields are fields that have been changed, for example, by another user from another email client or through an Internet browser. Also, these fields may differ from the updated fields obtained in step 160. Then, in block 185, the process updates the MICROSOFT Outlook Elements with new fields. At block 175, the process receives notifications of stored fields on the external server. This process is ensured by the work of a specialized IPP. Then, at block 180, the process updates the "Storage Elements Stored in the Data Warehouse" 140 with information reflecting the fact that the fields were successfully stored on the external server.

This means that records of both changed and saved fields have been deleted from the "Storage Elements stored in the data warehouse" 140.

In FIG. 2 shows a flowchart for generating a list of changed fields according to an illustrative embodiment. In block 210, the synchronization application checks to see if changes made to the Element are significant to the process. In the illustrative embodiment, significant changes are those that have been made in the Specialized Object, since the object is essentially synchronized. A specialized Object is an Object (a business object, a specialized object), behind which there is a certain flow of work and which is stored on an external server. Specialized Objects can be, for example: Complaints, Inquiries to support services, Vacation requests, Vacancies, Applicants, Employees, Travel expenses reports, Software errors, Functional offers, Insurance applications, Purchase orders, Medical reports, Replacement Requests, Balance Sheet Equipment, Balance Sheet Software, Test Scenario, Leave Requests, etc. If Specialized Objects are not normally supported by standard email clients, then Specialized Objects can be converted to Email client items. For example, data (data contained in specialized objects, such as the date the specialized object was created, the author of the specialized object, etc.) from an external server can be received and written to the Email Client Elements.

Further, if in block 220 changes were recorded in significant Elements, then in block 230 the system checks whether changes have been made to significant fields. If changes to significant fields are detected in block 240, then a list of changed fields is created in block 250. Thus, the list of changed fields ("Storage Elements Stored in RAM" 142) is updated with each changed significant field. If no changes are detected at block 220, then at block 260, the process ends.

In FIG. 3 shows a block diagram of generating a list of stored fields according to an illustrative embodiment. At block 310, the synchronization application checks if the Item that was saved is significant to the process. In the illustrative embodiment, conservation events that relate to the Specialized Object are significant because it is synchronized.

If saving events are detected in block 320 in significant MICROSOFT Outlook Elements, then in block 330, the synchronizing application verifies that the significant fields were saved. If significant fields are detected in block 340, a list of stored fields is created in block 350. The process of copying changed fields from "Storage Elements Stored in RAM" 142 to "Storage Elements Stored in Data Warehouse" 140 can be used for each saved field instead of creating a list of stored fields. If no changes are detected in blocks 320 and 340, the process ends in block 360.

In FIG. 4 shows the architecture of a system according to an illustrative embodiment. The change event listener component 410 is designed to track (monitor) events that show changes in Outlook 400 Items. The save event listener component 420 is used to track events that show the saving of Outlook 400 Items. The read / write component from Outlook 440 items is used to read information from Outlook 400 items to check if there have been changes, and to subsequently record updated fields received from an external server 460.

The read / write component from Storage Elements 450 is intended for recording information about changed fields and stored fields received from components 410 and 420, respectively. Next, component 450 reads information about both changed and stored fields from Storage Elements 455 to start the process of sending updated fields to an external server 460 via the data transfer / receive component 430. This component is used to send fields updated in Outlook Elements to an external server 460 and to receive updated fields from an external server 460.

In another illustrative embodiment, the synchronization application provides tight integration with MICROSOFT Outlook. The synchronizing application has the functionality of a task manager (manager of specialized objects), which works with tasks and specialized objects. However, the tasks described here are significantly more advanced than the standard tasks of MICROSOFT Outlook. In particular, these tasks have the following additional functionalities:

1. Discussion with a hierarchy of comments submitted by users;

2. A story with a list of all the changes that the task has undergone;

3. Time log (time spent), ie estimated time spent on the task;

4. Unlimited number of subtasks; and

5. Structured links to other Specialized Objects in the system. Specialized Objects can be interconnected with each other using hyperlinks. This allows flexible data modeling.

An illustrative option allows users using MICROSOFT Outlook to continue to work in their familiar environment. In other words, the task manager is integrated into the Microsoft Outlook interface using the Outlook development tools. Therefore, advanced tasks are used in Microsoft Outlook. New tasks are tasks similar to typical Microsoft Outlook tasks, but they have more functionality. Users can create integrated specialized tasks, edit them, assign tasks, etc. Information is transmitted to an external server (that is, to an external server synchronized with Microsoft Outlook).

For example, advanced tasks may include a discussion with a hierarchy of comments submitted by users. Unlike MICROSOFT Outlook's own tasks, advanced tasks have comments associated with them. Comments have a hierarchical structure so that users can post new comments or respond to other comments. Users can edit the comments they sent. This functionality provides the possibility of real-time discussion within a specific task while maintaining context, which makes this task more convenient for collaboration purposes.

Advanced tasks can also have their own change history with a list of all changes made to the task. Each change made in the task can be viewed in the history in a convenient form. Thus, the user can analyze the history of all changes that have ever been made in the task. This helps resolve contentious issues or accurately recover from inadvertently deleted data.

Advanced tasks may also have a time log (time spent) reflecting the total time spent on the task. The user can see the amount of time spent on tasks in a special table. Then combined reports on elapsed time for specific tasks can be prepared. This information is useful for billing and cost analysis purposes.

Advanced tasks can also have an unlimited number of subtasks. Using subtasks, the user can divide the work into several smaller parts and give each part to a specific employee. Since the hierarchy of subtasks is unlimited, the user can manage quite complex projects only through advanced tasks. A list of all subtasks with the statuses and names of those to whom they are assigned can be found in the primary task.

Advanced tasks can also have structured links to other specialized objects in the system. Elements can be linked to each other for navigation, statistics, and quick contextual navigation. The user can set a link from the task to any Element stored on the server, and then move quickly using this link. Information about related tasks can also be viewed in the corresponding Elements.

A typical appearance of integrated tasks is illustrated in Figures 5-7. In FIG. 5 shows one embodiment of a screenshot of a discussion interface screen (user comments) according to an illustrative embodiment. In FIG. 6 shows one embodiment of a snapshot of a history interface screen according to an illustrative embodiment. In FIG. 7 shows one embodiment of a screenshot of a subtasks interface according to an illustrative embodiment.

The specialist will take into account that the proposed method and system provide effective two-way synchronization between MICROSOFT Outlook and an external server.

Two-way synchronization is necessary so that the user can also work with specialized objects in other interfaces, implemented as additional program modules for other applications (i.e., MICROSOFT Visual Studio). The external server also provides its own web interface through which the user can work with specialized objects.

With reference to FIG. 8, a typical system for implementing the invention includes a multi-purpose computing device in the form of a computer 20 or a server including a processor 21, a system memory 22, a system bus 23 that couples various system components, including the system memory to the processor 21.

The system bus 23 may be any of various types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. System memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. The ROM 24 stores the basic input / output system 26 (BIOS), consisting of basic programs that help exchange information between parts inside the computer 20, for example, at the time of launch.

Computer 20 may also include a hard disk drive (HDD) 27, a hard disk drive (HDD) 28 for reading and writing information from / to a flexible magnetic disk 29 and an optical drive 30 (e.g., a CD drive, a DVD drive , BD drive, GD drive and the like) for reading / writing information from / to the optical disk 31. The HDD 27, the HDD 28 and the optical drive 30 are connected to the system bus 23 via the HDD 32 interface, the HDD interface 33 and the optical drive interface 34 respectively. HDD 27, HDD 28 and the optical drive 30 and their corresponding drives provide non-volatile storage of data, such as machine-readable instructions, data structures, program modules and other data of the computer 20.

It is also worth noting that the devices for storing information described above are not limited to the listed devices, since instead of them any types of devices designed for storing information can be used, such as flash memory, magnetic tapes and films, digital video disks, Bernoulli cartridges.

Various software modules can be stored on the HDD 27, ROM 24, RAM 25, HDD 28 and optical drives 30, including the operating system 35. Computer 20 includes a file system 36 connected to or included in the operating system 35, one or more applications / programs 37, other program modules 38 and program data 39. A user can enter commands and information into a computer 20 using input devices such as a keyboard 40 and a mouse 42. Other input devices (not shown here) may include a microphone, joystick, satellite -hand dish, scanner, or any other.

These and other input devices quite often work with the processor 21 through the serial port 46 interface connected to the system bus, however, they can also work with the processor through other interfaces, such as a parallel port, a game port, or a universal serial bus. A monitor 47 or any other type of display is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor 47, other peripheral information output devices (not shown), such as speakers and printers, are usually connected to personal computers.

Computer 20 may operate in a networked environment through logical connections / connections to one or more remote computers 49. The remote computer (or computers) 49 may be another computer, server, router, or shared network nodes, and typically also includes many devices and elements, which were described above for the computer 20, although only the information storage device 50 is indicated in the drawing. Logical connections / connections include a local area network (LAN) 51 and a global computer network (GKN) 52. Which networking environments are usually distributed in companies, enterprise-wide computer networks, intranets (Intranet) and the Internet.

Computer 20, used in a network environment of a local area network, is connected to a local area network (LAN) 51 through a network interface or adapter 53. When used in a networked environment, computer 20 typically uses a modem 54 or other means to establish communication with the public network 52, for example, The internet.

The modem 54 can be internal or external and is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules or parts of them executed by computer 20 can be stored on a remote information storage device. This example shows an example of network connections, but any other type of connection can be used to connect the computer to other computers.

Claims (15)

1. The system implemented in the computer for synchronizing objects describing the workflow between the email client and the external server, the system comprising:
many objects describing the workflow stored on the external server, and elements of the email client;
change event monitoring module for detecting changes in email client elements;
save event monitoring module for detecting saves in email client items;
a module for reading / writing from email client items to read fields from email client items and to write updated fields of email client items received from an external server,
a plurality of storage elements for storing information about changed fields and stored fields;
a module for reading / writing from storage elements for reading data from storage elements and for writing data reflecting changed fields and stored fields to storage elements; and
a component for receiving / transmitting data for sending and receiving data to / from an external server,
where the data stored in the storage elements is received from the change event monitoring module and from the save event monitoring module, and
where data stored in email client items is read / written based on storage items. 2. The system of claim 1, wherein the objects describing the workflow are not normally supported by a standard email client. 3. The system of claim 1, wherein the objects describing the workflow are converted to email client elements. 4. The system of claim 1, wherein the email client is MICROSOFT Outlook, Lotus Notes. 5. The system of claim 1, wherein the elements of the email client are any of:
Email messages
contacts;
tasks;
meeting and
Events. 6. The system of claim 1, further comprising a manager of objects describing the workflow embedded in the email client for managing non-standard extended objects describing the work flow that are not normally supported by the email client. 7. The system according to claim 6, where the extended objects that describe the workflow include any of:
discussion with a hierarchy of comments submitted by users;
a history with a list of all changes made on an object that describes the workflow;
a time log reflecting the total time spent on an object describing the work flow;
unlimited number of subtasks; and
structured links to other objects describing the work flow in the system. 8. A method for synchronizing objects describing a workflow, implemented in a computer, between an email client and an external server, comprising the steps of:
(a) checking for changes in the elements of the email client;
(b) a record of the list of modified fields of the email client elements, if changes are detected;
(c) checking save events in email client items;
(d) writing a list of changed fields to storage items;
(e) checking changes to storage items;
(f) obtaining the actual field values from the elements of the email client, if changes are detected;
(g) sending the actual field values to an external server;
(h) receiving update notifications from an external server;
(i) updating storage items;
(k) receiving fields updated on the external server and new fields from the external server;
(k) updating the email client items with the received fields; and
(m) repeating steps (a) - (m). 9. The method according to claim 8, where the elements of the email client include objects that describe the workflow that are not normally supported by the standard email client. 10. The method of claim 8, further comprising checking whether changes have been made to the element that is significant to the process. 11. The method according to claim 8, where the list of changed fields of the elements of the email client consists of significant changed fields. 12. The method of claim 8, further comprising checking whether changes are saved to the process-relevant element. 13. The method according to claim 8, further comprising integrating a manager of objects describing the work flow into an email client for managing non-standard extended objects describing the work flow. 14. The method according to p. 13, where the extended objects that describe the workflow are any of:
discussion with a hierarchy of comments submitted by users;
a history with a list of all changes made to objects describing the work flow;
a time log reflecting the total time spent on an object describing the work flow;
unlimited number of subtasks; and
structured references to other entities in the system. 15. A system for synchronizing objects describing the workflow between an email client and an external server, a system including:
CPU;
memory associated with the processor;
a computer logic program stored in memory and executed by the processor to perform the steps described in paragraph 8.

Images