RU2419849C2 - Mechanism for synchronising set of applications for efficient work and business applications - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: synchronisation method is adapted to provide synchronisation between the application of a set of program applications for efficient work and a business application such as an application for managing interaction with clients. Requests are sent from the application of the set of program applications for efficient work in a business application by accessing a web service in order to update, delete or create a new object in that application. The business application extracts each request from the received web service accesses. The request may be provided in form of a XML data. Requests are sent to the application of the set of program applications for efficient work by sending messages which are embedded in an e-mail message in order to update, delete or create an element in the application of the set of program applications for efficient work. The element is associated with the object of the business application. Control messages are hidden from the user and are extracted from the e-mail message for assessing, resolving conflicts, advancing to a higher level of properties and binding between the object of the business application and the application element of the set of program applications for efficient work.

EFFECT: high rate of synchronising applications.

20 cl, 13 dwg

Description

State of the art

A number of software application kits are available for users, which include applications for creating an event calendar, saving contact information, email support, saving task information, etc. One example is Microsoft Outlook® offered by Microsoft Corporation, Redmond, Wash. Microsoft Outlook® is part of the Microsoft Office® software suite. Many users are familiar with such software bundle applications and use them on a regular basis.

Some users of productive software suites also use commercial applications or systems designed for specific business applications (also referred to as business systems or LOB systems in this document). One example is customer relationship management (CRM) systems offered by a number of companies. Most of the information that is managed through LOB systems can include managing contacts, creating a calendar of events and tasks, among other things.

In many cases, a set of software applications for productive work cannot exchange or synchronize their information with the LOB system automatically. For example, if a user adds a business task to a set of software applications for productive user work, task information is not automatically transferred to the LOB system. Instead, this information is detected by the user in each different system. Typically, users need to enter task information a second time into the LOB system. Some users may want to provide the ability to store LOB information in email systems and synchronize with LOB information in database systems.

SUMMARY OF THE INVENTION

In accordance with various aspects of the disclosed embodiments, the synchronization method is configured to allow synchronization between a client machine, which includes a software application suite for productive work, and a server machine, which includes a business application (LOB). An application for a software product suite for productive work can be a personal information system (PIM) application, such as Outlook® (offered by Microsoft Corporation, Redmond, Washington), or some other application, such as Lotus Notes, Star Office, etc. Examples of productive application suite software applications include email management, appointment management, scheduling / calendar management, note management, task management, contact management, etc. Synchronization can be processed between data elements in a software application suite for productive work and objects in a LOB application by using representations of XML data and stored binding information.

In one particular implementation, the information that is used for synchronization is stored as XML data. The representation of XML data can be stored as a property of a data element in a software suite application for productive work. The representation of XML data can be transferred to the LOB application, which can then operate with its own conflict resolution and data storage for LOB objects. The change to LOB application objects can then be provided as XML, which can then be formatted into a control message, which is transmitted to the software suite application for productive work. Representations of XML data provide a consistent interface that is simply managed through each respective application.

In another aspect, user-based information encryption is performed. This aspect can advantageously help to ensure that the information contained in any PIM element that is sent to the email recipient cannot be read by this recipient and thus cannot be inadvertently shared. In a related aspect, encryption helps to prevent an unexpected mode of operation of information on the recipient side. For example, in some conventional systems, the information contained in appointment appointments can easily be shared by sending an invitation to a meeting. Thus, the user can share information without even knowing about it. Information encryption prevents this unintentional sharing of information. However, if the user has several devices, the described encryption does not prevent the sharing of information on multiple user devices.

In another aspect, information is stored in a personal property, reducing the possibility of rewriting. In some traditional systems, information may be implicitly exchanged with an invited party in a meeting request without the knowledge of the requester. When the requesting and invited parties share information by sending information explicitly or implicitly, it is likely that the information will be stored in one property. Since the last stored information is supported, information from one of the users can be overwritten. In one aspect of the present application, a specific property name is assigned in order to retain additional information so that conflicts are avoided.

In another aspect, information can be moved to a higher level and to a lower level, so that information elements or attributes (that is, which are in XML) could not be replicated (duplicated) to properties in the contained PIM elements. For example, in one implementation, the standard Microsoft Outlook® UI can be used to display or process these values and / or values that can be shared with other users. In one aspect of the present application, the presentation of XML data is provided to the LOB application so that the LOB elements can only be modified by the LOB application. In another aspect, the LOB element is formatted as XML data, which is then used to synchronize the product suite of software applications for productive work. Since XML can be used as a mechanism for transferring information, simplified user interfaces can be implemented for application of a set of software applications for productive work.

In another aspect, dialogs are mutually synchronized between a suite of software applications for productive work and a LOB application. Dialogs can be developed in any appropriate language, such as, for example, Extensible Application Markup Language (XAML). Synchronization between dialogs predominantly allows several dialogs showing the same element to be open at the same time. When the user enters information in one dialogue, the information automatically changes in all other places where it is displayed. For example, in a Microsoft Outlook® implementation, when one information is displayed in the Microsoft Outlook® dialog (Inspector) and in the taskbar or action bar, it should be synchronized. This aspect provides mechanisms that allow multiple dialogs in Microsoft Outlook® to share a single instance of data (while in the editing process).

In yet another aspect, a software application suite for productive work in a client machine is configured to send requests by accessing a web server to update, delete, or create a new object in a LOB application. The LOB application retrieves the request from the client machine, and the request can be provided as XML data. The server machine sends requests through control messages that are attached to e-mail in order to update, delete, or create an element in the application of the software application suite for productive work, while the element is associated with the LOB object. Control messages are hidden from the user and are retrieved by the client machine to evaluate, resolve conflicts, move to a higher level of properties and link between the LOB object and the application element of the software application suite for productive work.

In a further aspect, an application may transmit a LOB identifier in a mail message, wherein the LOB identifier is associated with a preceding binding between an element of the software application suite for productive work and the LOB object. The LOB identifier may be embedded in the mail message in the header associated with the mail message. The mail message does not have to contain (nested or otherwise) the LOB object itself, since the LOB identifier refers to the LOB object. After the email message is received, the email descriptor for the productive software suite can identify a particular element of the software suite for productive work in the shadow of synchronization or the synchronization data store that accesses the LOB identifier. In one example, a user can access an element of a software application suite for productive work by selecting a link (for example, URL links in any number of forms, for example, HTTP, HTTPS, FTP, FTPS, OBA, etc.) and another embedded information (for example, a representation of XML data or another representation of data) that is associated with a LOB identifier in an email message. In another example, an action bar or task bar can be activated to access a specific element of a software application suite for productive work. Since the LOB identifier can be embedded in a link, any required action associated with an element of the software application suite for productive work can be carried out by configuring the descriptor (for example, the URL descriptor) accordingly.

Brief Description of the Drawings

Non-limiting and non-exhaustive embodiments are described with reference to the following drawings, in which like reference numerals refer to like elements in different representations, unless otherwise indicated.

