Abstract: User interfaces are defined by metadata for use with productivity suite applications in a wrapped window, a task pain, or some other suitable representation. Data can be bound to a data source in a one-way format such that changes from the data source propagate to property fields in the UI form. Data can also be bound to a data source in a two-way format such that changes from the property field of the UI propagate back to the data source. The data source can be a local cache such as for synchronization between a productivity suite application and a line of business (LOB) application (e.g., CRM applications). A rendering engine is arranged to process the UI and data bindings such that custom event handlers are defined in a code behind assembly format. Productivity suite items are accessible from the code behind assembly through a series of item interfaces.

Abstract: A single virtual image of client information centrally located at an always-on network location for maintaining equivalency among multiple user devices. The image can be accessed by the user devices when coming online to upload and receive changes in the client information. A mid-tier system can be employed as the always-on central location with which the user client machines can communicate to maintain the same set of client information. Services in support thereof include an ownership service for dynamic selection of a designated client machine to take ownership for performing the actions on one client machine and arbitration of duplicate requests, a notification service for allowing data sources to publish cache update instructions to a central place, a roaming service for allowing clients machines to share state with each other, and an encryption service for secure storage and communications of client information.

Abstract: A system and method for enabling supplementary deployment actions to be performed in conjunction with a deployment of an application version. A deployment manager may download one or more supplementary deployment action (SDA) components to a user application cache. In conjunction with performing deployment actions, SDA components may be invoked from the user application cache or from a global application cache. The SDA components may perform actions specific to the application or version of the application, including actions not preconfigured in the deployment manager. An SDA component may be invoked prior to or after the deployment manager performs deployment actions. If an SDA component fails, SDA components that succeeded may be automatically invoked to roll back their actions. SDA components may be used to perform a first install, an update, a roll back, or an uninstall. SDA components may have the privileges of the application and the user corresponding to the user application cache.

Abstract: Versioning and concurrency control architecture of data operations on data of a data source by multiple independent clients of a user. Data operation messages between the clients and the data source are intercepted and tracked for serialization control to a data view instance of the data source. The architecture can be located as an always-on centrally-located system (e.g., mid-tier), accommodate data operations that include create, read, update, delete, and query (CRUDQ) against data sources, and provides support for distributed transactions, locking, versioning, and reliable messaging, for example, for data sources that do not expose such capabilities. A hash is employed for version control and to control changes at the data source. The central system also provides logic for the individual CRUDQ operations, and granular error classification to enable retries whenever possible.

Abstract: Architecture that provides the capability to receive types associate with external data and services and then integrate (or blend) these types into other applications such as office suite applications and collaboration applications. The result is the user is given a complete view of a given business problem and allows the user to complete tasks and plans in a single context. The architecture creates new defined types and blends these new defined types with the host native types of the particular host application (e.g., office application, collaboration application, etc.) so the user can operate from within a single context. Formal and pre-existent business applications, as well as external data sources are seamlessly proxied into the everyday productivity tools and/or collaboration environment to enable the user complete work as a single work stream within a known user experience with expected behaviors.

Abstract: Recurring appointment items in a calendaring application are synchronized and recorded in a backend Line Of Business (LOB) service. Items marked in the calendaring application for time recording are used to create a recurring bound item with extended properties. A sweeper module scans on every run the mailbox for such recurring bound items. Occurrences of bound recurring appointments, which occur between the last scan and the current scan, are determined and detached from the corresponding recurring series, such that standalone bound items, are created for such occurrences that can be recognized by an LOB application. Entries for bound items are retrieved from a client data store and synchronized it with the backend LOB service through a create, update, or delete operation request.

Abstract: Methods and systems of leveraging synchronous communication protocols to enable asynchronous application and line of business behaviors. An application platform may be provided and configured to provide a pending state for any synchronous operation. The pending state may indicate that the operation has not been completed yet. For an application which may know how to track an operation that has a pending state, the application may control when the operation enters and exits the pending state. The application may communicate to the application platform to hold off on other operations dependent upon the pending operation when the pending operation is not complete. For an application which does not know how to track an operation that has a pending state, the application platform may ignore the pending state of the operation and proceed to other operations. Accordingly, the synchronous user experience is preserved where a straightforward, down-level user interface and experience is appropriate.

