MX2008004933A - Productivity suite to line of business synchronization mechanism - Google Patents

Abstract

A synchronization method is arranged to permit synchronization between a productivity suite application and a line of business (LOB) application such as a Customer Relation Management or CRM application. Requests are sent from the productivity suite application to the LOB application via a web service call to update, delete, or create a new entity in the LOB application. The LOB application extracts each request from received web service calls, where the request can be provided in an XML data representation. Requests are communicated to the productivity suite application via control messages that are embedded in an email to update, delete, or create an item in the productivity suite application, where the item is associated with a LOB entity. The control messages are hidden from the user, and extracted from the email message for evaluation, conflict resolution, property promotion and binding between the LOB entity and the productivity suite application item.

Description

MECHANISM OF SYNCHRONIZATION FROM SERIES OF PRODUCTIVITY TO BUSINESS LINE Background of the Invention There are a number of productivity series available to users that include applications for scheduling events, storing contact information, supporting email, storing task information, etc. An example is Microsoft Outlook® available from Microsoft Corporation, Rendmond, Washington. Microsoft Outlook® is part of the Microsoft Office® productivity series. Many users are familiar with such productivity serial applications and use them on a regular basis. Some productivity series users also use business software applications or systems developed for particular business uses (also referred to here as Business Line or LOB systems). An example is the Customer Relationship Management (CRM) systems available from a number of companies. Much information that is managed through LOB systems can include contact management, scheduling or cataloging events and tasks, to name a few. In many cases, the productivity series can not exchange or synchronize information with the LOB system in an automatic way. For example, if a user adds a business task in the user productivity series, the task information will not automatically migrate through the LOB system. Rather, the information is discovered by the user in each different system. Typically, the user will have to enter the task information for a second time in the LOB system. Some users may wish to allow the storage of LOB information in the email system and the synchronization with the LOB information in retrieval systems.

Brief Description of the Invention According to various aspects of the described embodiments, a synchronization method is arranged to allow synchronization between a client machine that includes a serial productivity application and a server machine that includes a business application line (LOB). The productivity serial application can be a personal information manager (PIM) application such as-Outlook® (available from Microsoft Corporation, Redmond, Washington), or some other application such as Lotus Notes, Star Office, etc. Illustrative productivity series applications include e-mail handling, appointment management, schedule / calendar management, note handling, task management, contact management, and others. Synchronization can be handled between data items in the productivity serial application and entities in the LOB application through the use of XML data representations and stored union information. In a particular implementation, the information that is used for synchronization is stored in an XML data representation. The XML data representation can be stored as a property for the data item in the productivity serial application. The presentation of XML data can be communicated to the LOB application, which can then handle its own conflict resolution and data storage for LOB entities. Changes to the entities in the LOB application can then be provided as an XML, which can subsequently be formatted to a control message that is communicated to the productivity serial application. The XML data representations provide a uniform interface that is simply handled by each respective application. In another aspect, the cryptic encoding of the information is performed on a per-user basis. This aspect can advantageously help to ensure that the information contained in any PIM article that is sent to an electronic mail receiver can not be read by that recipient and thus can not be inadvertently shared. In a related aspect, the cryptic encoding helps to prevent the information from causing unexpected behavior on the receiver side. For example, in some conventional systems, the information contained in appointments can easily be shared when invitations are sent for the appointment. In this way, the user can share information without being aware of it. The cryptic coding of the information avoids this occurrence of inadvertent sharing of information. However, in the case where the user has multiple devices, the described cryptic coding will not prevent the information being shared through the multiple devices of the user. In another aspect, the information is stored in a personal property, reducing the likelihood of overwriting. In some conventional systems, the information can be implicitly exchanged with the guests in an appointment request without the applicants noticing. When the applicant and the guest share the information, either by sending the information explicitly or implicitly, there is a possibility that the information will be stored in the same property. Since the last stored information will be maintained, the information of one of the users can be overwritten. In one aspect of the present disclosure, a specific property name is assigned to store the additional information so that conflicts are avoided. In another aspect, the information can be promoted to a higher degree and lower grade so that the elements or attributes of the information (ie, which is in XML) can be replicated to properties in articles containing PIM. For example, in an implementation, the Microsoft Outlook® Ul standard can be used to present or manipulate these values and / or the values can be shared with other users. In one aspect of the present disclosure, an XML data representation is provided to the LOB application so that the LOB items can only be changed by the LOB application. In other aspects, the LOB article is formatted into an XML data representation that is then used to synchronize with the productivity serial application items. Since XML can be used as the mechanism for transferring information, simplified user interfaces can be implemented for the productivity serial application. In another aspect, dialogues between the productivity series and the LOB application are mutually synchronized. The dialogues can be developed in any appropriate language such as, for example, an extensible application markup language (XAML). The synchronization between dialogs advantageously allows multiple dialogues that show the exact article that will be open simultaneously. When the user enters information in a dialogue, the information is automatically changed in all other places where it is being displayed. For example, in a Microsoft Outlook® implementation, when the same information is displayed in a Microsoft Outlook® (Inspector) dialog and in the task box or action box, these need to be synchronized. This aspect provides mechanisms that allow multiple dialogs in Microsoft Outlook® to share the same data case (while they are in the editing process).

In yet another aspect, a serial productivity application on a client machine is configured to send requests through a web server call to update, delete, or create a new entity in the LOB application. The LOB application extracts the request from the client machine, where the request can be provided in an XML data representation. The server machine sends requests through control messages that are embedded in an email to update, delete, or create an article in the productivity serial application, where the article is associated with a LOB entity. The control messages are hidden from the user, and are extracted by the client machine for evaluation, conflict resolution, property promotion and union between the LOB entity and the productivity serial application article. In a further aspect, a LOB application can communicate a LOB identifier in an email communication, wherein the LOB identifier is associated with a prior binding between a productivity serial item and a LOB entity. The LOB identifier can be embedded in an email communication in the header associated with the email message. The email communication does not need to contain (embedded or otherwise) the same LOB entity, since the LOB identifier refers to the LOB entity. Once the e-mail message is received, the e-mail handler for the productivity series can identify a specific productivity serial item in a synchronization shadow or synchronization data storage by reference to the LOB identifier. In one example, the user can access the productivity serial article by selecting a link (for example, a URL link in any number of ways such as http, HTTPS, FTP, FTPS, OBA, etc.), and other embedded information (for example, an XML data representation, or other data representation) that is associated with the LOB identifier in the email message. In another example, an action box or task box can be activated to access the specific productivity series item. Since the LOB identifier can be embedded in a link, any desired action associated with the productivity serial item can be taken by configuring the handler (eg, a URL handler), appropriately.