Figure 1 is a block diagram representing a general computing environment that can be used to implement the techniques described herein according to an embodiment.

Figure 2 illustrates an example system in which a client device is configured to synchronize with the LOB system.

FIG. 3 illustrates how a correlation is established between an anchor element and a LOB object when a new link element is created by the LOB system.

FIG. 4 illustrates how a correlation is established between a bindable element and a LOB object when a new bindable element is created through a suite of software applications for productive work.

FIG. 5 illustrates how the correlation between a bindable element and a LOB object changes when a bindable element is updated or deleted in a software application suite for productive work.

6 illustrates how the correlation between the linked element and the LOB object changes when the linked element is updated or deleted by the LOB system.

7 illustrates an example flow of information between a client and a server during a stack operation.

8 and 9 illustrate an extraction operation that may be used in another exemplary system.

10 illustrates an exemplary structure of a synchronization subsystem for a software application suite that is used on a client machine.

11 illustrates another flow of information between a client and a server.

12 illustrates an example synchronization subsystem.

13 is a flowchart of an example synchronization method.

DETAILED DESCRIPTION OF THE INVENTION

Various embodiments are described in more detail below with reference to the accompanying drawings, which form part of them and which illustrate specific exemplary embodiments for practical use of various embodiments. However, other embodiments may be implemented in many different forms and should not be construed as limiting to the embodiments set forth herein; on the contrary, these options for implementation are provided so that this entity is comprehensive and complete. Embodiments may be used in practice as methods, systems or devices. Accordingly, embodiments may take the form of a hardware implementation, a fully software implementation, or an implementation combining software and hardware aspects. The following detailed description, therefore, should not be construed in a limiting sense.

In short, the synchronization method is configured to provide synchronization between a client machine, which includes a software application suite for productive work, and a server machine, which includes a business application (LOB), such as a customer relationship management application, or CRM . The client machine sends requests by accessing the web server in order to update, delete, or create a new object in the LOB application. The LOB application retrieves the request that is received from the client machine, and the request can be provided in the form of XML data. The server machine sends requests by means of control messages that are embedded in e-mail to update, delete, or create an element in the application of a set of software applications for productive work, while this element is associated with the LOB object. Control messages are hidden from the user and are retrieved by the client machine to evaluate, resolve conflicts, move to a higher level of properties and link between the LOB object and the application element of the software application suite for productive work.

Logical operations of various embodiments are implemented (1) as a sequence of computer-implemented steps performed in a computer system, and / or (2) as interconnected machine modules within a computer system. The implementation is a matter of choice depending on the performance requirements of the computing system implementing the embodiment. Therefore, the logical operations constituting the embodiments described herein are referred to alternatively as operations, steps, or modules.

Various modules, technologies, and methods may be described herein in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Typically, program modules include procedures, programs, objects, components, data structures, etc. to perform specific tasks or implement specific abstract data types. In a typical embodiment, the functionality of the software modules may be combined or distributed as required in various embodiments.

The implementation of such modules and technologies may be stored or transmitted in some form of computer-readable medium. A computer-readable medium may be any available medium that can be accessed by a computer. By way of example, but not limitation, computer-readable media may include “computer storage media” and “media”.

A "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as machine-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other technology, CD-ROM, digital multifunction disks (DVD) or other optical media, magnetic tapes, magnetic tape, magnetic disk media or other magnetic storage devices, or any other medium that can be used to store the desired information and which can be accessed using a computer.

A "data medium" typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier signal or other transmission mechanism. The transmission medium also includes any information delivery medium. The term "modulated information signal" means a signal that has one or more of the characteristics set or changed so as to encode information in the signal. By way of non-limiting example, a communication medium includes a wired medium, such as a wired network or a direct wired connection, and a wireless medium, such as an acoustic, RF (radio frequency, RF), infrared, and other wireless medium. Combinations of any of the above should also be included in the number of computer-readable media.

This detailed description refers to “one embodiment”, “embodiment” or “exemplary embodiment”, which means that the particular feature, structure or characteristic described is included in at least one embodiment. Thus, the use of such phrases may refer to more than just one embodiment. In addition, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

However, those skilled in the art may recognize that the embodiments may be practiced without one or more specific details or with other methods, resources, materials, etc. In other instances, widespread structures, resources, or operations are not shown or described in detail simply in order to avoid difficulties in understanding aspects of the embodiments.

Sample computing environment

Figure 1 illustrates a general computing environment 100 that can be used to implement the techniques described herein. Computing environment 100 is just one example of a computing environment and does not intend to suggest any limitation as to the amount of use or functionality of the computing and network architectures. Computing environment 100 should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in exemplary computing environment 100.

Computing environment 100 includes a general-purpose computing device in the form of a computer 102. Components of a computer 102 may include, but are not limited to, one or more processors or processing devices 104, a system memory 106, and a system bus 108 that couples various system components including a processor 104, with system memory 106.

The system bus 108 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. As an example, such an architecture may include an industry standard architecture bus (ISA), microchannel architecture bus (MCA), an extended architecture ISA bus (EISA), a local video standardization association (VESA) bus, a peripheral component interconnect (PCI) bus ), also known as the "mezzanine bus," the PCI Express bus, the universal serial bus (USB), the Secure Digital (SD) bus, or the IEEE 1394 bus, i.e. Firewire

Computer 102 may include a variety of computer-readable media. Such media may be any available media that is accessible through computer 102 and includes both volatile and non-volatile media, removable and non-removable media.

System memory 106 may include computer-readable media in the form of volatile memory, such as random access memory (RAM); and / or non-volatile memory, for example, read-only memory (ROM) or flash RAM. A basic input / output system (BIOS) 114 comprising basic procedures that help transfer information between elements within a computer 102, for example, during startup, is typically stored in ROM 112 or flash RAM. RAM 110 typically comprises data and / or program modules that are directly accessible and / or, in fact, are driven by a processor 104.

Computer 102 may also include other removable / non-removable, volatile / non-volatile computer storage media. As an example, FIG. 1 illustrates a hard disk drive 116 for reading and writing to a stationary non-volatile magnetic medium (not shown), a magnetic disk drive 118 for reading or writing to a removable non-volatile magnetic disk 120 (for example, a flexible disk) and a drive 122 on optical disks for reading and / or writing to a removable non-volatile optical disk 124, such as a CD-ROM, DVD-ROM, or other optical medium. The hard disk drive 116, the magnetic disk drive 118, and the optical disk drive 122 are each connected to the system bus 108 by one or more storage media interfaces 125. Alternatively, the hard disk drive 116, the magnetic disk drive 118, and the optical disk drive 122 may be connected to the system bus 108 by one or more other interfaces (not shown).

Disk drives and their associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for computer 102. Although the example illustrates hard disk 116, removable magnetic disk 120, and removable optical disk 124, it should be understood that others types of computer-readable media that can store data that is accessible by computer, for example, magnetic tapes or other magnetic storage devices, flash memory cards, CD-ROMs, numbers Newer multi-function discs (DVDs) or other optical storage media, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM) and the like can also be used to implement an example computing system and environment.

