Abstract: When a software component is starting, such as but not limited to a task or a subtask, the component pushes its identification (ID) onto a stack. The component executes its other instructions. If the component completes its instructions so that it can terminate normally, it pops the stack, which removes its ID from the stack. If the component fails, such as by not being able to complete its instructions, it will not be able to pop the stack so its ID will remain in the stack. Another software process can read the IDs in the stack to identify which components have failed and can automatically take a specified action, such as by sending an email message to, sending a text message to, or calling by telephone, a person or persons responsible for that software component.

Abstract: An intelligent conflict detection system. The system provides semantic expression of edits and history-aware conflict detection in a large-scale service allowing multiple users to simultaneously work with the same document, which may result in conflicting edits. When submitted, changes to a version of a document are compared to all versions of the document created since the document was sourced. Edits to documents are expressed as intents describing the changes in terms of an action and object of that action based on a characteristic of the data being edited. Comparing the intent of current edits against the historical intent of the edits made in prior versions originating from the same source document allows the system to intelligently assess whether the edits are in conflict. History-aware semantic analysis results in users being prompted less frequently to resolve conflicts, which improves the user experience.

Abstract: A consistent user view system. The system incorporates any changes made by a user in any views shown to that user even when the changes have not propagated to the partitions supplying the view. The system separates the authority for edits from the replicated storage allowing efficient transactions and linear scalability. Documents are read from view-based partitions of a store. Document writes are written to a document-specific partition in a journal and applied to the store. The system stores a copy of pending changes in a user-specific partition. When a user requests a view, the system checks that user's cache for any pending changes applicable to the view. If any applicable changes are found, the changes are applied before showing the view to the user. Pending changes that have been successfully applied to the store are trimmed from the user-specific partition to free up resources.

Abstract: A scalable eventual consistency system. The system uses logical document journaling to provide eventual consistency across partitions in a large-scale service. The system allows for transactional edits to massively interconnected graphs of documents documents through parallelization without sacrificing linear scalability. The system separates the authority for edits from the replicated storage allowing efficient transactions and linear scalability. All document writes are written to document-specific partitions in a journal where they are queued until the changes are propagated to view-based partitions of a store. By continually checking the journal and attempting to replicate any pending document writes to the store, the system provides eventual consistency without complicated synchronization mechanisms.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: When a software component is starting (305), such as but not limited to a task or a subtask, the component pushes (310) its identification (ID) onto a stack. The component then executes (315) its other instructions. If the component completes its instructions so that it can terminate normally (320), then it pops (325) the stack, which removes its ID from the stack. If the component fails, such as by not being able to complete its instructions, then it will not be able to pop the stack so its ID will remain in the stack. Another software process can then read the IDs in the stack to identify (330) which components have failed and can automatically take a specified action (335), such as by sending an email message to, sending a text message to, or calling by telephone, a person or persons responsible for that software component.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: When a software component is starting (305), such as but not limited to a task or a subtask, the component pushes (310) its identification (ID) onto a stack. The component then executes (315) its other instructions. If the component completes its instructions so that it can terminate normally (320), then it pops (325) the stack, which removes its ID from the stack. If the component fails, such as by not being able to complete its instructions, then it will not be able to pop the stack so its ID will remain in the stack. Another software process can then read the IDs in the stack to identify (330) which components have failed and can automatically take a specified action (335), such as by sending an email message to, sending a text message to, or calling by telephone, a person or persons responsible for that software component.

Abstract: Disclosed herein are systems, methods, and software for facilitating technology upgrades. In at least one implementation, an incomplete upgrade to service units within a service environment is initiated. An upgrade health of each of the service units is evaluated based at least in part on results of the incomplete upgrade. A complete upgrade of the service environment is then initiated based at least in part on the upgrade health of each of the plurality of service units.

Abstract: A line of business data integration (“LOBI”) stack is provided that is configured to store an abstract representation of a mechanism utilized by a line of business (“LOB”) system to return requested LOB data in batches. When a request is received from a client for the LOB data, the LOBI stack utilizes the abstract representation to retrieve the requested LOB data from the LOB system in batches. In this manner, the batching mechanism utilized by the LOB system is abstracted from the client.

Abstract: A computing device having a dynamic metadata model includes an interface module, an algorithm module and a registration module. The interface module includes an interface that defines one or more API functions for obtaining metadata using an algorithm. At least one of the API functions is used with a plurality of algorithms. Each of the plurality of algorithms is associated with a business system. The algorithm module includes one or more algorithms that implement the API functions defined in the interface. The one or more algorithms provide metadata without accessing a metadata database. Each of the one or more algorithms is associated with a business system. The metadata is associated with API functions of the business system. The registration module registers the one or more algorithms on the computing device.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: A secondary location is configured as a recovery service for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the secondary location is automatically updated to reflect a current state of the primary location that is actively servicing user load. Content changes to the primary location are automatically reflected to the secondary location. System changes applied to the primary location are automatically applied to the secondary location. For example, removing/adding machines, updating machine/role assignments, removing adding/database are automatically applied to the secondary location such that the secondary location substantially mirrors the primary location. After a failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: A machine manager controls the deployment and management of machines (physical and virtual) for an online service. Multi-tier server groups are arranged in farms that each may include different configurations. For example, their may be content farms, federated services farms and SQL farms that are arranged to perform operations for the online service. When the multiple farms are upgraded, new farms are deployed and the associated content databases from the old farms are moved to the newly deployed farms. During the upgrade of the farms, requests may continue to be processed by the farms. The farms may be automatically load balanced during an upgrade. As content becomes available on the new farm, requests for the content may be automatically redirected to the new farm.

Abstract: A cloud manager is utilized in the patching of physical machines and virtual machines that are used within an online service, such as an online content management service. The cloud manager assists in the scheduling of the application of software patches to the machines (physical and virtual) within the network such that the availability of the online service is maintained while machines are being patched. The machines to be patched are partitioned into groups that are patched at different times. Generally, the groups are partitioned into a highly available independent groups of machines such that one or more of the groups that are not currently being patched continue to provide the service(s) of the group that is being patched. The machines (physical and virtual) within each of the groups may be patched in parallel.

Abstract: A machine manager controls the deployment and management of machines (physical and virtual) for an online service. Multi-tier server groups are arranged in farms that each may include different configurations. For example, their may be content farms, federated services farms and SQL farms that are arranged to perform operations for the online service. When the multiple farms are upgraded, new farms are deployed and the associated content databases from the old farms are moved to the newly deployed farms. During the upgrade of the farms, requests may continue to be processed by the farms. The farms may be automatically load balanced during an upgrade. As content becomes available on the new farm, requests for the content may be automatically redirected to the new farm.

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: A line of business data integration (“LOBI”) stack is provided that is configured to store an abstract representation of a mechanism utilized by a line of business (“LOB”) system to return requested LOB data in batches. When a request is received from a client for the LOB data, the LOBI stack utilizes the abstract representation to retrieve the requested LOB data from the LOB system in batches. In this manner, the batching mechanism utilized by the LOB system is abstracted from the client.

Abstract: A computing device having a dynamic metadata model includes an interface module, an algorithm module and a registration module. The interface module includes an interface that defines one or more API functions for obtaining metadata using an algorithm. At least one of the API functions is used with a plurality of algorithms. Each of the plurality of algorithms is associated with a business system. The algorithm module includes one or more algorithms that implement the API functions defined in the interface. The one or more algorithms provide metadata without accessing a metadata database. Each of the one or more algorithms is associated with a business system. The metadata is associated with API functions of the business system. The registration module registers the one or more algorithms on the computing device.