Brief Description of the Drawings Now non-limiting and non-exhaustive embodiments will be described with reference to the following drawings, wherein similar reference numbers refer to similar parts throughout the various views unless otherwise specified. Figure 1 is a block diagram representing an illustrative general computer environment that can be used to implement the techniques described herein, in accordance with one embodiment. Figure 2 shows an illustrative system in which a client device is arranged for synchronization with a LOB system. Figure 3 illustrates how the correlation between a merged item and a LOB entity is established when a new merged item is created by the LOB system. Figure 4 illustrates how the correlation between a merged item and a LOB entity is established when a new merged item is created in the productivity series. Figure 5 illustrates how the correlation between a merged item and a LOB entity is changed when a merged item is updated or eliminated in the productivity series. Figure 6 illustrates how the correlation between a merged item and a LOB entity is changed when a merged item is updated or deleted by the LOB system. Figure 7 illustrates an illustrative communication flow between a client and a server during a push operation. Figures 8 and 9 illustrate an attraction operation that can be employed in another illustrative system. Figure 10 shows an illustrative design of the synchronization subsystem for a series of productivity that is used in a client machine. Figure 11 shows another flow of illustrative communication between a client and a server.

Figure 12 shows an illustrative synchronization subsystem. Figure 13 is a flow chart for an illustrative synchronization method.

Detailed description Various embodiments are described more fully below with reference to the accompanying drawings, which form a part thereof, and which show specific illustrative modalities for practicing various modalities. However, other modalities can be implemented in many different ways and should not be constructed as limiting the modalities established here; rather, these modalities are provided so that this description will be concise and complete. The modalities can be practiced as methods, systems or devices. Therefore, the modalities may take the form of a hardware implementation, a full software implementation or an implementation that combines the software and hardware aspects. Therefore, the following detailed description should not be taken in a limiting sense. Briefly stated, a synchronization method is arranged to allow synchronization between a client machine that includes a serial productivity application and a server machine that includes a business line application (LOB) such as a Relationship Management application Client or CRM application. The client machine sends requests through a web server call to update, delete, or create a new entity in the LOB application. The LOB application extracts the request that is received from the client machine, where the request can be provided in an XML data representation. The server machine sends requests through control messages that are embedded in an email to update, delete or create an article in the productivity serial application, where the article is associated with a LOB entity. The control messages are hidden from the user, and are extracted by the client machine for evaluation, conflict resolution, property promotion and union between the LOB entity and the productivity serial application article. The logical operations of the various modalities are implemented, (1) as a sequence of steps implemented in a computer that run in a computer system, and / or (2) as machine modules interconnected within the computer system. The implementation is a matter of choice depending on the operating requirements of the computer system that implement the modality. Accordingly, the logical operations forming the modalities described herein are alternatively referred to as operations, steps or modules. Various modules, techniques and methods can be described here in the general context of computer executable instructions, such as program modules, executed by one or more computers or other devices. Generally, the program modules include routines, programs, objects, components, data structures, etc., to perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules can be combined or distributed as desired in various modalities. An implementation of these modules and techniques can be stored in or transmitted through some form of computer-readable media. Computer-readable media can be any available media that can be accessed by a computer. By way of example, and not limitation, computer readable media may comprise "computer storage media" and "communications media". "Computer storage media" includes non-volatile, removable and non-removable media implemented in any method or technology for the storage of information such as computer-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 memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, storage of magnetic disk or other magnetic storage devices, or any other means that can be used to store the desired information and that can be accessed by a computer. The "media" typically modalizes computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism. The media also includes any means of information provision. The term "modulated data signal" means a signal having one or more of its characteristics set or changed in such a way as to encode information in the signal. As a non-limiting example only, the media includes means by keys such as a network by keys or a direct cable connection, and wireless means such as acoustic, RF, infrared, and other wireless media. Also included are combinations of any of the foregoing within the scope of computer readable media. Reference has been made through this specification to "one embodiment", "the embodiment" or "an illustrative embodiment" representing that a particular described aspect, structure or characteristic is included in at least one embodiment. In this way, the use of such phrases can refer to more than one modality. In addition, the aspects, structures or characteristics described can be combined in any suitable form in one or more modalities. However, one skilled in the art can recognize that the modalities can be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other cases, structures, resources or well-known operations have not been shown or described in detail merely to avoid obscuring aspects of the modalities.

Illustrative Computation Environment Figure 1 illustrates a general computing environment 100, which can be used to implement the techniques described here. The computer environment 100 is only an example of a computing environment and is not intended to suggest any limitations as to the scope of use or functionality of computer and network architectures. Neither the computer environment 100 should be interpreted as having any dependency or requirement in relation to any or a combination of components illustrated in the illustrative computer environment 100. The computer environment 100 includes a general-purpose computing device in the form of a computer 102. The components of the computer 102 may include, but are not limited to, one or more processors or processing units 104, system memory 106 , and common system driver 108 that couples various system components including processor 104 to system memory 106.