Any number of program modules may be stored on hard disk 116, magnetic disk 120, optical disk 124, ROM 112 and / or RAM 110, including, by way of example, operating system 126, one or more application programs 128, other program modules 130 and program data 132. Each of such an operating system 126, one or more application programs 128, other program modules 130 and program data 132 (or some combination thereof) may implement all or part of the resident components that support distributed file the system.

The user can enter commands and information into the computer 102 through input devices such as a keyboard 134 and pointing devices 136 (for example, a "mouse"). Other input devices 138 (not shown specifically) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, and / or the like. These and other input devices are connected to the processing device 104 via the input / output interfaces 140, which are connected to the system bus 108, but can be connected to another interface and bus structures, such as a parallel port, a game port, or a universal serial bus (USB).

A monitor 142 or other type of display device may also be connected to the system bus 108 via an interface, such as a video adapter 144. In addition to the monitor 142, other peripheral output devices may include components such as speakers (not shown) and a printer 146, which can be connected to computer 102 via input / output interfaces 140.

Computer 102 may operate in a networked environment using logical connections to one or more remote computers, such as remote computing device 148. As an example, remote computing device 148 may be a personal computer, laptop computer, server, router, network computer, peer device, or another common network node, etc. Remote computing device 148 is illustrated as a portable computer, which may include many or all of the elements and features described herein that correspond to computer 102. Alternatively, computer 102 may operate in a non-networked environment.

The logical connections between computer 102 and remote computer 148 are depicted as a local area network (LAN) 150 and a common wide area network (WAN) 152. Such network environments are common in offices, corporate networks, the intranet, and the Internet.

When used in a LAN environment, the computer 102 is connected to the local area network 150 via a network interface or adapter 154. When used in a WAN network environment, the computer 102 typically includes a modem 156 or other means for establishing communication over a wide area network 152. Modem 156, which may be internal or external to the computer 102, may be connected to the system bus 108 via input / output interfaces or other suitable mechanisms. It should be appreciated that the illustrated network connections are exemplary, and that other means of establishing at least one communication link between computers 102 and 148 can be applied.

In a networked environment, such as illustrated with computing environment 100, program modules depicted with respect to computer 102, or portions thereof, may be stored on a remote storage device. As an example, the remote application programs 158 are located in the storage device of the remote computer 148. For purposes of illustration, application programs and other executable program components, such as an operating system, are illustrated as separate blocks in this document, although it is recognized that such programs and components are in different time points in different storage components of computing device 102 and are executed by at least one computer data processor.

The following is a description of sample interfaces and configurations implemented in Microsoft Outlook® in order to maintain synchronization of Microsoft Outlook® information with the LOB system. In other embodiments, other productivity suite applications may be used in place of or in addition to Microsoft Outlook®.

Sample configuration

Figure 2 illustrates an example system in which a client device is configured to synchronize with the LOB system. As shown in the drawing, a suite of software applications for productive work (220), such as Microsoft Outlook®, is available on the client device. Microsoft Outlook® contains one or more items, such as: calendar appointments for appointments, contacts, email, etc. Each element (230) of a set of software applications for productive work includes a set of standard properties (231) that relate to a set of software applications for productive work, and one or more data elements (LOB data 232) that are associated with the LOB system . Additional system properties are also associated with the element, as, for example, it may be necessary to associate data and properties with the element (for example, binding information in the system property 233). Outside of element (240), there is a set of system properties that are associated with synchronization (242), as well as a data store that is used to cache synchronization data (241).

One user should be able to install client software on multiple machines. However, only the primary machine has the ability to synchronize with the LOB system. Other machines are considered secondary machines. The LOB system returns a business response synchronously with the primary machine. The LOB system interacts with the formatter to provide “commands” to the primary machine, for example, create, update, or delete commands that originate from the LOB system. There can only be one primary machine at any time. Secondary machines (for example, client 260), which include their own copy of a suite of software applications for productive work (270), still contain a copy of the information available on the primary machine, including the business status and synchronization status of the connected items (for example element 280 for productive work, including properties 281-283). The described system can be configured to store a synchronization cache on a server in order to distribute business status responses from the server to secondary clients.

Elements of a set of software applications for productive work (for example, element 230) must contain enough information for the system to recognize and reproduce the attached elements. LOB data (including properties moved to a higher level) must be stored and associatively associated with an element of the software application suite for productive work. System information stored in the elements of a set of software applications for productive work should be static. In other words, it should not be changed after it is set in order to avoid the appearance of “artificial” synchronization conflicts. The system must save synchronization data and system properties associated with synchronization outside the elements of a set of software applications for productive work. A marker that is hidden in a property can be used to indicate which machine is primary. In some cases, the token may be transmitted so that the primary machine can be changed, for example, in the event of a recovery after a failure.

Figure 3 illustrates how a correlation is established between an anchor element (330) and an LOB object (370) when a new anchor element is created by the LOB system. First, the LOB object (370) is created in the LOB system (360), as indicated by step 1 (391), wherein the LOB object (370) includes an identifier (LOBID 372). The LOB system (360) transmits the request (392) to the server (340) to create the LOB object identified by LOBID 372 as a binding element, as indicated by step 2. The server (340) receives the request (392) and applies formatting means (250) for the request (392), leading to the transfer of the command (394) to the primary client (310) to create a binding. The synchronization subsystem (320) for a set of software applications for productive work (for example, Outlook) on the server (310) receives the command (392) during the next synchronization and creates a binding to the Outlook element (350), as indicated by step 5. The attached element has a unique identifier (UID 332), which is assigned to it, and associatively associates with the LOB object via LOBID 334.

Figure 4 illustrates how a correlation is established between an anchor element and a LOB object when a new anchor element is created through a suite of software applications for productive work. First, the element (430) is created in a set of software applications for productive work, as indicated by step 1 (491). Then, the synchronization subsystem (420) in the set of software applications for productive work (for example, Outlook) transmits (492) the binding command to the LOB system (460), as indicated by step 2. The LOB system (460) receives the creation command binding during the next synchronization with the client and creates a LOB object (470), identified by LOBID 472, as illustrated, by step 3 (493). The LOB system (460) optionally passes the LOBID (472) back to the client (410) in step 4 (494), and the client (410) can then associate the LOBID (434) with the binding element (430), as illustrated by step 5 (495). In some cases, LOBID (472) is not transferred back to the software application suite for productive work.

FIG. 5 illustrates how the correlation between a snap element and a LOB object changes when the tie element is updated or deleted in a software application suite for productive work. First, the element (530) is changed in the set of software applications for productive work, as indicated by step 1 (591). Next, the synchronization subsystem (520) in a set of software applications for productive work (for example, Outlook) transmits (for example, by accessing a web service), update or delete to the LOB system (560), as indicated by means of step 2 ( 592). The LOB system (560) receives the update / remove binding command during the next synchronization with the client (510) and modifies or deletes the LOB object (570) identified by LOBID 572, as illustrated by step 3 (593). In some cases, when the LOBID (534) is unknown through a suite of software applications for productive work, the LOB system (560) refers to the BIID binding identifier 532 to determine which LOB object (570) to modify or delete.