Abstract: Architecture that maintains the user experience as close as possible to the user experience when dealing with the usual/regular forms and data provided in an office application when dealing with hybrid forms and hybrid data. Synchronization of the hybrid data to single-master and multi-masters systems is accomplished when the associated hybrid client goes offline, changes are made to the hybrid data, and then the client comes back online. For example, where the single-master system is a line-of-business (LOB) server system and the multi-master system is an officer server that employs collaboration capability, the architecture allows office users to access, manipulate, and share LOB entity information using collaborative means, while at the same time, ensuring data and business process consistency for the LOB entity in the LOB system.

Abstract: Architecture for uninterrupted access to business data by enabling work on rich client machines to be stored in a local business data cache that is always available. A dispatching mechanism executes read/write requests against the local cache transparently to a client application, an automatic synchronization mechanism propagates changes bi-directionally when the client goes online and a live connection with the corresponding backend data source is available. A declarative data access model is employed based on operation stereotyping and grouping that enables client applications to transparently execute create, read, update, delete, query (CRUDQ) and association operations against the local cache as if executed against the actual business data source. The architecture supports the offline creation of entities and sets of related entities when the entity identifiers are generated by the business data source and offline navigation of entity associations when foreign keys are not present in the related entities.

Abstract: Recurring appointment items in a calendaring application are synchronized and recorded in a backend Line Of Business (LOB) service. Items marked in the calendaring application for time recording are used to create a recurring bound item with extended properties. A sweeper module scans on every run the mailbox for such recurring bound items. Occurrences of bound recurring appointments, which occur between the last scan and the current scan are determined and detached from the corresponding recurring series such that standalone bound items are created for such occurrences that can be recognized by an LOB application. Entries for bound items are retrieved from a client data store and synchronized it with the backend LOB service through a create-, update-, or delete-operation request.

Abstract: Techniques to manage event notifications are described. An apparatus may comprise a server having an event notification component. The event notification component may have an event agent component to receive a message indicating a change event for line of business (LOB) data, and convert the change event to a defined LOB entity event. The event notification component may have a notification service component to generate a LOB event message for the entity event. The event notification component may have an event database to store the event message in a user event queue. Other embodiments are described and claimed.

Abstract: Techniques for a web services data access layer are described. An apparatus may comprise a client device having an application program, a data access layer, and a client data store. The data access layer may comprise a cache manager component and a queue manager component. The application program may request an operation for an office business entity, with the cache manager component to perform the operation using data stored by the client data store. The queue manager component may store the operation in an operational queue. Other embodiments are described and claimed.

Abstract: Techniques to cross-synchronize data are described. An apparatus may comprise a cross-synchronization component to synchronize multiple data items for different application programs between multiple client devices synchronized using multiple synchronization circuits. The cross-synchronization component may determine whether changes to the multiple data items made at a first client device are propagated to a second client device using consistency information maintained by a consistency group item for a consistency group including the data items. Other embodiments are described and claimed.

Abstract: A single virtual image of client information centrally located at an always-on network location for maintaining equivalency among multiple user devices. The image can be accessed by the user devices when coming online to upload and receive changes in the client information. A mid-tier system can be employed as the always-on central location with which the user client machines can communicate to maintain the same set of client information. Services in support thereof include an ownership service for dynamic selection of a designated client machine to take ownership for performing the actions on one client machine and arbitration of duplicate requests, a notification service for allowing data sources to publish cache update instructions to a central place, a roaming service for allowing clients machines to share state with each other, and an encryption service for secure storage and communications of client information.

Abstract: Versioning and concurrency control architecture of data operations on data of a data source by multiple independent clients of a user. Data operation messages between the clients and the data source are intercepted and tracked for serialization control to a data view instance of the data source. The architecture can be located as an always-on centrally-located system (e.g., mid-tier), accommodate data operations that include create, read, update, delete, and query (CRUDQ) against data sources, and provides support for distributed transactions, locking, versioning, and reliable messaging, for example, for data sources that do not expose such capabilities. A hash is employed for version control and to control changes at the data source. The central system also provides logic for the individual CRUDQ operations, and granular error classification to enable retries whenever possible.