The common conductor of the system 108 represents one or more of any of several types of common conductor structures, including a common memory conductor or memory controller, a common peripheral conductor, an accelerated graphics port, and a common processor or driver local using any of a variety of architectures' common driver. By way of example, said architectures may include a common Standard Architecture of Industry (ISA) conductor, a common Microchannel Architecture (MCA) conductor, a common Enhanced ISA conductor (EISA), a common local conductor of the Association of Video Electronics Standards (VESA), a common Peripheral Component Interconnect (PCI) driver, also known as a Mezzanine common driver, a common PCI Express driver, a Universal Serial driver (USB), a Secure Digital common driver (SD), or an IEEE 1394, that is, common FireWire driver. Computer 102 may include a variety of computer readable media. Said means can be any available means that are accessible by the computer 102 include both volatile and non-volatile means, removable as non-removable media. System memory 106 includes computer readable media in the form of volatile memory, such as random access memory (RAM) 110; and / or non-volatile memory, such as read-only memory (ROM) 112 or flash RAM memory. A basic input / output system (BIOS) 114, containing the basic routines that help transfer information between elements within the computer 102, such as during startup, is stored in the ROM 112 or flash RAM. The RAM 110 typically contains data and / or program modules that are immediately accessible to and / or are actually operated through a processing unit 104. The computer 102 may also include other removable / non-removable computer storage media, volatile / non-volatile. By way of example, Figure 1 shows a hard disk drive 116 for reading from and writing to a non-removable, non-volatile magnetic medium (not shown), magnetic disk unit 118 for reading from and writing to a removable magnetic disk, non-volatile 120 (e.g., a "floppy disk"), and an optical disk drive 122 for reading and / or writing to a removable, non-volatile optical disk 124, such as a CD-ROM, DVD-ROM, or other optical media. The hard disk drive 116, the magnetic disk drive 118, and the optical disk unit 122 each are connected to the common conductor of the system 108 through one or more data media interfaces 125. Alternatively, the disk drive Hard 116, magnetic disk unit 118, and optical disk unit 122 can be connected to common system conductor 108 through one or more 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 the computer 102. Although the example illustrates a hard disk 116, a removable magnetic disk 120, and a removable optical disk 124, it can be seen that other types of media readable by computer that can store data that is accessible by a computer, such as magnetic cassettes or other magnetic storage device, flash memory cards, CD-ROM, digital versatile discs (DVD) or other optical storage, random access memory (RAM) , read-only memories (ROM), electrically erasable programmable read-only memory (EEPROM), and the like, can also be used to implement the illustrative computing environment and system. Any number of program modules can 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 the operating system 126, one or more application programs 128, other program modules 130, and program data 132 (or some combination thereof) can implement all or part of the resident components that support the distributed file system. A user can input commands and information to the computer 102 through input devices, such as the keypad 134 and a pointing device 136 (e.g., a "mouse"). Other input devices 138 (not specifically shown) may include a microphone, game pad, game pad, satellite antenna, serial port, scanner or scanner, and / or the like. These and other input devices are connected to the processing unit 104 via input / output interfaces 140 which are coupled to the common conductor of the system 108, but may be connected through another interface and common conductor structures, such as a parallel port, game port, or a common universal serial driver (USB). The monitor 142 or another type of display device can also be connected to the common system conductor 108 through an interface, such as a video adapter 144. In addition to the monitor 142, other peripheral output devices can include components such as speakers (not shown) and printer 146, which can be connected to the computer 102 through interfaces I / O 140. The computer 102 can operate in a networked environment using logical connections to one or more remote computers, such as the device of remote computing 148. By way of example, the remote computing device 148 can be a PC, laptop, server, router, network computer, peer device or other common network node, and the like. The remote computing device 148 is illustrated as a portable computer which may include many or all of the elements and aspects described herein in relation to the computer 102. Alternatively, the computer 102 may also operate in a non-networked environment. The logical connections between the computer 102 and the remote computer 148 are illustrated as a local area network (LAN) 150 and a general wide area network (WAN) 152. Such networked environments are common places in offices, network computers between companies, intranets, and the Internet. When implemented in a LAN environment, the computer 102 connects to the local network 150 through a network interface or adapter 154. When implemented in a WAN network environment, the computer 102 typically includes a 156 modem or others. means for establishing communications over the wide network 152. The modem 156, which may be internal or external to the computer 102, may be connected to the common system conductor 108 through I / O 140 interfaces or other appropriate mechanisms. It should be appreciated that the network connections illustrated are examples and that other means may be employed to establish at least one communication link between computers 102 and 148. In a networked environment, such as that illustrated with the computing environment 100 , program modules illustrated in relation to the computer 102, or portions thereof, can be stored in a remote memory storage device. By way of example, remote application programs 158 receive in a memory device of remote computer 148. For purposes of illustration, applications or programs and other executable program components such as the operating system are illustrated here as discrete blocks, although it is recognized that said programs and components receive at various times in different storage components of the computing device 102, and are executed by at least one computer data processor. Below is an illustrative interface description and the configuration implemented in Microsoft Outlook® to support the synchronization of Microsoft Outlook® information with a LOB system. In other modes, different productivity serial applications can be used instead of or in addition to Microsoft Outlook®.

Illustrative Configuration Figure 2 shows an illustrative system in which a client device is arranged for synchronization with a LOB system. As shown in the figure, a Productivity Series (220) such as Microsoft Outlook® is available on a client device. Microsoft Outlook® maintains one or more items such as calendar appointments, contacts, email, etc. Each productivity serial item (230) includes a group of standard properties (231) that refers to the productivity series, and one or more data items (LOB 232 data) that are related to the LOB system. Additional system properties are also associated with the system so that it may be necessary to join data and properties to the article (for example, union information in the property system 233). Outside the article (240), there is a group of system properties that are related to synchronization (242), as well as a data storage that is used to cache synchronization data (241). An individual user must be able to install client software on multiple machines. However, only the primary machine is able to synchronize with the LOB System. Other machines are considered secondary machines. The LOB System returns a business response synchronously to the primary machine. The LOB system is interconnected with a formatter to provide "commands" that originate in the LOB system to the primary machine, such as commands to create, update or delete. At any time, there can be only one primary machine. Secondary machines (for example, customer 260), which include their own copy of the productivity series (270), still contain a copy of the information available on the primary machine, including business states and synchronization of linked items (by example, productivity article 280, including properties 281-283). The described system can be arranged to maintain a synchronization cache on a server to distribute business status responses from the server to the secondary clients. Serial productivity items (for example, article 230) must maintain sufficient information for the system to recognize and present joint articles. LOB data (including properties that rise in grade) must be stored and associated with the productivity serial item. The system information stored in serial productivity items must be static. In other words, it should not change once it is set to prevent the introduction of "artificial" synchronization conflicts. The system should store synchronization data and system properties related to synchronization outside the productivity serial items. A signal, which is hidden in a property, can be used to designate which machine is the primary one. In some cases, the signal can be passed in such a way that the primary machine can be changed, such as in the case of disaster recovery. Figure 3 illustrates how the correlation between a merged item (330) and a LOB entity (370) is set when a new merged item is created by the LOB system. First, the LOB entity (370) is created in the LOB system (360) as designated by step 1 (391), wherein the LOB entity (370) includes an identifier (LOBID 372). The LOB system (360) communicates a request (392) to the server (340) to create the LOB entity identified by LOBID 372 as an attached article as designated by step 2. The server (340) receives the request (392) and applies a formatter (250) to the request (392), resulting in the communication of a command (394) to the primary client (310) to create the join. The synchronization subsystem (320) for the productivity series (e.g., Outlook) in the client (310) receives the command (392) during the next synchronization and creates a link to an outlook (350) article as designated by the step 5. The merged article has a unique identifier (BIID 332) that is assigned to it, and is associated with the LOB entity through'LOBID 334. Figure 4 shows how the correlation between a merged item and a LOB entity is established when a new united article is created in the productivity series. First, article (430) is created in the productivity series as designated by step 1 (491). Then, the synchronization subsystem (420) in the productivity series (for example, Outlook) communicates (492) to create a LOB system binding command (460) as designated by step 2. The LOB system (460) ) receives the creation of join command during the next synchronization with the client, and creates a LOB entity (470) identified by LOBID 472, as illustrated by step 3 (493). The LOB system (460) optionally communicates the LOBID (472) back to the client (410) in step 4 (494), where the client (410) then you can associate the LOBID (434) with the linked article (430) as illustrated by step 5 (495). In some cases, the LOBID (472) does not communicate back to the productivity series.