FIG. 6 illustrates how the correlation between the anchor element and the LOB object changes when the anchor element is updated or deleted by the LOB system. First, the LOB object (670) is modified or deleted in the LOB system (660), as indicated by step 1 (691). The LOB system (660) sends the request (692) to the server (640) to update or delete the LOB object identified by at least one of the LOBID (672) and the BIID in the request (692) to the server (640) . The server (640) receives the request (692) and applies the formatting tool (650) to the request (692), leading to the transmission of a command or control message (694) to change or remove the anchor element, as indicated by step 4. Subsystem (620) ) synchronization of a set of software applications for productive work (for example, Outlook) on the primary client (610) takes a command during the next synchronization and modifies or removes the binding (for example, BIID 532 and LOBID 634) with the corresponding binding element (630), as indicated by step 5 (695).

The synchronization subsystem described above is deployed on client machines, which can be on or off the corporate network. A virtual private network or VPN connection to the corporate network is expected, as well as HTTP-type remote synchronization connections, through a server application such as Microsoft Exchange Server. LOB synchronization can be performed as a background subprocess on a client device while a set of software applications for productive work is running. Changes made in the set of software applications for productive work are provided to the LOB system through any available RPC mechanism (for example, corporate network, VPN, HTTP, etc.), while changes to the LOB system are expected performed only on the corporate network. File synchronization can be processed in any appropriate way on the corporate network, for example, through Microsoft Active Directory, which can be configured to provide. NET API for these purposes.

Sample definitions of synchronization interfaces

For each type of element to be bound, the synchronization subsystem performs a different action depending on the change that occurs (create / update / delete). In addition, the action "Query" can be activated as a result of processing the control message of the request. Below is the information that must be transmitted and returned from each of these actions.

Create is invoked by the system each time the client-side creation of the Bound Item is processed. Options for Create include BoundItemID, NewItemData, and CultureName. The return values for Create include LOBID, BusinessStatus, and Description. BoundItemID is the client-generated string of a unique identifier for the item to be bound. NewItemData is an XML document that is defined by a schema for the LOB system so that the LOB data for the bound element is provided properly. CultureName is the name of the culture that should be used for the business status, description, and all other messages retrieved from the Create call. A LOBID is a string that is formed by LOB as a unique identifier for an item type (for example, ContactID uniquely identifies a contact). BusinessStatus is a string that corresponds to the short name of the new business state that should be assigned to the element to be bound as a result of Create. This is an arbitrary value provided through the LOB system; synchronization does not make any assumptions about the contents of this value. The idea is that this value can be used to filter elements that are in the same state. Description is an optional line that is an explanation of BusinessStatus. It is part of the information of the binding elements, so that, if necessary, Description can be provided in the UI.

Update is called by the system every time a client-side binding update is processed. Update options include BoundItemID, RequestID, LOBID, PreviousItemData, NewItemData, and CultureName. Return values for Update include BusinessStatus and Description. RequestID is a unique identifier for the update message to enable the LOB system to identify copies. The same request identifier should be sent if a duplicate update message is sent. PreviousItemData is an XML document that matches all the LOB data from the bound element from the last synchronized state.

Delete is called by the system every time a client-side binding update is processed. Options for Delete include BoundItemID, LOBID, PreviousItemData, and CultureName. Return values for Delete include BusinessStatus and Description.

QueryResult is called by the system every time a request control message is processed. The QueryResult parameter is an XML document that contains a list of identifiers for objects to be bound and their corresponding LOBID for all existing objects to be bound of the specified type. There are no return values for QueryResult.

Sample definitions of control messages

This section indicates the information that is expected in each type of control message. Control messages include: Create Control Message, Update Control Message, Delete Control Message, and Query Control Message.

The Create Control Message includes fields for: BoundItemID, LOBID, BoundItemType, and LOBData. Update Control Message includes fields for: LOBID, BoundItemType and LOBData. Delete Control Message includes fields for: LOBID and BoundItemType. Query Control Message includes a field for BoundItemType.

BoundItemID is a unique identifier assigned to a new binding element. BoundItemID is generated by the formatter, as described in more detail below. BoundItemType is a string that matches the fully qualified type name of the element to be bound, including the solution and version. BoundItemType can be used by the system to find an appropriate definition of a binding element that describes the properties that should be bound to an element of a software application suite for productive work, as well as how an element of a software application suite for productive work should be synchronized with LOB- object. As previously described, the LOBID is a unique identifier assigned by the LOB system to the attached element, and the LOB data is an XML document containing all the LOB data for the attached element.

Sample synchronization system

The system can be arranged so that it is not based on events from a set of software applications for productive work (for example, Microsoft Outlook) in order to activate and detect synchronization. To detect changes (create / update / delete), the system uses a 3-way synchronization approach between a set of software applications for productive work, a synchronization data storage (SDS) and information obtained directly from the LOB system. Data can be changed from several input points in the system. Information can be changed in many different places, including web access points, mobile devices and other client machines. Changes are ultimately synchronized with the primary client machine (for example, through Outlook / Exchange synchronization).

The LOB system can detect and process duplicate requests based on a unique request identifier. Outgoing (client-server) communication with the LOB system can be carried out through web services, while incoming (server-client) messages are provided to clients through a server application (for example, Microsoft Exchange).

Conflict detection is also handled by the system when one binding element is changed through the LOB system and a set of software applications for productive work. If the system detects that one of the items to be bound is updated by the user and the LOB system, a conflict is identified, and conflict resolution resolves it accordingly.

The LOB system supports the provision of immediate business responses when a synchronous call to the web service is accepted. The LOB system does not need to accept acknowledgment or error messages about the success of processing Create, Update, Delete, or Query commands.

This section describes the high-level information flows between the LOB system and the client. The following diagrams provide an overview of the possible flows of information that are supported.

7 illustrates an example flow of information between a client and a server during a push (write) operation. A push operation may be initiated by a client (710) or a server (750) as described.

Step 1 illustrates a client-initiated (710) stream in which a change detection process is performed by the system on the client. In step 1, the synchronization logic (730) in the system identifies new, updated, and deleted anchor elements and creates (791) a virtual list of change requests that must be submitted to the LOB system. A virtual list can be provided in a queue, such as a virtual outbound queue (VOQ 712). The list is processed when there is a connection (connectivity) (for example, 792 accessing a web service) to the LOB system (for example, server 750), in step 2. If the connection to the LOB system is not identified in step 2, then the list repeated the next time the change detection process is running

When creating a virtual request list, the system also takes into account new incoming control messages (notifications of creation, updates, deletions coming from the LOB system, from the list of 714 control messages) in order to detect and resolve or cause conflicts accordingly. The conflict is detected by the synchronization logic (730) when one element is modified in a set of software applications for productive work and in the LOB system, or when one side tries to update the element while the other tries to delete it. For each detected change (creation, update, deletion) that does not lead to conflict, the system provides a request to the LOB system (for example, server 750) by accessing the web service (792), as, for example, described in the definitions synchronization interface.

The LOB system (for example, a server 750 with the LOB application 760) can also initiate a create, update, delete, or query action on the client (710) when appropriate actions are performed on the LOB system. At step 3, the LOB system accesses the web service (793), which is provided by the formatting tool (770). In the case of creation requests, the formatter (770) returns a unique identifier that is used by the system to identify the new binding element. For details of the information sent as part of the web service call, see the "Sync Interface Definitions" section of this document.

At step 4, the formatter (770) generates a control message (794) and sends it to the specified mailbox associated with a set of software applications for productive work (for example, an Outlook mailbox). Control messages (794) are sent from a dedicated account. When a control message is delivered to the target mailbox (for example, via Microsoft Exchange Server or some other e-mail and directory server 780), it is automatically moved to a hidden folder through a server-side rule so that accidental deletion of control messages is prevented. The server-side rule is supported (created and re-created) by the client (for example, see the Outlook Add-in datasheet for details).

At step 5, control messages (795) are delivered to the client (710) via a mechanism such as e-mail, which is formatted for application software package for productive work (720). The client (710) processes the control messages (795) in step 6 (796) by performing a synchronization process that creates, updates, and deletes the anchored elements as necessary. When processing control messages, the system also takes into account local changes (creation, updating, deletion of binding elements) that must be transferred to the LOB system in order to detect and flag conflicts accordingly.

Figs. 8 and 9 illustrate a retrieval operation that can be used in another exemplary system, the retrieval can be triggered by the synchronization web service or by a forced push that is triggered by the LOB system.

Synchronization logic

Bound items can be changed because the user changes them directly or indirectly through synchronization (for example, a web access interface). It takes a process that compares the elements and identifies the differences between the client and the LOB system in order to decide whether changes on one side should propagate to the other side.

Change can be done in one of four ways. Firstly, the user can change the anchor element in a set of software applications for productive work. The system detects and automatically submits a request for changes to the LOB system. Secondly, the change can be made through another client, and this affects the client of the set of software applications for productive work through synchronization and the LOB system. Changes in the set of software applications for productive work and the LOB system can be made in any sequence with any delay. Thirdly, changes can be made through a smartphone, web access or any other means and synchronized through a server with a set of software applications for productive work. These changes must be detected through the synchronization process. Fourth, changes can be made to the LOB system itself. Each type of change should be considered through a synchronization process.

Local synchronization data storage (SDS) retains the original version. SDS is synchronized and then used to track deltas (differences) between a set of software applications for productive work and the LOB system. Deltas are then added to the virtual request queue containing all service requests to the LOB system. Update procedures determine when changes should be propagated to the LOB system. The synchronization logic formulates a request and provides it to the LOB system when there is a connection. When updating a suite of software applications for productive work, the synchronization logic uses the information of the LOB system to update Outlook, and then updates the SDS.

Most of the data to be bound is contained in two places: as an element in a set of software applications for productive work and in the LOB system. It is assumed that each copy contains additional data that is not in the other copy. The synchronization system is responsible for synchronizing a shared subset of properties stored in the BoundData property of the bound element, and the presence of the bound element, for example, the element can be created or destroyed as a result of synchronization. The synchronization system allows one definition of truth: the LOB system is always right. At the same time, the synchronization system does not have any direct access to LOB objects and, therefore, stores a separate copy in SDS of what it assumes is stored in the LOB system.

The synchronization process can be divided into several separate phases. In the browse phase, all bindable items in the mailbox are compared with SDS. Referential integrity mismatches between the mailbox and the SDS are detected and corrected immediately. Modified elements are detected and marked for further processing. Deleted items are then detected and transmitted to the synchronization tool so that a corresponding deletion request can be sent to the LOB system. In some implementations, the various phases of the synchronization process described above can be combined into one integrated process, where various functions (for example, snap, browse, resolution, etc.) can be combined into a simplified algorithm. A simplified algorithm can achieve greater execution speed or achieve some other greater efficiency (for example, reducing memory / disk usage, eliminating redundancy, etc.).

Any control messages that are identified are processed during the second phase. Next, promotion (expansion) of properties to a higher level is performed for all elements that are marked as modified. The resulting updated representation of the XML data is compared with a copy of SDS, and the synchronization tool is notified. The synchronization tool runs in the background subprocess and in this embodiment uses copies of SDS. The synchronization tool is responsible for providing Create, Update, and Delete queries, as well as query processing.

A copy of SDS contains the same properties as those mentioned above. In a typical situation, EntryID, BoundltemID, BoundItemType, and LOBID are the same for a productive suite item and a copy of SDS. All differences between an element of a software application suite for productive work and a copy of SDS are interpreted as a request to update a LOB object. If not, referential integrity is violated, and an element of the software application suite for productive work needs to be further analyzed. The main reasons for any differences are as follows: an element is created by the user, there is no SDS copy for this element yet, but the BoundData property is readable, and the element is copied, moved or deleted by the user, the binding between EntryID and BoundItemID is broken; there may be zero, one or more elements, all of which are associated with one copy of SDS, and their BoundData properties are readable, an updated meeting request, or a task request is accepted by the user; The corresponding appointment or task (anchor item) has been damaged. The EntryID is preserved, but the BoundData property is no longer readable. A copy of a foreign bound object was received from another user. The BoundData property is not readable, and there is no corresponding copy for this element in SDS. A copy or anchor item is sent to another user, and then it is sent back. This is a variation of previous possibilities, and it cannot be considered as a special case. Data corruption may have occurred.

There is a built-in assumption that BoundItemID is unique (primary key), and the combination of BoundItemType + LOBID is also unique (secondary key). These restrictions must be activated in the SDS database. Of course, in the mailbox EntryID is also unique. Any item where the BoundData property is unreadable or where duplicate properties stored internally do not match the same properties (BoundItemID, BoundItemType and LOBID) in the Outlook item are considered corrupted. As a general rule, the binding of this damaged item is automatically canceled. Any duplicate element (where several Outlook elements have one BoundItemID) is detected and either converted to a new binding element or its binding is canceled; the original is compared with a copy of SDS (in case of movement, we select one copy).

Information flow

Figure 10 illustrates another exemplary flow of information between a set of software applications for productive work on the client and the LOB system. The LOB system (1070) can initiate updates in anchored elements through control messages (Create, Update, and Delete). The format tool (1080) service generates control messages, as requested, through the LOB system (1070). Control messages are transferred to a set of software applications for productive work by means of an electronic message in the mailbox (1010). The server-side rule moves the control message to the specified (hidden) folder (for example, the control message folder 1020) from which they are selected by the control message processor (1030). Create, Update, and Delete queries are processed immediately, while Query queries are queued in SDS (1050) and processed by synchronization tool (1060). The binding / review / permission tool (1040) service (or services, depending on the implementation) is configured to compare all bindable items in the mailbox (1010) with SDS (1050) and identify mismatches / changes in the bindable items.