Figure 5 illustrates how the correlation between a merged item and a LOB entity is changed when a merged item is updated or eliminated in the productivity series. First, article (530) is changed in the productivity series as designated by step 1 (591). Then, the synchronization subsystem (520) in the productivity series (for example, Outlook) communicates (for example, through a web service call) either to update or delete, in the LOB system (560) as it is designated by step 2 (592). The LOB system (560) receives the update / deletion of the join command during the next synchronization with the client (510), and modifies or eliminates the LOB entity (570) identified by the LOBID 572, as illustrated by step 3 ( 593). In some cases, in, .done the LOBID (534) is not known for the productivity series, the LOB system (560) refers to the union identifier, BIID 532 to determine which LOB entity (570) to modify or eliminate. Figure 6 illustrates how the correlation between a merged item and a LOB entity is changed when a merged item is updated or deleted by the LOB system. First, the LOB entity (670) is modified or deleted in the LOB system (660) as designated by step 1 (691). The LOB system (660) communicates a request (692) to the server (640) to update or delete the LOB entity identified by at least one of the LOBID (672) and the Bl 1 D in the request (692) for the server (640) ). The server (640) receives the request (692) and applies a formatter (650) to the request (692), resulting in the communication of a command or control message (694) to change or eliminate the joined article as designated by step 4. The synchronization subsystem (620) for the productivity series (for example, Outlook) on the primary client (610) receives the command during the next synchronization and modifies or removes the union (for example, BIID 532 and LOBUD 634) to the appropriate attached article (630) as designated by step 5 (695). The synchronization subsystem described above is deployed to client machines that can be inside or outside a corporate network. A virtual private network or VPN connectivity to the corporate network is expected, such as remote HTTP synchronization connections through a server application such as the Microsoft Exchange Server. LOB synchronization can run as a background sequence on the client device as long as the productivity series is running. Changes made in the productivity series are issued to the LOB system, through any available RPC mechanism (for example, corporate network, VPN, HTTP, etc.), while changes in the LOB system are expected to be made only in the corporate network. File synchronization can be handled in any appropriate form within the corporate network, such as through the Microsoft Active Directory, which can be arranged to expose a .NET API for such purposes.

Illustrative Synchronization Interface Definitions For each United Article Type, the synchronization system will execute a different action depending on the change that occurs (create / update / delete). In addition to this, a "Query" action can be invoked as a result of processing a Query Control Message. The following specifies the information that needs to be passed to and returned from each of these actions. Create is invoked by the system each time a United Article creation from the client side is processed: The parameters for Create include United Article ID, New Article Data, and Culture Name. Return values for Create include LOBID, Business Status, and Description. The United Article ID is a unique identifier sequence generated by the customer for the United Article. The New Article Data is an XML document that is defined by a schema for the LOB system, so that the LOB Data for the merged article is appropriately provided. The Culture Name is the name of the culture that should be used for the business status, descriptions and any other message of the Create call. The LOBID is a sequence that is generated by LOB as a unique identifier for the type of item (for example, the Contact ID only identifies the contact). The Business Statement is a sequence corresponding to a short name of the new business state that must be assigned to the United Article as a result of the Create parameter. It is an arbitrary value provided by the LOB System, the synchronization makes no assumption about the contents of this value. The idea is that this value can be used to filter items that are in the same state. The description is an optional sequence that is an explanation about the State of Business. This will be part of the United Article information so that it can be a Description exposed in the Ul if desired. Refresh is invoked by the system every time a United Article update from the client side is processed. The parameters for Update include United Article ID, Request ID, LOBID. Previous Article Data, New Article Data, and Culture Name. The return values for Update include Business Status, and Description. The Request ID is a unique identifier for the update message to allow the LOB System to identify duplicates. The same Request ID must be sent if a duplicate update message is sent. The Prior Article Data is an XML document that corresponds to all the LOB Data of the united article of the last synchronized state. Delete is invoked by the system each time a United Article deletion from the client side is processed. The parameters for Delete include United Article ID, LOBID, Previous Article Data, and Culture Name. The values returned for Delete include Business Status and Description. Query Result is invoked by the system each time a Query Control Message is processed The Query Result parameter is an XML document that contains the list of the United Article Ids and its corresponding LOBID for all the United States Existing United States. specified type There are no return values for the Query Result Illustrative Control Message Definitions This section specifies the information that is expected in each type of Control Message. Control messages include a Create Control Message, an Update Control Message, a Delete Control Message, and an Inquiry Message. Control The Create Control Message includes the fields for United Article ID, LOBID, United Article Type, and LOB Data The Update Control Message includes fields for LOBID, United Article Type, and LOB Data The Delete Control Message includes fields for LOBID United Article Type The Control Query Message includes a field for the United Article Type The United Article ID is a unique identifier that will be assigned to the new United Article The United Article ID is generated by the formatter as described with more detail later The United Article Type is a sequence that corresponds to a fully qualified name of the Article Type United including solution and version The United Article Type can be used by the system to locate the corresponding United Article Definition, which describes the properties that will be attached to the productivity serial article and how the productivity serial item will be synchronized with the LOB entity. As previously described, LOBID is the unique identifier assigned by the LOB System to the United Article, and the LOB Data is an XML document containing all the LOB data for the United Article.

Illustrative Synchronization System The system can be arranged so that it is not based on events in the productivity series (for example, Microsoft Outlook) to invoke and detect synchronization. In order to detect changes (create / update / delete), the system uses a 3-way synchronization aspect, between the productivity series, a synchronization data storage (SDS), and the information obtained directly from the LOB System. The data can be changed from multiple entry points in the system. The information can be changed in many different places, including web access, mobile devices, and other client machines. The changes will eventually be synchronized to a primary client machine (for example, through Outlook / Exchange synchronization). The LOB System can detect and handle requests in duplicate based on a unique Request ID. The outgoing communication (client to server) with the LOB System can be done through web services, while the incoming messages (server to client) will flow to the clients through the server application (for example, Microsoft Exchange) . Conflict detection is also handled by the system when the same United Article is changed by the LOB System and the productivity series. If the system detects that the same United Article has been updated by the user and the LOB System, a Conflict will be identified and a conflict resolution will be properly addressed. The LOB System supports providing immediate business responses when a synchronous Web Service call is received. The LOB System does not need to receive a confirmation or error notification about the successful processing of commands from Create, Update, Delete or Consult. This section describes the high-level communication flows between the LOB System and the Client. The following diagrams provide a summary of possible communication flows that are supported. Figure 7 shows an illustrative communication flow between a client and server during a push operation. The push operation can be initiated by the client (710) or the server (750) as will be described. Step 1 illustrates a client (710) that initiates the flow, where a change detection process is executed by the system in the Client. In step 1, the synchronization logic (730) in the system identifies new United Articles, updated and deleted and creates (791) a virtual list of change requests that need to be submitted to the LOB System. The virtual list can be provided in a queue such as a virtual output queue (VOQ 712). The list is processed when there is connectivity (for example, web service call 792) to the LOB System (for example, server 750) in step 2. If no connectivity is identified with the LOB System in step 2, then the list goes back to try the next time the change detection process is running. When the virtual list of requests is created, the system also takes into account new Input Control Messages (create, update, delete notifications that come from the LOB System, from the Control Message List 714) to detect and resolve or raise conflicts properly. A Conflict is detected by the synchronization logic (730) when the same article has been modified in the productivity series and the LOB System, or when one side tries to update an article when the other is trying to delete it. For each detected change (create, update, delete) that does not result in a Conflict, the system issues a request to the LOB System (for example, server 750) by calling a Web Service (792) as described in the Definitions of Synchronization interface. The LOB System (for example, server 750 with the LOB 760 application) can also activate the execution of the actions to create, update, delete, or consult the client (710) when relevant actions occur in the LOB system. In step 3 the LOB system calls a web service (793) that is exposed by the Formatter (700). In the case of creating requests, the Formatter (770) returns the Unique Id that will be used by the system to identify the new United Article. For details on the information sent as part of the Web Service call see the section on Synchronization Interface Definitions discussed here. In step 4, the Formatter (770) generates a Control Message (794) and sends it to the specified mail associated with the productivity series (for example, an Outlook mail). Control Messages (794) are sent from a dedicated account. When the Control Message is supplied to the target mail (for example, by the Microsoft Exchange Server, or some other EMAIL and directory server 780) it is automatically moved to a hidden folder by a server-side rule so that it is avoided an accidental deletion of Control Messages. The server-side rule is maintained (created and recreated) by the Client (for example, see the Outlook addition specification for more detail). In step 5, the Control Messages (795) are delivered to the Client (710) through a type of email type mechanism that is formatted for the productivity serial application (720). The client (710) processes the Control Messages (795) in step 6 (796) by running a synchronization process that creates, updates and removes United Items as required.

When Control Messages are processed, the system also takes into account local changes (create, update, delete United Articles) that need to be communicated to the LOB System to detect and indicate conflicts appropriately. Figures 8 and 9 illustrate an attraction operation that can be employed in another illustrative system, where the attraction can be initiated by a synchronization web service or by a soft touch that is imitated by the LOB System.

Logic of Synchronization United Articles can be changed since the user changed them directly or indirectly 'through synchronization (for example, a web access interface). A procedure is needed that compares the articles and determines the differences between the client and the LOB system to decide if changes on one side should be propagated to the other side. A change can occur in one of four ways. First, the user can change a first United Article in the productivity series. The system detects and automatically issues a request for a change to the LOB System. Secondly, the change can be made through another Client and this affects both the serial productivity client through synchronization and the LOB System. Changes to the productivity series and the LOB System can occur in any sequence with some delay. Third, the change can be made through a Smart Phone, web access, or other means and is synchronized through the server to the productivity series. These changes need to be found through a synchronization process. Fourth, the change can be made in the same LOB System. Each type of change must be considered by the synchronization process. A Local Synchronization Data Storage (SDS) stores the original version. The SDS- is synchronized with and subsequently used to track deltas between the productivity series and the LOB System. The deltas are then added to a virtual request queue containing all the service requests for the LOB System. The updating procedures determine when the changes need to be propagated to the LOB System. The synchronization logic formulates a request, and presents it to the LOB System when there is connectivity. When the productivity series is updated, the synchronization logic uses the LOB System information to update Outlook and then updates the SDS. Most of the joined data exists in two places: as an article in the productivity series and in the LOB system. It is assumed that each copy contains additional data that does not exist in the other copy. The synchronization system is responsible for synchronizing: a shared subset of properties stored in the United Data property of the merged item, and the existence of a merged item, for example, the item may be created or destroyed as a result of synchronization. The synchronization system assumes an individual definition of trust the LOB system is always correct At the same moment in which the synchronization system has no direct access to LOB entities, and in this way maintains a separate copy in the SDS of what assumes it is stored in the LOB system The synchronization process can be divided into several different phases. In the sweep phase, all items linked in the mail are compared against the SDS. Inequalities in referential integrity are immediately detected and fixed between the mail and SDS Modified items are detected and marked for further processing After deleted items are detected and passed to the synchronizer, so that an appropriate elimination request can be sent to the LOB system. In some implementations, the vain phases of the synchronization process described above can be merged into a single integrated process, where several functions (for example, join, scan, resolution , etc) can be combined in a simplified algorithm The simplified algorithm can obtain an improved execution speed or obtain some other improved efficiency (for example, reduce memory / disk usage, eliminate redundancies, etc) Any control message that is identified is processed during the second phase. Then, property promotion occurs for all items that were marked as modified. The resulting updated XML data representation is compared to the SDS copy and the synchronizer is notified. The synchronizer runs in a background sequence and in this mode uses SDS copies. The synchronizer is responsible for submitting Create, Update and Delete requests, as well as processing queries. The SDS copy contains the same properties mentioned above, under normal circumstances, the Input ID, United Article ID, United Article Type and LOBID are equal for the productivity serial article and in the SDS copy. Any difference between the productivity serial item and the SDS copy is interpreted as a request to update the LOB entity. If not, the referential integrity is broken and the productivity serial article should be investigated further. The main causes of any of these differences are: the item has been created by the user, there is no SDS copy for that item but the property of United Data can be read, and the item has been copied, moved or deleted by the user , the stroke between the Input ID and the United Article ID has been broken; there may be zero, one or more items all related to a single SDS copy and the properties of United Data are readable, an updated meeting request or task request has been received by the user; Corresponding appointment or task has been corrupted (united article). The Entry ID of the Item has been retained but the property of Datos Unidos is no longer readable. A copy of the strange attached article has been received from another user. The property of United Data is not legible and there is no corresponding copy for this article in SDS. A copy or a linked article has been sent to another user, and then it has been sent back. This is a variation of previous possibilities and can not be recognized as a special case. Data corruption may have happened. There is a developed assumption that the United Article ID is unique (primary key) and that the combination of United Article Type + LOBID also unique (secondary key). These restrictions must be reinforced in the SDS database. Of course, in the mail, the Entry ID is also unique. Any item where the property of United Data is not legible or where the duplicate properties stored inside do not match the same properties (United Article ID, United Article Type and LOBID) in the Outlook article is considered corrupted. As a rule it generates, said corrupted article is automatically separated. Any duplicate article (when more than one Outlook article has the same United Article ID) is detected and has already been converted to a new united or unbound article; the original matches the copy of SDS (in the case of moving a copy).