Although not very common, but important at the same time, the scenario involves the re-creation by the LOB system of all the binding elements for a given user. This can be used to populate the mailbox with initial snap items, as well as as part of a crash recovery when some items were lost or damaged. A variation of this scenario can be used to update existing binding elements to a new binding definition (schema). It can also request information about the current state of the linked items (Query). Another common use is to send regular mail messages to the user's mailbox (1010); in this case, the synchronization system is not involved.

Sender ID is used to distinguish valid control messages from unauthorized (or false) control messages. Information in the control message can be encrypted to protect its confidentiality.

The primary machine is responsible for processing control messages, pushing properties to a higher level, resolving conflicts, and providing updates to the LOB. It keeps SDS and mailbox synchronized. A secondary machine can be used to update binding items via the UI. It also binds its own SDS database using synchronization, but with some important differences. The secondary machine does not process the control message and does not advance (promote) the properties to a higher level during synchronization, nor does the secondary machine send the changes to the LOB system. When compiling SDS, the secondary machine assumes that the data in the mailbox is correct. All failures to update SDS due to referential integrity issues are silently ignored, since it is assumed that the primary machine will eventually resolve the conflict, and that the resolution will be extended to the secondary machine. An important consequence of these rules is that SDS on the secondary machine does not contain the full state of all pending changes, and therefore it cannot be extended to the primary.

The server can be configured to store a synchronization cache (for example, similar to SDS, but excluding data to be bound) for the purpose of distributing business status responses from the server to various secondary client machines. Periodically, the server can push (write) changes to the secondary client so that the secondary clients have the latest copy of the corresponding SDS data.

Synchronization subsystem

The synchronization subsystem is illustrated in Fig. 11, and it consists of the following main components: controller (1102), attached items manager (1106), attached items packaging tool, review tool (1112), resolution tool (1109), control processor (1110) messaging provider (1107) data and means (1105) synchronization.

A controller (1102) is a public component used to control the synchronization process.

A binding element manager (1106) is a public component that is used to create and / or directly access binding elements. A snap-in packaging tool is a publicly available packaging tool that encapsulates an element of a software application suite for productive work as a snap-in item or undo an item. In some implementations, the functionality of the dispatcher (1106) of the bindable elements may be included as part of the controller (1102) or as part of another component.

The viewer (1112) is an internal component used to find anchorable items that need to be analyzed (since they have changed since the last synchronization occurred). In some implementations, the functionality of the detection tool (1112) may be included as part of the controller (1102) or as part of another component.

The resolution tool (1109) is an internal component used to analyze binding elements and either allow changes locally (by expanding (distributing) properties to a higher level) and / or mark them for complete synchronization. In some implementations, the functionality of the resolution tool (1109) may be included as part of a controller (1102) or as part of another component.

The control message processor (1110) is an internal component used to process control messages from the indicated indicated folder (1111) for messages sent by the formatter. Control messages are processed in such a way as to update the elements of the software application suite for productive work in the case of the verbs Create / Update / Delete or to provide Query commands that must be processed by the synchronization tool. In some implementations, the functionality of the control message processor (1110) may be included as part of the controller (1102) or as part of another component.

A data provider (1107) is an internal component that provides access to SDS data tables (1108). In some implementations, the functionality of a data provider (1107) may be included as part of a controller (1102) or as part of another component.

The synchronization tool (1105) is an internal component responsible for: notifying LOB systems when linked items are created, updated or deleted on the client, updating the synchronization data store (SDS 1108) after successful notifications, processing Query control messages and synchronization process status messages . In some implementations, the functionality of the synchronization tool (1105) may be included as part of a controller (1102) or as part of another component.

The timing of the changes is illustrated by FIG. 12, as follows. Changes to binding elements can only be performed on the primary machine (a machine with OBA support) or through another internal interface, for example, from a web service (for example, Outlook Web Access or OWA), or any other clients and mobile devices without support OBA Depending on where the changes are made, the system synchronizes them using slightly different code paths.

Manage Bound Items: Supported Clients

The user can create, update and delete binding items in a client that supports synchronization, for example, using the built-in or plug-in component. The system detects changes and automatically provides a request for changes to the LOB system. The request is processed, and the LOB system sends back a success or failure response at the application level. This response is accepted by the client, and the business state of the bound item application is updated. In the case of new binding elements (for example, created in Outlook), the response from the LOB system is used by the system in order to correlate the attached element with the LOB object.

Manage Bound Items: Web Access

The user accesses his mailbox through web access. Bound items are provided to the user as standard items. The user can change the standard information in the usual way, but not the extended information. The user can update or delete existing anchor elements, but cannot create new ones, except when copying an existing anchor element (indirect creation). When a user returns to the primary machine, changes made through web access are synchronized through a server application (for example, through Microsoft Exchange). The system detects changes and automatically submits the corresponding change request to the LOB system.

Manage Bound Items: Non-Supported Clients

The user can access his mailbox with the help of a client of a set of software applications for productive work, which does not have the appropriate support (not allowed). Bound items are displayed as standard items. The user can change the standard information in the usual way, but not the extended information. The user can update or delete existing binding elements, but cannot create new ones. After that, the user is synchronized with the server application (for example, Microsoft Exchange). When the user returns to the primary client machine, changes made to the client without support are synchronized from the server application. The system detects changes and automatically submits the corresponding change request to the LOB system.

Manage Bound Items: Mobile Devices

The user accesses his mailbox through a mobile device. Special support for mobile devices is not provided, they are treated as web access. Bound items are provided to the user as standard items. The user can change the standard information in the usual way, but not the extended information. The user can update or delete existing binding elements, but cannot create new ones. When a user returns to the primary client machine, changes made on the mobile device are synchronized through a server application (for example, Microsoft Exchange). The system detects changes and automatically submits the corresponding change request to the LOB system.

Manage Bound Items: Many Supported Clients

The user has a “primary” client machine and any number of “secondary” client machines, and each machine has an installed client application that provides synchronization between applications of a set of software applications for productive work and the LOB system. The user can create, update or delete anchored items on any machine. Changes made on one machine are synchronized with others through a server application (for example, Microsoft Exchange), but in one embodiment, only the primary machine is able to synchronize with the LOB system. The "primary" machine is set during installation; other machines are considered "secondary" machines. There is no special limit on the number of secondary machines that a user can have. When the ability to connect to the LOB system is available on the primary machine, the system automatically sends the required change requests to the LOB system.