Communication Flow Figure 10 shows another flow of illustrative communication between a series of productivity in a client and a LOB system. The LOB system (1070) can initiate updates to linked articles through control messages (Create, Update and Delete). The formatter service (1080) creates control messages as requested by the LOB system (1070). The control messages are communicated to the productivity series through an email message in an email (1010). A server-side rule moves the control message to a designated (hidden) folder (e.g., control message folder 1020), from which it is collected by a control message processor (1030). The Create, Update and Delete requests are processed immediately; while Query requests are queued in an SDS (1050) and processed by the synchronizer (1060). The Unite / Sweep / Resolver (1040) service (or services that depend on the implementation) is available to: compare all items linked in the mail (1010) against the SDS (1050), and identify inequalities / changes in the united articles. Although not a very common scenario, but it is still an important scenario, the LOB system that recreates all the articles united for a given user is involved. This can be used to fill out the mail with initial items, as well as part of a disaster recovery when some items have been lost or corrupted. A variation of this scenario can be used to update existing joined items to a new union definition (schema). You can also request information about a real state of joined articles (Consultation). Another common use is to send regular mail messages to the user's mail (1010); in this case the synchronization system is not involved. An identity of the sender is used to distinguish valid control messages from unauthorized (or simulated) control messages. The information in the control message can be cryptically encoded in order to protect its privacy. The primary machine is responsible for processing control messages, promoting properties, resolving conflicts and issuing updates to LOB. Maintain SDS and mail synchronized. The secondary machine can be used to update articles linked through Ul. It is also building its own SDS database using synchronization, but with some important differences. The secondary machine is not processing the control message and does not promote ownership during synchronization, nor does the second machine issue changes to the LOB system. When an SDS is built, the secondary machine assumes the data in the mail as correct. Any failure to update an SDS due to referential integrity issues is silently ignored since it is assumed that the primary machine will finally resolve the conflict and that the resolution will be propagated to the secondary machine. The important consequence of these rules is that the SDS on the secondary machine does not contain the entire state of any pending change and therefore can not be promoted to the primary machine. The server may be arranged to maintain a synchronization cache (for example, similar to SDS but excluding aggregate data information) for the purposes of distributing business status responses from the server to the various secondary client machines. Periodically, the server can bring changes to the secondary client, so that secondary clients have the final copy of the relevant SDS data.

Synchronization Subsystem The synchronization subsystem is illustrated in Figure 11, and is composed of the following major components: a Controller (1102), a United Article Handler (1106), a United Article Wrapper, a Sweeper (1112), a Resolver (1109), a Control Message Processor (1110), a Data Provider (1107), and a Synchronizer (1105). The Controller (1102) is a public component used to control the synchronization process. ,. The United Article Manager (1106) is a public component that is used to create and / or have direct access to linked articles. The United Article Wrapper is a public wrapper that encapsulates the productivity serial item as a merged item, or separates the item. In some implementations, the functionality of the United Article Handler (1106) may be included as part of the Controller (1102), or as part of another component. The Sweeper (1112) is an internal component used to find linked items that need to be investigated (since they have changed since the last synchronization occurred). In some implementations, the Sweeper functionality (1112) may be included as part of the Controller (1102), or as part of another component. The Resolver (1109) is an internal component used to investigate linked items and either resolve the changes locally (through property promotion) and / or mark them for full synchronization. In some implementations, the functionality of the Resolver (1109) may be included as part of the Controller (1102), or as part of another component. The Control Message Processor (1110) is an internal component used to process control messages from a verified designed folder (1111) for messages sent by the Formatter. Control messages are processed to update serial productivity items in the case of verbs (Create / Update / Delete or to issue Query commands that will be processed by the synchronizer component.) In some implementations, the functionality of the Message Processor Control (1110) can be included as a controller part (1102), or as part of another component.The Data Provider (1107) is an internal component, which provides access to the SDS data tables (1108). The functionality of the Provisioned Data (1107) can be included as part of the Controller (1102), or as part of another component.

The synchronizer (1105) is an internal component responsible for: Notifying the LOB system when the United Articles were created, updated, or deleted on the client, updating the Synchronization Data Storage (SDS 1108) after successful notifications, processing messages of Query control, and report the status of the synchronization process. In some implementations, the functionality of the Synchronizer (1105) may be included as part of the Controller (1102), or as part of another component. Change Synchronization is illustrated in Figure 12 as presented below. Changes can be made to United Articles on the primary machine (a machine enabled by OBA) or through another external interface such as from a web service (for example, Outlook Web Access, or OWA), or some other clients enabled without OBA and mobile device. Depending on where the changes were made, the system will synchronize those that use slightly different code paths United Article Management: Enabled Customers The user may create, update and delete United Articles in a Client that is enabled for synchronization such as through an addition or connection component. The system detects changes and automatically issues change requests to the LOB System. The request is processed and the LOB System sends back an application success level or failure response. This response is received by the Client and the application business status of the United Article is updated. In the case of new United Articles (for example, created in Outlook), the response of the LOB System is used by the system to correlate the United Article with the LOB Entity.

Management of United Articles: Web Access- The user has access to his mail through web access. United Articles are exposed to the user as standard items. The user can change the standard information in a normal way, but not the extended information. The user can update or delete existing United Articles, but can not create new ones, except in the case of copying an existing United Article (indirect creation). When the user returns to his machine to his primary machine, the changes made through web access are synchronized by the server application (for example, through Microsoft Exchange). The system detects the changes and automatically issues the appropriate change requests to the LOB System.

Handling United Articles: Unauthorized Customers The user can access their email using a productivity serial client that is not enabled. United Articles appear as standard items. The user can change the standard information in a normal way, but not the extended information. The user can update or delete existing United Articles, but can not create new ones. The user then synchronizes with the server application (for example, Microsoft Exchange). When the user returns to their Primary Client machine, changes made to the non-enabled client are synchronized from the server application. The system detects the changes and automatically issues the appropriate change requests to the LOB System.

Handling of United Articles: Devices - Mobile The user has access to his mail through a mobile device. No special support is provided for mobile devices, they are treated just like web access. United Articles are exposed to the user as standard items. The user can change the standard information in a normal way, but not the extended information. The user can update or delete existing United Articles, but can not create new ones. When the user returns to their Primary Client machine, the changes made to the mobile device are synchronized by the server application (for example, Microsoft Exchange). The system detects the changes and automatically issues the appropriate change requests to the LOB System.

United Article Management: Multiple Customers Enabled The user has a "primary" client machine and any number of "secondary" client machines, where each machine has a client application installed that enables synchronization between serial productivity applications and the LOB system. The user can create, update or delete United Articles on any machine. The changes made in one machine will be synchronized to the others through the server application (for example, Microsoft Exchange), but in one mode only the primary machine will be able to synchronize with the LOB System. The "primary" machine is designated at the time of installation; other machines will be considered as "secondary" machines. There is no specific limit for the number of secondary machines that a user may have. When connectivity to the LOB System is available on the primary machine, the system will automatically issue the requested change requests to the LOB System. The described system may be arranged such that a synchronization cache is maintained on the server for the purposes of distributing business state responses from the server to the various secondary client machines. For this example, the server synchronization cache is updated before and after each primary client sweep. The server synchronization cache may consist of all the data in the SDS, excluding the United Data. According to a sweep interval program, the server synchronization cache can be downloaded from the server to each of the secondary client SDSs.

United Article Management: Propagation of Changes When changes to relevant business entities are made in the LOB System, the server application will be notified through the Formatator. A change notification is provided to Qualified Customers who may need to apply the changes to the United Article. Since notification of a change is sent, clients do not need to trigger an update and can immediately respond without waiting for a scheduled synchronization time.

Synchronization Method Figure 13 is a flow diagram of an illustrative synchronization method. Periodically, the System Sweeper process can locate and "flag" United Items that need to be synchronized, where those items are placed in a logical list for synchronization (Synchronization List). For each item in the first Synchronization List, a request to create, update or delete (CUD Request) is generated and stored in the output queue (for example, VOQ 712 in Figure 7). Then a web service call is initiated, so that a connection to the LOB system can be established. The web service call may be successful, fail, or generate a connection exception.

A successful connection is established when a response is obtained from the LOB in response to the web service call. For successful connection to the web service, the system updates the attached article copy in the SDS with the response information. Similar CUD requests are processed similarly for each item in the Synchronization List A failed connection is presented when an exception other than a connection exception is provided by the LOB system in response to the web service call. For a failed connection to the web service, the CUD Request is maintained in the exit queue and marked for retry A retry account for the CUD request can be initialized when the first failed connection is identified Retrievals or reentries will continue until a successful connection is established or the maximum number of attempts allowed through a predetermined interval reach a limit The CUD request is moved to a Cola de So LIABILITIES Failed when the maximum number of allowed attempts is reached without success Additional CUD requests will not be processed unless a successful connection is obtained A connectivity exception may occur when the client has a valid authentication cracker and the detonation to the target server fails. system jumps to the next article in the first Synchronization List when the connectivity exception results from a web service call An illustrative process flow for synchronization is illustrated in Figure 13, as will be described later Processing begins in block 1301, and flows to decision block 1305. In decision block 1305, the productivity synchronization system evaluates the synchronization list to identify any merged items that need to be synchronized between the productivity application application and the LOB application. united is in l To the synchronization list, the processing flows to block 1310, where the system waits for a predetermined moment (e.g., X minutes) before evaluating the synchronization list again. When items joined in the synchronization list are found, the system determines if the maximum number of failed requests has been reached in block 1315 When the maximum number of requests has been reached, processing again flows to block 1310 Alternatively, processing continues to block 1320 where a CUD request is created Continuing in block 1325, the CUD request is placed in an exit request queue such as VOQ 712 of Figure 7 In block 1330, the productivity application synchronization system issues each request in the system exit request queue LOB through a service call such as a web service call Continuing with decision block 1335, the CUD call request is evaluated to determine if the request was successfully issued to the LOB system The processing continues from decision block 1335 to block 1340 (where the synchronization data storage or SDS is updated) when the CUD call request It is successful. Processing flows from decision block 1335 to block 1345, when the CUD call request fails. In some cases, a connection exception is generated and the processing flows from the decision block 1335 to the decision block 1305. In block 1345, the synchronization system for the productivity serial application attempts to redo the CUD call request. In decision block 1350, the system determines whether a response is received from the call request. When the response is successful, processing flows from decision block 1350 to block 1340, where the SDS is updated. When the response fails, processing flows from decision block 1350 to decision block 1360. If no response is received, processing continues from decision block 1350 to block 1355, where the system waits a while-out to expire before of attempting another operation in block 1345. In 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 continues to block 1365, where the CUD request is moved to a failed queue. When the maximum number of reentries has not been exceeded, the system increments an internal retry counter in block 1370, and proceeds to block 1355 to wait for another retry.

Synchronized Reference Items As previously described, unions are created between LOB entities and PS items. Although the synchronization system has no direct access to LOB entities, the SDS maintains a separate copy of what it assumes is stored in the LOB system. creates a union between a LOB entity and a PS article, a copy of the synchronized PS article can be placed in the SDS, so that the PS article can be indexed with LOBID associated with the LOB entity. In other words, a PS article that is associated with a LOB entity can be retriever of the SDS with reference to LOBID Since the PS article can be retrieved with reference to the LOB ID, a number of applications of interest, connections, or other software methods can be implemented which uses the article PS (for example, a recovery workflow system) In one example, a LOB application can communicate to a LOB identifier (for example, or, LOBID) with a serial productivity application through an email communication Email communication includes embedded information that refers to the LOB article For example, LOBID can be embedded in a header associated with the email message E-mail communication does not need to contain (embed or otherwise) the same LOB article, since LOBID refers to the LOB entity. Once the e-mail message is received, the e-mail manager for the productivity series You can identify a specific productivity serial item in a synchronization shadow or a storage of synchronization data that refers to the LOB dentifier. In another example, the user can refer to the productivity serial article with a link (for example, a URL link in any number of ways such as http, HTTP, FTP, FTPS, OBA, etc.) which refers to the LOB identifier associated with a PS article in the SDS: In yet another example, an action box, task table, or other software methodology can be activated when the LOB system sends an email message to the productivity serial system. Once activated, the software methodology can retrieve the serial SDS productivity article by referring to the LOBID, and then act on the productivity serial article. The actions that can be performed in the productivity serial article by the software methodology can result in the creation, update, or deletion of a productivity serial item, which can then be synchronized with the LOB system as described previously. The LOB system can effectively communicate a task to the user of the productivity series by referring to the software methodology and the LOB ID in the email communication. In an illustrative software methodology, the LOB system email communication can communicate a request for the user to complete a review or approval associated with the specific productivity series item that is synchronized with the LOB entity identified with the LOB ID. The communication of electronic mail can be communicated automatically through the LOB system when a final term arrives in the LOB system, or when it is provided by a specific user of the LOB system. The email can be created by the LOB system communicating information (for example, through an XML data representation, through text, through embedded data, etc.) to the formatter, which then cooperates with the EMAIL and Directory Server (see for example, Figure 7) to generate the email message. Email can intensify the need to complete an action that is associated with the productivity serial item, provide additional explanations, etc., where email can refer to tasks in a recovery workflow system. Since the productivity serial application can interpret an embedded link in the email communication as a task, the actual task information can be presented automatically. The user can then select and follow the link to open the task article in the productivity serial application, where the associated synchronized retrieval information can be stored in an XML data representation. Since the LOB identifier can be embedded in a link, any desired action associated with the productivity serial item can be taken by appropriately configuring the handler (for example, a URL handler). Although illustrative embodiments and applications have been illustrated and described, it should be understood that the invention is not limited to the precise configuration and resources described above. Various modifications, changes and variations apparent to those skilled in the art can be made in the arrangement, operation, and details of the methods and systems described herein without departing from the scope of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the appended claims.