The described system can be arranged so that the synchronization cache is maintained on the server for the purpose of distributing business status responses from the server to various secondary client machines. For this example, the server synchronization cache is updated before or after each primary client review. The server synchronization cache may consist of all data from the SDS except for BoundData. According to the schedule of review intervals, the server synchronization cache can be loaded from the server into the own SDS of each secondary client.

Managing Bound Items: Propagating Changes

When changes to the corresponding business objects are made in the LOB system, the server application is notified by the formatter. Notification of changes is delivered to clients with support (allowed), who may need to apply changes to the element to be bound. Since the change notification is pushed (transmitted), clients do not have to reload the update and can immediately respond without waiting for the appointed synchronization time.

Synchronization method

13 is a flowchart of an example synchronization method. Periodically, the system tool of the viewer can find and “tag” the elements to be linked that are to be synchronized, while these elements are placed in a logical list for synchronization (synchronization list). For each element in the synchronization list, a request to create, update or delete (CUD request) is generated and stored in the outgoing queue (for example, VOQ 712 from Fig. 7). A call to the web service is then initiated so that a connection to the LOB system can be established. A call to the web service may succeed, fail, or throw a connection exception.

A successful connection is established when a response is received from the LOB in response to a call to the web service. To successfully connect to the web service, the system updates the copy of the bound element in the SDS with information from the response. Additional CUD requests are handled similarly for each item in the synchronization list.

A connection error occurs when an exception other than a connection exception is thrown from the LOB system in response to a call to the web service. For an error connecting to the web service, the CUD request is stored in the outgoing queue and marked for retry. The CUD request retry counter can be initialized when the first connection error is identified. Repeats continue until either a successful connection is established or the maximum number of attempts allowed in a predetermined time interval reaches the limit. The CUD request moves to the error request queue when the maximum number of allowed attempts is reached without success. Additional CUD requests are not processed until a successful connection is reached.

A connection exception can occur when the client has a valid authentication cookie, and the transfer to the target server fails. The system moves to the next item in the synchronization list when a connection exception occurs as a result of accessing the web service.

An exemplary synchronization workflow is illustrated in FIG. 13, as described below. Processing begins at block 1301 and proceeds to decision block 1305.

In decision block 1305, the synchronization system of the productive software application suite evaluates the synchronization list in order to identify all associated items that need to be synchronized between the productive software application suite application and the LOB application. When there are no bindable items in the synchronization list, processing proceeds to step 1310, where the system waits for a predetermined time (for example, X minutes) before re-evaluating the synchronization list. When the bindable items are found in the synchronization list, the system determines whether the maximum number of erroneous requests has been reached, at step 1315. When the maximum number of requests has been reached, the processing proceeds to step 1310. Alternatively, the processing proceeds to step 1320, where the CUD request is generated.

Going to block 1325, the CUD request is queued for outgoing requests, for example, VOQ 712 of FIG. 7. At block 1330, the application synchronization system of the software application suite for productive work sends each request in the outgoing request queue to the LOB system by calling (accessing) a service, such as accessing a web service. Going to block 1335, the CUD call request is evaluated to determine if the request was successfully submitted to the LOB system. Processing proceeds from step 1335 to step 1340 (where the synchronization data store, or SDS, is updated) when the CUD call request is successful. Processing proceeds from decision block 1335 to block 1345 when the CUD call request fails. In some cases, a connection exception is generated, and the processing proceeds from decision block 1335 to decision block 1305.

At block 1345, the product synchronization suite application synchronization system attempts to repeat the CUD call request. At block 1350, the system determines whether a response has been received from the request to call. When the response is successful, the processing proceeds from decision block 1350 to block 1340, where the SDS is updated. When the answer is erroneous, the processing proceeds from decision block 1350 to decision block 1360. If the answer is not accepted, the processing proceeds from decision block 1350 to block 1355, where the system waits for a timeout before attempting another retry at block 1345.

At decision block 1360, the system determines whether the maximum number of retries for the CUD call request has been reached. When the maximum number of retries has been reached, processing proceeds to block 1365, where the CUD request is moved to the error queue. When the maximum number of retries is not exceeded, the system increments the internal retry counter at step 1370 and proceeds to step 1355. to wait for another retry.

Link to synchronized items

As described above, bindings are created between LOB objects and PS elements. When the synchronization system does not have any direct access to the LOB objects, the SDS system stores a separate copy of what it believes is stored in the LOB system. When the link between the LOB and the PS is created, a copy of the synchronized PS can be placed in the SDS so that the PS can be indexed using the LOBID associated with the LOB. In other words, the PS element that is associated with the LOB object can be retrieved from the SDS with reference to the LOBID. Since the PS element can be retrieved with reference to the LOBID, a number of "interested" applications, plug-ins, or other software methods can be implemented that can use the PS element (for example, a system for stream processing of databases).

In one example, a LOB application may send a LOB identifier (e.g., LOBID) to an application in a software suite for productive work through a mail message. An email message includes embedded information that refers to a LOB element. For example, a LOBID may be nested in a header associated with a mail message. The mail message does not have to contain (nested or otherwise) the LOB object itself, since the LOBID refers to the LOB object. After the email message is received, the email descriptor for the productive software suite can identify a particular element of the software suite for productive work in the shadow of synchronization or the synchronization data store that accesses the LOB identifier.

In another example, a user can refer to an element of a software application suite for productive work using a link (for example, URL links in any number of forms, for example, HTTP, HTTPS, FTP, FTPS, OBA, etc.), which refers to LOB identifier associated with the PS element in SDS.

In yet another example, an action bar, task bar, or other similar software methodology can be activated when the LOB system sends an email message to the software suite system for productive work. Once activated, the software methodology can retrieve an element of the software application suite for productive work from the SDS by referencing the LOBID and then act on the element of the software application suite for productive work.

Actions that can be performed for an element of a software application suite for productive work in a software methodology can lead to the creation, updating, or deletion of an element of a software application suite for productive work, which can then be synchronized with the LOB system, as described above. The LOB system can effectively transfer the task to the user of the software application suite for productive work by referring to the software methodology and the LOBID in the mail message.

In one exemplary software methodology, a mail message from the LOB system can send a request to the user to perform an analysis (scan) or statement associated with a particular element of the software application suite for productive work, which is synchronized with the LOB object identified by the LOBID. A mail message can be transmitted automatically through the LOB system when a deadline in the LOB system occurs or when it is provided through a specific user of the LOB system. An e-mail message can be created by means of the LOB system by transmitting information (for example, by presenting XML data, by means of text, by means of embedded data, etc.) to a formatting tool, which then interacts with the email and directory server (see , for example, FIG. 7) to generate a mail message. An e-mail message may emphasize the need to complete an action that is associated with an element of the software application suite for productive work, provide additional explanations, etc., while the e-mail message can refer to tasks in the in-line database processing system. Since the application of the set of software applications for productive work can interpret the link attached to the mail message as a task, the actual information on the task can be presented automatically. After that, the user can select and follow the link to open the task element in the application of the set of software applications for productive work, while the associated database system information can be saved as XML data. Since the LOB identifier can be embedded in a link, any required action associated with an element of the software application suite for productive work can be carried out by configuring the descriptor (for example, the URL descriptor) accordingly.

Although exemplary embodiments and applications are illustrated and described, it should be understood that the invention is not limited to the exact configuration and resources described above. Various modifications, changes and variations obvious to those skilled in the art can be made in the structure, operation and details of the methods and systems disclosed herein without deviating from the scope of the claimed invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention consists in the appended claims.

Claims (20)

1. A machine-readable medium having computer-executable instructions for synchronizing information between a business application (LOB) and an application of a set of software applications for productive work, while the instructions comprise the steps of:
receive the e-mail message transmitted in the eject mode using the application (720) of the software application suite for productive work, while the control message (795) is embedded in the e-mail message transmitted in the eject mode, and the control message is a representation (793) of XML data from the LOB application (760), which sets the changes in the LOB object;
extracting the control message (795) from the email message using the application (720) of a set of software applications for productive work on the client machine (710); and
changes are identified for the anchor element in response to the extracted control message (795) during the synchronization process (796), so that the anchor element is associated with both the element (230) of the productive software suite and the LOB object (251) wherein the control message (795) indicates at least one of: creating the LOB object, updating the LOB object, and deleting (214) the LOB object. 2. The machine-readable medium of claim 1, wherein the instructions further comprise the step of:
authenticate the e-mail message before retrieving the control message (795) so as to prevent simulated access from unauthorized senders. 3. The computer readable medium of claim 1, wherein the instructions further comprise the step of:
provide an alert to the user when the control message (795) is retrieved from the email message. 4. The computer-readable medium of claim 1, wherein the instructions further comprise the step of:
automatically place the extracted control message (795) in at least one of: a hidden folder and a queue (714) of incoming messages. 5. The machine-readable medium of claim 1, wherein the instructions further comprise the step of:
save each attached element in the synchronization data store (SDS, 1050) on the client machine (710). 6. The machine-readable medium of claim 5, wherein the instructions further comprise the step of:
identify the changes between the elements (230) of the application of the software suite for productive work and the associated LOB objects (251) using SDS (1050) and place the requests for the identified changes in the virtual queue (712) of requests for synchronization with the LOB system (250 ) 7. The machine-readable medium of claim 5, wherein the instructions further comprise the step of:
comparing all the binding elements in the mailbox (1010) for the application (720) of the software suite for productive work with SDS (1050) and detect and record the link integrity between the mailbox (1010) and SDS (1050). 8. The machine-readable medium of claim 7, wherein the instructions further comprise the steps of:
mark modified elements for subsequent processing, increase the level of properties of marked elements; and
comparing the resulting updated representation of the XML data with the SDS copy. 9. The machine-readable medium of claim 1, wherein the synchronization process comprises at least one of the following: identification and resolution of conflicts (1230) associated with the element to be bound, increasing the level of property associated with the element being bound, lowering the level of property, associative associated with the binding element, and updating the binding elements without increasing the level of properties when the application of the set of software applications for productive work is assigned to the secondary machine (260). 10. The machine-readable medium of claim 1, wherein the instructions further comprise the steps of:
create an outgoing request (212) in response to a change in an element of the set of software applications for productive work on the client machine (210), while the outgoing request contains at least one of:
creating, updating, and deleting (212) associated with element (230) of a set of software applications for productive work;
place the outgoing request in the outgoing queue (712) for synchronization with the LOB application (760);
initiate a call (792) to the web service for queuing a request to the LOB application (760) at the first moment of time so that the LOB application (760) can retrieve the outgoing request from the web service when the web service successfully connects to LOB application (760); and
remove the outbound request from the outbound queue (712) and update the synchronization data store (SDS, 1050) when the web service successfully connects to the LOB application (760). 11. The computer readable medium of claim 10, wherein the instructions further comprise the step of:
initiate a second call (792) to the web service for an outgoing request in the outgoing queue (712) at the second point in time when the web service was initially unable to successfully connect to the LOB application. 12. The machine-readable medium of claim 10, wherein the instructions further comprise the step of:
encoding a request for presenting XML data for reception by a LOB application (760). 13. A device for synchronizing information between a business application (LOB) and an application of a set of software applications for productive work, while the device contains:
processor (104);
computer readable medium (116, 118, 120, 122, 124);
operating environment (126) stored on a computer-readable medium and executed on a processor (104); and
an application (128, 130) running under the control of the operating environment (126) and configured to perform an action, while the application (128, 130) is configured to:
create a request (214) in response to a change in the LOB object (251), while the request contains at least one of the instructions to create a LOB object, update the LOB object, and delete the LOB object;
form a representation (793) of XML data associated with a change in the LOB object (251);
format the presentation (770) of XML data into a control message (794), which is encoded in an email message (780); and
transmit in an push mode an e-mail message (780) to the application (720) of the software application suite for productive work, so that changes in the LOB object (251) can be synchronized (730) with the application elements of the software application package for productive work, by retrieving the control message (795) from the email message. 14. The device according to item 13, in which the application is additionally configured to transmit in the push mode an e-mail message to another application (270) of a set of software applications for productive work, which is available on the secondary client (260). 15. The device according to item 13, in which the application is additionally configured so that:
Accept an online service (792)
retrieve the update request (791) from the web service call (792), wherein the update request (791) is associated with a change in the application element of the software application suite for productive work; and
update the LOB object in response to the retrieved update request, wherein the retrieved update request corresponds to at least one of an instruction to create an application element of a software application suite for productive work, update an application element of a software application suite for productive work, and delete an application element for a software application suite for productive work. 16. The device according to clause 15, in which the update request from the call (792) to the web service is another representation of XML data. 17. The device according to item 13, in which the application is additionally configured so that:
accept a call (792) to a web service from an application (720) of a set of software applications for productive work,
retrieve a request from a web service call, and
Create a LOB object in response to the retrieved request. 18. A method for synchronizing information between a business application (LOB) and a software suite application for productive work, the method comprising the steps of:
receiving a representation (793) of XML data from a LOB application (760), wherein the representation (793) of XML data identifies changes associated with at least one object in the LOB application (760);
format (770) the representation (793) of the XML data into a control message (740);
embed a control message (794) in an email message (780); and
send an e-mail message (795) to the application (720) of the software application suite for productive work in the push mode, so that changes associated with at least one object in the LOB application (760) can be synchronized with the application (720 ) a set of software applications for productive work. 19. The method according to p, optionally containing stages in which:
accept another representation (792) of XML data from an application (720) of a set of software applications for productive work;
identifying changes associated with at least one element in the application of the software application suite for productive work, from another representation (792) of XML data; and
updating at least one object in the LOB application (760) based on the identified changes so that the at least one object in the LOB application is associated with at least one element in the application of the software application suite for productive work. 20. The method according to claim 19, in which the update contains at least one of: creating, modifying and deleting at least one object in the LOB application.

Images