Claims (20)

1. A computer readable medium that has computer executable instructions for synchronizing information between a business application line (LOB) and a productivity serial application, instructions comprising: receiving an email push notification with the productivity serial application (720), when a control message (795) is embedded in the push communication email, wherein the control message is an XML data representation (793) of the LOB application (760) that defines changes to an entity LOB; retrieving the control message (795) of the electronic mail with the productivity serial application (720) on the client machine (710); and identifying changes to a linked article in response to the expected control message (795) during a synchronization process (796), such that the linked article is associated with both a productivity serial item (230) and the LOB entity ( 251), wherein the control message (795) indicates at least one of: a LOB entity creation, an LOB entity update, and a LOB entity delete (214).

2. The computer-readable medium according to claim 1, wherein the instructions further comprise, authenticating the electronic mail before retrieving the control message (795), so that simulation of unauthorized issuers is avoided.

3. The computer readable medium according to claim 1, wherein the instructions further comprise, providing a notification to a user when the control message (795) is retrieved from the electronic mail. The computer readable medium according to claim 1, wherein the instructions further comprise, automatically placing the retrieved control message (795) in at least one of a hidden folder and an input message queue (714). The computer-readable medium according to claim 1, wherein the instructions further comprise, storing each linked item in a synchronization data store (SDS, 1050) on the client machine (710). The computer readable medium according to claim 5, wherein the instructions further comprise, identifying changes between the productivity serial application items (230) and the associated LOB entities (251) with the SDS (1050), and placing requests for the identified changes in a virtual request queue (712) for synchronization with the LOB system (250). The computer readable medium according to claim 5, wherein the instructions further comprise, comparing all items linked in an email (1010) for the productivity serial application (720) against the SDS (1050), and detect and fix referential integrity between mail (1010) and SDS (1050). 8. The computer readable medium according to claim 7, wherein the instructions further comprise, making modified articles for further processing, promoting properties for the marked articles; and compare the resulting updated XML data representation against the SDS copy. 9. The computer readable medium according to claim 1, wherein the synchronization process comprises at least one of: identifying and resolving conflicts (1230) associated with the merged article, promoting a property associated with the merged item, downloading of degree a property associated with the attached article, and updating the joined items without promoting properties when the productivity serial application is assigned to a secondary machine (260). 10. The computer readable medium according to claim 1, wherein the instructions further comprise, creating an exit request (212) in response to a change to a serial item of 'productivity on the client machine (210). , wherein the exit request comprises at least one of creating, updating, and deleting (212) associated with the productivity serial article (230); placing the output request in an output queue (712) for synchronization with the LOB application (760); initiate a web service call (792) for the request in the queue to the LOB application (760) in a first time so that the LOB application (760) can retrieve the request to exit the web service when the web service is successfully connects to the LOB application (760); and removing the exit request from the exit queue (712) and updating a synchronization data storage (SDS, 1050) when the web service successfully connects to the LOB application (760). The computer readable medium according to claim 10, wherein the instructions further comprise, initiating a second web service call (792) for the output request in the output queue (712) at a second time when the Web service initially fails to successfully connect to the LOB application. 12. The computer readable medium according to claim 10, wherein the instructions further comprise encoding the request into an XML data representation for reception by the LOB application (760). 13. An apparatus for synchronizing information between a business application line (LOB) and a "productivity serial application," the apparatus comprising: a processor (104); a computer-readable medium (116, 118, 120, 122, 124); an operating environment (126) stored in the computer readable medium and running in the processor (104); and an application (128, 130) operating under the control of the operating environment (126) and operating to perform actions, wherein the application (128, 130) is arranged to: create a request (214) in response to a change to a LOB entity (251), wherein the request comprises at least one of an instruction to create the LOB entity, update the LOB identity, and delete the LOB entity; generate an XML data representation (793) associated with the change in the LOB entity (251); formatting the XML data representation (770) in a control message (794) that is encoded in an electronic mail (780); and push-emailing the electronic mail (780) to the productivity serial application (720) so that changes to the LOB entity (251) can be synchronized (730) with productivity serial application items by extracting the message control (795) of the email. The apparatus according to claim 13, wherein the application is further configured to push the email to another productivity serial application (270) that is present in a secondary client (260). 15. The apparatus according to claim 13, wherein the application is further configured to: receive a web service call (792); extracting an update request (791) from the web service call (792), wherein the update request (791) is associated with a change to a productivity serial application article; and updating a LOB entity in response to the extracted update request, wherein the extracted update request corresponds to at least one of an instruction to create the productivity serial application article, update the productivity serial application article , and eliminate the productivity serial application article. The apparatus according to claim 15, wherein the update request of the web service call (792) is another representation of XML data. The apparatus according to claim 13, wherein the application is further configured to: receive a web service call (792) from the productivity serial application (720), extract a request from the web service call, and create a LOB entity in response to the extracted request. 18. A method for synchronizing information between a business application line (LOB) and a productivity serial application, the method comprises: receiving an XML data representation (793) from the LOB application (760), where the representation XML data (793) identifies changes associated with at least one entity in the LOB application (760); formatting (770) the XML data representation (793) in a control message (740); embedding the control message (794) in an email (780); and communicating by push e-mail (795) to the productivity serial application (720), so that the changes associated with at least one entity in the LOB application (760) can be synchronized with the productivity serial application ( 720). The method according to claim 18, further comprising: receiving another XML data representation (792) from the productivity serial application (720); identify changes associated with at least one article in the productivity serial application of the other XML data representation (792); and updating at least one entity in the LOB application (760) based on the identified changes, such that at least one entity in the LOB application is linked to at least one article in the productivity serial application. The method according to claim 19, wherein the update comprises at least one of: creating, modifying, and deleting at least one entity in the LOB application.