System and method for content sharing through external systems

Abstract

The present disclosure relates to systems and methods for content sharing with external systems. Mechanisms are disclosed for sharing managed content with external systems. A sharing module exposes content in a share item and metadata associated therewith to an external system. The share item represents a folder or directory in a repository managed by an information system such as an enterprise content management system. The exposure is made possible through application programming interface (API) calls that are processed by a first sharing module API, a repository API, a second sharing module API, and an external system API. These APIs collectively provide a one-to-one mapping of the communication protocol used by the managed repository and the external system. The share item in the managed repository and the share item exposed to the external system are synchronized, and any conflicts between the two are detected and resolved. Shared content can be sent back to the managed repository, and shared versions are deleted from the external system.

Description

[0001] This application is a divisional of International Application No. PCT / CA2018 / 050825, entitled "SYSTEMS AND METHODS FOR CONTENT SHARING THROUGH EXTERNAL SYSTEMS", filed July 5, 2018, and National Application No. 201880053490.8, which claims priority to U.S. Provisional Application No. 62 / 529,617, entitled "SYSTEMS AND METHODS FOR CONTENT SHARING THROUGH EXTERNAL SYSTEMS", filed July 7, 2017, and U.S. Patent Application No. 15 / 906,846, entitled "SYSTEMS AND METHODS FOR CONTENT SHARING THROUGH EXTERNAL SYSTEMS", filed February 27, 2018, both of which are hereby incorporated by reference in their entireties.

[0002] Cross Reference to Related Applications

[0003] This application claims priority to U.S. Provisional Application No. 62 / 529,617, entitled "SYSTEMS AND METHODS FOR CONTENT SHARING THROUGH EXTERNAL SYSTEMS", filed July 7, 2017, and U.S. Patent Application No. 15 / 906,846, entitled "SYSTEMS AND METHODS FOR CONTENT SHARING THROUGH EXTERNAL SYSTEMS", filed February 27, 2018, both of which are hereby incorporated by reference in their entireties. TECHNICAL FIELD

[0004] The present disclosure relates generally to the field of enterprise information management (EIM). More specifically, the present disclosure relates to EIM systems operating in networked computing environments. Even more specifically, the present disclosure relates to sharing content or any information managed by a restricted storage system, repository, EIM system operating in an enterprise computing environment through an external system operating in a cloud computing environment. BACKGROUND

[0005] Enterprise information management (EIM) is a particular field of technology in information technology (IT). EIM combines many enterprise class systems such as enterprise content management (ECM), business process management (BPM), customer experience management (CEM), and business intelligence (BI). An EIM system can utilize a content server to store and manage, among other things, digital assets of an organization or enterprise, such as content and documents (which are collectively referred to herein as "managed objects"). To protect these managed objects, the content server will operate behind a firewall of the enterprise and can be specially configured so that only authorized users can securely access the managed objects. Typically, the content server is installed on-premises of the organization or enterprise (e.g., the server machine or machine on which the content server is implemented will be physically installed in a building). This is sometimes referred to as "on-prem".

[0006] As businesses continue to grow, so does the need for business users to collaborate and / or share files with external users. Because external users are generally not authorized to access a business's EIM system, they cannot view and / or edit any files managed by the business's content server. When the need arises for an external user to review and / or edit a file, one common option is for a business user to log into the business content server from within the business network where the content server resides, retrieve the file, and share a copy of the file with the external user via email or through a publicly accessible cloud-based storage system.

[0007] Once the copy is shared outside the business network, it is no longer managed by the content server. The content server has no way to track the shared copy, return the shared copy to the content server, and / or update the original file to reflect any changes made to the shared copy. Because this kind of "copy and set free to share" can pose a security risk, the sharing feature can be disabled in the content server to prevent sharing of certain files, folders, directories, etc. However, this means the need to share externally is not addressed. The embodiments disclosed herein can address this need and more. SUMMARY

[0008] It is an object of the present invention to improve EIM systems by providing a reliable and secure way to expose content managed by an "on-premise" EIM system operating in a business computing environment. This object can be achieved in a sharing module running on a feature-rich content server platform in which a content server user can reliably and securely share EIM-managed content and collaborate on that content with external participants through external systems such as cloud-based storage systems. In this disclosure, the term "platform" refers broadly to a specific structure on which multiple software products (i.e., applications) can be built within the same technical framework. In this case, the structure includes both hardware components and software components.

[0009] The embodiments disclosed herein can be implemented on many suitable EIM systems. Documentum, available from OpenText, a Canadian-headquartered company, can be a non-limiting example of a feature-rich ECM platform on which some of the embodiments disclosed herein can be implemented. For purposes of illustration and not limitation, OpenText TM Core (OpenText TMThe term "Core" can be a non-limiting example of an external system (i.e., a system outside of an EIM system or content server operating within an enterprise computing environment, such as a cloud-based storage system operating in a network computing environment outside the enterprise computing environment). Core operates in a cloud computing environment and provides personal cloud storage for securely sharing and collaborating on files. These files are stored by Core in a separate and independent cloud computing environment (e.g., stored by a cloud-hosted service provider such as OpenText). TM (On a tenant server computer in a multi-tenant platform operated by the cloud). Those skilled in the art will recognize that the embodiments disclosed herein are not limited to Core and can work well with any external system, including any third-party cloud storage system operating in a cloud computing environment outside of the EIM system operating in an enterprise computing environment behind its firewall as disclosed herein.

[0010] In today's highly connected world, enterprise users often collaborate with other individuals and organizations for a variety of purposes. This collaboration requires sharing authorized content (e.g., managed enterprise content that has been reviewed and approved for sharing outside the enterprise) in a repository with collaborators at the content-consuming system. Such collaborators would otherwise be unable to access the content due to system limitations. For example, an EIM system operating in the back end of an enterprise computing environment does not connect directly to front-end content delivery applications, such as fax applications. Furthermore, constraints on external users (such as user privileges) can limit how content can be exchanged / shared among collaborative participants. For example, user John might prefer to receive information via fax, but existing EIM systems do not connect directly to fax applications. As another example, user Cathy, as a co-author of an artifact, might want to work on the latest copy of the artifact and might want to use a file sync-n-share system to work from different devices. However, her publisher's repository does not connect directly to an external file sync-n-share application. These limitations and constraints can adversely affect collaboration and reduce productivity / performance.

[0011] Previous solutions attempted to address these issues by allowing users to transfer content out of the repository using external file synchronization and sharing services. However, this required complex, hard-coded custom settings between the single repository and the single external system. Once set up, the single repository and the single external system were tightly coupled—the file synchronization and sharing service could only transfer content between the single repository and the single external system.

[0012] This type of content sharing method can limit the number of content consuming systems (e.g., external systems to which content can be delivered). There are also constraints on the number of repositories from which content can be delivered to these content consuming systems. Another limitation is that it does not provide for the delivery of any metadata associated with the content being shared. Generally, external systems will create their own metadata so they do not use the source metadata.

[0013] In some embodiments, a method for sharing content managed by an EIM system through an external system can include receiving, by a sharing module, instructions to publish a share item to an external system, the share item representing a folder or directory in a managed repository, the sharing module running on a server machine operating in an enterprise computing environment, the managed repository residing in the enterprise computing environment, the external system operating independently outside the managed repository, the server machine having a processor and a non-transitory computer readable medium. The method can further include publishing, by the sharing module, objects in the share item and metadata associated with the objects from the managed repository to the external system. In some embodiments, the metadata associated with the objects is generated in an EIM system managing the managed repository to provide context for the objects. These are sometimes referred to as "source" metadata. Previously, such source metadata was not shared with and / or used by external systems when managed content was shared externally.

[0014] In some embodiments, the publishing by the sharing module can include making a first application programming interface (API) call to retrieve the objects and metadata from the share item in the managed repository; and making a second API call to deliver the objects and metadata to the external system. In some embodiments, the first API call is made through a first sharing module API and a repository API, the first sharing module API interfacing the sharing module and the repository API, the repository API interfacing the first sharing module and the managed repository. In some embodiments, the second API call is made through a second sharing module API and an external system API, the second sharing module API interfacing the sharing module and the external system API, the external system API interfacing the second sharing module API and the external system. The repository API, the first sharing module API, the second sharing module API, and the external system API collectively provide a one-to-one mapping of communication protocols used by the managed repository and the external system.

[0015] In some embodiments, the instructions for publishing are automatically received from the scheduler in a programmatic manner according to a sharing profile defined by an administrator of the managed repository. The sharing profile contains content sharing rules specified by the administrator as applicable to the shared item, the scheduler running on a server machine. The content sharing rules can be characterized as a one-way synchronization rule set or a two-way synchronization rule set.

[0016] In some embodiments, in response to the instructions to publish the shared item to the external system, a graph builder (which can be part of the sharing module) can build a first graph for the shared item. The first graph contains nodes representing objects in the shared item at the time of publishing.

[0017] In some embodiments, after the shared item is published to the external system, the sharing module monitors for any changes to the shared item by performing one-way synchronization or two-way synchronization on demand, continuously, or every predetermined time interval to synchronize the shared item in the managed repository and the shared item published to the external system. The synchronization operation returns updates to the shared item from either the managed repository or the external system, if the sharing profile commands one-way synchronization, or from both the managed repository and the external system, if the sharing profile commands two-way synchronization.

[0018] In some embodiments, the method can further include building a second graph for the shared item based on results from the synchronization operation; detecting any changes to the shared item by comparing the first graph of the shared item and the second graph of the shared item; determining whether any changes to the shared item cause a version control conflict for an object in the shared item; if a version control conflict for an object in the shared item is found, communicating conflicting versions of the object involved in the conflict to a conflict resolver for conflict resolution. In some embodiments, the conflict resolution can include renaming a file extension of a first version of the conflicting versions of the object, thereby changing a file type of the first version; presenting at least the first version of the object to a user through a user interface running on a user device; prompting the user through the user interface to select one of the conflicting versions of the object; and determining a resolved version of the object based on the user selection. The resolved version of the object can then be synchronized back to the managed repository, the external system, or both. This enables the content shared externally to be synchronized with the version residing in the backend. When the need to share content externally no longer exists, the content shared externally can be sent back to the managed repository. After the last synchronization operation, the version published by the sharing module to the external system is deleted by the external system in response to a request from the sharing module. The external system notifies its user(s) that the content in question is no longer shared.

[0019] In some embodiments, the external system can be one of a plurality of external systems connected to the managed repository through the sharing module. Each of the plurality of external systems will have a one-to-one mapping between the managed repository and each external system through the sharing module API, the repository API specific to the managed repository, and the external system API specific to each external system. Likewise, the managed repository can be one of a plurality of managed repositories connected to the sharing module. Each of the plurality of managed repositories will connect to the sharing module through the repository API specific to each managed repository and the sharing module API, such that although the sharing module allows for many-to-many connections between managed repositories and external systems, each pair of managed repository and external system can have a specific one-to-one mapping relationship. This arrangement makes the underlying architecture scalable, adaptive, and flexible.

[0020] One embodiment includes a system including a processor and a non-transitory computer readable storage medium storing computer instructions that are interpretable by the processor to perform a method substantially as described herein. Another embodiment includes a computer program product having a non-transitory computer readable storage medium storing computer instructions that are interpretable by a processor to perform a method substantially as described herein. Many other embodiments are possible.

[0021] These and other aspects of the present disclosure will be better appreciated and understood when considered in connection with the following description and accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the present disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions or rearrangements can be made within the scope of the present disclosure without departing from the spirit thereof, and the present disclosure includes all such substitutions, modifications, additions or rearrangements. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate certain aspects of the application. A more complete appreciation of the application and the scope of its components and operations of the systems provided by the application will be gained as further

[0023] Figure 1 A diagram depicting sharing of content stored in a managed repository in an enterprise computing environment through a sharing module connecting the managed repository with an external system, in accordance with some embodiments disclosed herein.

[0024] Figure 2 FIG. 1 depicts a diagram of a system architecture of an exemplary sharing module, in accordance with some embodiments disclosed herein.

[0025] Figure 3 FIG. 2 depicts a diagram of system components and operational flow of an exemplary sharing module, in accordance with some embodiments disclosed herein.

[0026] Figure 4 FIG. 3 depicts a flowchart illustrating a method for sharing content by an external system, in accordance with some embodiments disclosed herein.

[0027] Figure 5 FIG. 4 depicts a diagram of a distributed network computing environment in which the disclosed embodiments can be implemented. DETAILED DESCRIPTION

[0028] The present application and various features and advantages thereof are more fully disclosed in the following non-limiting embodiments described in conjunction with the accompanying drawings. Descriptions of well-known materials, techniques, components and devices are omitted so as not to unnecessarily obscure the disclosure in detail. It should be understood, however, that the detailed description and specific examples, while indicating some embodiments of the application, are given by way of illustration only, and are not by way of limitation. Various substitutions, modifications, additions and / or rearrangements within the spirit and / or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.

[0029] It is an object of the present disclosure to provide a feature-rich EIM platform operating in an enterprise computing environment in which enterprise users can reliably and securely share and / or collaborate on managed content (e.g., documents stored in a repository managed by an EIM system operating reliably and securely behind the enterprise's firewall in the enterprise computing environment) with users that otherwise cannot access the managed content (e.g., external Core users and / or enterprise users that are not authorized users of the EIM system).

[0030] Sharing content with external participants / collaborators should not burden existing EIM users with having to learn how to navigate and use external systems. For security reasons, interaction between EIM users and external systems should be kept to a minimum. Instead, EIM administrators should control (e.g., through content sharing rules) how or when content will be shared, who can use the sharing privileges, etc. Preferably, sharing content with external participants / collaborators should have minimal or negligible impact on EIM functionality, EIM users' availability to the EIM system / repository, and / or managed documents that have been shared.

[0031] In some embodiments, the target and other targets can be implemented in a shared module that is policy-wise between the repository layer and the external system layer. The shared module can be hosted in a "domicile" in an on-premise enterprise computing environment or hosted in a cloud computing environment.

[0032] The repository layer has one or more repositories that are typically operated in the back end of an enterprise computing environment. These can be any suitable storage systems configured to store managed objects, including managed content such as files, documents, applications, and any digital assets owned by the enterprise. These storage systems can be used and / or managed by various enterprise software systems, including various types of EIM systems, e.g., OpenText Content Server, Documentum, ApplicationXtender (AX), etc. TM

[0033] The external system layer has one or more external systems that the shared module connects with. As discussed above, systems that are external to the repositories managed by the EIM system can be on-premise external systems or cloud-based external systems. The external systems have the necessary hardware (e.g., server machine(s)) and software (e.g., cloud or web-based user interfaces) and storage(s) accessible to user devices, each of which has its own data storage, such as a non-transitory computer-readable medium.

[0034] As discussed above, in some cases, an enterprise user can need to collaborate and / or share a file with an external user. For example, an employee "engineer" of an enterprise can be trying to create a design specification for a new pump that will be delivered to a customer. The pump specification document is stored in a repository managed by Documentum that is owned by the enterprise and operated on-premise. However, the engineer needs some input from an external user "contractor" who will supply parts for the pump. The contractor can not have access to the engineer's document in the Documentum repository, but the engineer needs the contractor to be able to edit and change the pump specification document to include / update information about the parts supplied by the contractor. To resolve this dilemma, the engineer can copy a copy of the pump specification document stored in the Documentum repository and upload the copy to an external system accessible to the contractor. Additionally or alternatively, the engineer can send a copy of the pump specification document to the contractor via email.

[0035] ​Once a copy of managed content (e.g., in the above example, the pump specification document) is taken outside the enterprise and shared (e.g., via email and / or uploaded to an external system), it is no longer managed by the ECM system (e.g., in the above example, Documentum). Thus, an external user (e.g., in the above example, the contractor) can freely view, modify, copy, store (e.g., in storage on the external system and / or in storage on the external user's device), and even share with other users who might otherwise not have access to the managed content (e.g., in the above example, the engineer's document) stored in the repository. Because the shared copy is not stored in the repository, the ECM system has no way to track the shared copy, return the shared copy to the repository, and / or update the original file to reflect any changes made to the shared copy.

[0036] For an enterprise (or any entity with content management needs), this kind of "copy and set free to share" creates a security risk. Thus, the sharing feature is typically disabled or turned off by default in EIM systems to prevent unauthorized sharing of certain files, folders, directories, etc. An administrator of the EIM system can enable sharing and assign sharing privileges to EIM users through an administrator user interface ("UI") of the sharing module.

[0037] Continuing with the above example, assume that the engineer is given sharing privileges to share the pump specification document stored in the Documentum repository with the contractor via a designated external system, such as Core. The engineer can place the pump specification document in a folder in the Documentum repository designated for sharing and provide information identifying the contractor (e.g., information identifying an external system user with whom an EIM user shares managed content), e.g., the contractor's email address. In this example, the engineer is the "sharing" user and the contractor is the "shared" user from the perspective of the sharing module. Alternatively, the engineer can designate a folder containing the pump specification document in the Documentum repository as a shared item that should be published to Core (or multiple external systems, as explained below) and accessible to the "shared" user(s).

[0038] A Documentum administrator can specify, through the administrator UI, a sharing profile to the sharing module that contains a list of shared items (e.g., a specified folder or directory in the Documentum repository) subject to certain content sharing rules (e.g., content sharing rules governing when content in the shared item will be published or otherwise externally shared, when synchronization will occur, how often synchronization will occur, whether it is one-way or two-way synchronization, when shared content will be sent back to the repository, etc.). Such sharing profiles are created and maintained through the administrator UI. The sharing and synchronization functionality of the sharing module, described further below, can be implemented as a sync-n-share service that can be included in a number of front-end user applications (e.g., client applications of the EIM system).

[0039] Using Core as an example of an external system, when content in a shared item in the Documentum repository is published by the sharing module to Core, everything in the shared item is provided to Core along with information identifying the "shared to" user(s) and the corresponding role(s). Depending on the role assigned to the shared to user, the shared to user is only allowed to view (e.g., as a viewer) or edit (e.g., as a collaborator or contributor) the shared content. Core can store the shared content (e.g., in a storage location associated with the "shared to" user(s)), notify the "shared to" user(s) of the shared content, and return an identifier(s) (used internally by Core) associated with the shared content to the sharing module. The unique identifier generated by Core that internally identifies the copy can be stored by the sharing module in a database local to the sharing module for synchronization purposes. Core is operable to notify any and all participants associated with the shared content, and to handle registration of any new Core users.

[0040] At this point, the shared content in the Documentum repository is identical to the shared content in Core (i.e., the content is shared between the Documentum repository and Core). Depending on the sharing profile of the shared content, the shared content can be subject to one-way or two-way synchronization performed by the sharing module. Synchronization can occur continuously or at time intervals.

[0041] In one-way synchronization, changes to the shared content can only be made on either the repository side or the external system side. In two-way synchronization, changes to the shared content can be made on both the repository side and the external system side. That is, in two-way synchronization, any modifications to the version of the shared content in the external system by the external recipient can be checked back into the repository. In some embodiments, modifications to the version of the shared content in the repository are also allowed. However, in one-way synchronization, only one of the versions of the shared content can be modified or changed. In some embodiments, changes to the version of the shared content in the repository are moved to the external system, but changes to the version of the shared content in the external system are not allowed (i.e., the version of the shared content in the external system is read-only).

[0042] In some embodiments, once shared / published, the version of the shared content in the repository is prevented from being changed (i.e., the version of the shared content in the repository becomes read-only when it is shared externally), and changes to the version of the shared content in the external system are moved back to the repository. This scenario is illustrated in the following example.

[0043] Suppose the engineer shares the pump specification document with the contractor through Core with one-way synchronization. This means that, in this example, once the shared item stored in the Documentum repository is published to Core for the contractor to edit, the pump specification document becomes read-only and changes to it can only be made through Core. This means that the engineer (or any user of Documentum) cannot modify the pump specification document stored in the shared item in the Documentum repository, but the contractor (and the engineer, if the engineer is also a user of Core) can edit the copy through Core.

[0044] When the contractor has finished their input to the copy stored in Core, any final changes are synchronized back to the Documentum repository by the sharing module to update the pump specification document. The copy stored in Core is then deleted. This process is referred to as check-out. The check-out of the shared content can be triggered by the "sharing" user (e.g., the engineer) or content sharing rules set forth in the sharing profile associated with the shared content (e.g., content sharing rules specifying a check-out date, a time limit for external content sharing, or conditions under which the access of the "shared" user to the shared content is revoked).

[0045] The skilled artisan recognizes that in another example of one-way synchronization, the copy of the pump specification document stored in Core can be read-only so that the contractor can view, but not change or modify, the copy of the pump specification document stored in Core. Conversely, changes are allowed through Documentum (e.g., by an engineer or authorized user of Documentum), which are then synchronized by the sharing module to Core to update the copy of the pump specification document stored in Core.

[0046] As discussed above, enabling and managing external sharing from an ECM system to external systems outside the ECM system is very difficult. This is because enterprise file synchronization and sharing (EFSS) is a very complex function, and requires complex integration between the repositories inside the enterprise and the endpoint systems outside the enterprise, as well as lengthy user setup for all the parties involved. The sharing module disclosed herein can significantly reduce this complexity, and likewise minimize the impact on existing repositories and ECM systems. The sharing module enables ECM system repositories to connect to external systems without the need for a fixed connection between the ECM system repositories and the external systems. This is further explained below with reference to Figure 1

[0047] It is noted here that while the above examples describe sharing managed content between employees of an enterprise and contractors outside the enterprise, sharing with internal users will also work seamlessly. That is, users inside the enterprise computing environment can share documents with internal users who are also members of the external system. Thus, one aspect of the present invention is to utilize the external system as an extension of the EIM system that resides in the enterprise computing environment and operates behind the enterprise's firewall. This extension enables sharing from the managed repositories, and enables the use of the external system as a secure and user-friendly collaboration platform to provide access to the shared documents to participants (both outside and / or inside the enterprise). For example, in a cloud-hosted external system such as Core, participants (both internal and external) can easily access Core, and collaborate on documents through Core, using Core's web client, mobile client, and desktop client app running on disparate user devices.

[0048] ​To ensure security, all communications between the sharing module and external systems can utilize Representational State Transfer (REST) protocol. In some embodiments, the sharing module can utilize the REST layer of the external system as a chosen API for server-to-server interactions, such as user lookup, sharing initiation, sharing revocation, etc. In some embodiments of one-way synchronization, the sharing module makes all outward calls (e.g., REST API calls) to the external system. In such cases, no inward connections from the external system back into the sharing module can be needed. In some embodiments, sharing scenarios can be manually driven by an end user, executed by the sharing module. In some embodiments, sharing scenarios can be automatically executed by the sharing module in a programmed manner through a rules-based engine that executes rules set forth in a sharing profile(s) stored in a database (e.g., a local database) accessible to the sharing module.

[0049] In some embodiments, the sharing module (also referred to herein as a "sync-n-share connector") includes a new type of adapter (also referred to herein as a "connection interface") that resides between the repository layer and the sharing module, and between the sharing module and the external system layer. The sharing module enables moving content between managed repositories and external content consumption points (e.g., Core, OneDrive, Google Drive, and / or any cloud-based storage solution / system).

[0050] The embodiments described below utilize a new approach to enable enterprise users to share content with collaborators within and / or outside of an enterprise or organization to a target population. The new approach is implemented in a new architecture in which a standalone sharing module (also referred to as a centralized content delivery bus or controller, file sync-n-share connector, or synchronizer) can connect multiple repositories to multiple external systems. On one hand, the sharing module connects to one or more repositories through a layer of adapters referred to herein as repository adapters. On the other hand, the sharing module connects to one or more external systems through a layer of adapters referred to herein as external system adapters. Figure 1 Examples of the new architecture are illustrated in the following figures.

[0051] In Figure 1In the example of FIG. 1, the architecture 100 includes a sharing module 110 that interfaces or otherwise connects the managed repositories 150, 160, 170 with the external systems 180, 190 through repository adapters 120 and external system adapters 130. Each repository adapter includes a repository API (e.g., 152, 164, 176) and a sharing module API (e.g., 122, 124, 126). The repository API is configured to communicate with the corresponding repository, and the sharing module API is configured to communicate with the sharing module 110. Likewise, each external system adapter includes a sharing module API (e.g., 112, 132) and an external system API (e.g., 182, 192). The external system API is configured to communicate with the particular external system, and the sharing module API is configured to communicate with the sharing module 110.

[0052] As such, the repository adapters 120 represent a first interface layer between the sharing module and the content repositories of the information management (IM) systems operating in the enterprise computing environment, and the external system adapters 130 represent a second interface layer between the sharing module and the external systems operating in a network computing environment external to the enterprise computing environment.

[0053] The first and second interface layers each have a pair of APIs, with each API configured for a particular function. In the first interface layer, one API is configured to communicate with the content repository, and the other API is configured to communicate with the sharing module. In the second interface layer, one API is configured to communicate with the sharing module, and the other API is configured to communicate with the external system. That is, as shown in FIG. 1, the first interface layer has a pair of APIs for each connection / interface between the content repositories and the sharing module. Similarly, as shown in FIG. 1, the second interface layer has a pair of APIs for each connection / interface between the sharing module and the external systems. Figure 1 Figure 1

[0054] ​​In the architecture 100, there are no fixed connections between the managed repositories and the external systems. Rather, through the sharing module, many-to-many content sharing connections are possible between the managed repositories and the external systems, with each pair of managed repository and external system being a one-to-one mapping. In this way, a new managed repository can be easily added to the architecture 100 by interfacing it with the sharing module (independent of any external system) through a pair of APIs, one for communicating with the new managed repository and one for communicating with the sharing module. Likewise, an external system can be easily added to the architecture 100 by interfacing it with the sharing module (independent of any managed repository of the backend) through a pair of APIs, one for communicating with the external system and one for communicating with the sharing module. The skilled person realizes that the architecture 100 is scalable and can easily be adapted to accommodate multiple managed repositories (managed by the same EIM system or different EIM systems) and multiple external systems.

[0055] Before describing the sharing module in detail, it can be helpful to understand the file sync-n-share service that the sharing module provides. Example use cases can include, but are not limited to, the following:

[0056] Use Case 1 : Collaboration through the file sync-n-share service

[0057] Enigma is a publishing company that publishes magazines on public health care. Jane is an employee of Enigma and works as an editor at Enigma. Jane collaborates with a group of reviewers at Enigma to review the magazines that Enigma publishes. Bob is one of the reviewers for Enigma and works from home.

[0058] Enigma stores drafts and other versions of these magazines in a repository (e.g., repository B in Figure 1 Only Enigma's employees are given access to the repository. The repository is connected with an external file sharing system (e.g., external system 180). The user interface for the magazine library provides Jane with the ability to select and push a draft magazine to a specific recipient in the external file sharing system (through the repository adapter 120, the sharing module 110, and the external system adapter 130). To do so, Jane uses the file sync-n-share service to pick the content she wants Bob to review, selects "share" and identifies Bob as a reviewer for that content, the magazine is now available for Bob to view in the external system also by using the file sync-n-share service. Once Bob has completed the review, Jane dispatches the content back into the repository.

[0059] Use Case 2: Sending of Managed Content as a Fax

[0060] Modicum is a mortgage intermediary that provides mortgages to qualified applicants. Modicum stores mortgage applications and associated collateral in an application repository. Modicum serves its customers through its onsite agents. Modicum arranges mortgages for its customers through a network of its lending partners. Anita is an onsite agent of Modicum who works closely with Leon (a lending partner) and is now working on Meera's mortgage application.

[0061] Throughout the time period that Meera's mortgage application is being processed, Modicum's agents fax various documents to the applicant for signature and also receive faxes of signed documents from the applicant. These documents are stored in the application repository at Modicum. Such applications and associated collateral are typically shared with one or more lending partners to get the best deal for the customer. The lending partners and the mortgage intermediary perform the exchange of documents through a fax network.

[0062] Anita uses the web interface of the mortgage software system to review all the applications that she is working on. The mortgage software system is configured with the file sync-n-share service provided by the architecture 100. Anita believes that Leon can provide the best deal for Meera and contacts Leon. Leon wants to see the associated collateral and verify that these documents are checked by Meera. Since the repository at Modicum is connected with the cloud fax system through the file sync-n-share service provided by the architecture 100, Anita can use the same web interface that implements the file sync-n-share service to fax Meera's mortgage application and associated collateral to Leon.

[0063] Use Case 3: Publication of Content and Metadata for a Portal

[0064] Pure Pipes sells pipes and flanges. The sales team of Pure Pipes uses their enterprise resource planning (ERP) system to manage the sales pipeline and opportunities. The ERP system also provides links to pricing information and product catalogs for the different products sold by Pure Pipes. The sales team relies on the catalog to make product fitment and offer any discounts to their customers.

[0065] The product catalog and discounts at Pure Pipes are managed through a pricing and packaging workflow in the company. Once approved in the pricing and packaging workflow, the product catalog is promulgated through the ERP system. Pure Pipes uses an EIM system to manage the pricing and packaging workflow. The approved product catalog is stored in a "product catalog" repository. The product catalog repository is connected to the ERP system in a similar arrangement as the arrangement of the architecture 100. In this example, the ERP system is an external system in the sense that it is external to the product catalog repository from the ERP system.

[0066] Once connected, each time a product catalog is approved in the EIM system, it is published to the ERP system along with the product catalog's associated metadata. The sales team can now start working with the latest product catalog and price list and be aware of the various discounts available. The metadata published along with the product catalog makes it easy to search and sort the product catalog.

[0067] As this example illustrates, an external system in the present disclosure can refer to a content consuming system operating within the same enterprise computing environment in which the content provider system (e.g., the managed repository) resides, or a content consuming system operating outside the enterprise computing environment in which the managed repository resides. In addition to connecting complex enterprise software systems, embodiments can also connect applications that would otherwise not directly communicate and / or share content with each other.

[0068] Use Case 4: Publication of content and metadata for custom applications

[0069] The citizen health insurance (CHC) covers the medical needs of the citizens of Pandora. The CHC stores all patient medical histories (patient records) in a patient health record (PHR) content repository. Healthcare providers can access patient records in the PHR content repository using a clinical patient record (CPR) software application running in their laptop computers. The PHR system is connected to the CPR system in a similar arrangement as the arrangement of the architecture 100. The CHC mandates that patient records are only available on the CPR for a one-week period before and after an appointment is scheduled, and all content related to the patient should be removed from the healthcare provider's laptop after that period.

[0070] Peter (a citizen of Pandora) is consulting with Dr. Dean (his family doctor). Dr. Dean has referred Peter to plastic surgeon Dr. Olaf. Peter has made an appointment with Olaf for next Friday. A week before the appointment, PHR pushes Peter's X-ray and MRI records to CPR (in the form of automatic sharing based on a rules-based engine). Dr. Olaf is able to access the medical records for the upcoming appointment with Peter. The metadata associated with the automatic sharing allows CPR to organize the X-ray and MRI images into clear categories and helps Dr. Olaf efficiently schedule the appointment with Peter.

[0071] As illustrated in the above use case examples, the embodiments disclosed herein can facilitate content exchange between different content repositories and external systems that consume, collaborate on, and store content. Benefits and advantages may include:

[0072] Content previously stored in restricted repositories can now be made available for expanded demographic use. Metadata published (shared) along with the content adds context to the shared content. The capabilities and feature sets of each connected system can be exposed to various applications.

[0073] As mentioned in the examples above, the standalone shared module approach can automatically push or "publish" managed content to content consumption systems outside the managed repository. In some embodiments, this is achieved using rule-based analytics and synchronization.

[0074] like Figure 2 As shown, the administrator can access the sharing module 210 and create rule sets 223 through the management console 221. Rule sets 223 can specify how the sharing module 210 can programmatically and automatically perform sharing. Figure 2 In this example, both the shared module 210 and the managed repository 260 (which can be a content repository, content server, etc. managed by the EIM system) reside in the enterprise computing environment 200, while the external system 280 operates in a cloud computing environment outside the enterprise computing environment 200. However, in some cases, the external system 280 may also operate within the enterprise computing environment 200, but outside of (and independently of) the managed repository 260. Furthermore, any cloud-based storage system can be an external system. An external system can be any system operating in a network computing environment outside the enterprise computing environment 200.

[0075] exist Figure 2In the example of FIG. 2, the managed repository 260 is communicatively connected with the repository connector interface 224 of the sharing module 210 through a repository-specific API 264, and the external system 280 is communicatively connected with the external system connector interface 212 of the sharing module 210 through a REST API 282. Separately, the management console 221 can operate to issue API calls to the sync-n-share controller or connector 221 through a sync-n-share API 225.

[0076] In some embodiments, the sync-n-share connector 221 can implement the execution logic of the sharing module 210 (which can include a rules-based engine configured to apply the ruleset 223), and store tracking information (e.g., information identifying shared items (such as content files or objects), users of the external system, roles granted to users of the external system by users of the managed repository, changes to shared items, etc.) in a local database 227 (local to the sharing module 210). The components of the sync-n-share connector 211 are further described below with reference to Figure 3

[0077] In some embodiments, the connector interfaces 212 and 224 of the sharing module 210 include implementations of the connection interfaces that define how to connect to the sharing module 210. As a non-limiting example, in Java TM , an "implements" clause can be included in a class definition to declare a class that implements an interface. The class can then be used to implement multiple interfaces, for example, by using the "implements" keyword followed by a comma-separated list of the interfaces that are implemented by the class. Such implementations are known to those skilled in the art, and are not further described herein.

[0078] Here, each adapter used by the sharing module 210 can be an implementation of a connection interface defined in the sharing module 210. Each such implementation (instance of a connection interface) can correspond to a one-to-one relationship between the sharing module 210 and a repository (or between the sharing module 210 and an external system). To this end, the sharing module 210 can be characterized as an "interface" between a content-consuming system and a managed repository in the adaptive content sharing architecture.

[0079] The extensible and adaptive content sharing architecture described above with reference to Figure 1 and Figure 2 may be implemented in many ways. Figure 3 An example of an adaptive content sharing architecture 300 is illustrated in FIG. 3. In Figure 3 ​In the example of FIG. 3, the "interface" (or independent sharing module) 310 can have a management UI 321, connector agents 382, 364, and a synchronizer 340. Although the interface 310 is shown as interfacing with one content repository 360 and one external system 380, this is for illustrative purposes only. Similar to the discussion above with respect to FIG. 2, the interface 310 can be readily configured to interface or otherwise connect with multiple repositories and multiple external systems, where each connection between a managed repository and an external system has a pair of connector agents implemented for the respective managed repository and external system to provide a one-to-one mapping between the managed repository and the external system. Figure 1

[0080] Each repository adapter (e.g., repository adapter 363) can be configured to map common taxonomy languages (e.g., a graph built by a graph builder 342 of the synchronizer 340). This mapping can be triggered by an analyzer 344 as a result of changes made on one side (one-way synchronization) or both sides (two-way synchronization) of the synchronizer 340. The changes can be caused by a technical need (e.g., versioning, editing, technical changes, etc.) at one repository (e.g., repository 360) or multiple repositories.

[0081] On the content consumption side (e.g., external system 380), a content consumption adapter can be utilized. This tier (or layer) adapter can (through configuration) map to the protocols (e.g., communication protocols) required to provide content handoff at each content consumption system connected to the interface 310. Additionally, the analyzer 344 can operate as a content taxonomy module, and along with the connector agents (e.g., connector agent 382 for external systems, connector agent 364 for repositories), the adapter (e.g., repository adapter 363) and the connector interfaces (external system connector interface 312 and repository connector interface 362 specific to the synchronizer 340) can provide the ability to find and deliver desired content and its associated metadata, such as associated document identifiers and / or object identifiers (e.g., DocID, ObjectID, etc.).

[0082] In some embodiments, repository (source) metadata is streamed with the content. As discussed above, external systems generally create their own (target system) metadata, so they do not use source metadata. With the present invention, users can now consume the ability of other attached content consumption systems (e.g., EFSS, fax, etc.) from within the application they are using. The ability to share content can be integrated with existing applications and / or workflows. Metadata delivered along with the content can provide context to published content and derive relevant benefits.

[0083] ​In some embodiments, the management UI 321 is communicatively connected to a local database 327 that stores a sharing profile 329. An administrator can set content sharing rules that apply to the sharing profile. These are not user profiles. Each sharing item has a set of rules. A sharing item can represent a folder or directory in the managed repository or any data source selected by the administrator. Different sharing items can have different sets of rules, or share the same rules, that govern when and how content can be shared. The rules can also specify content types. For example, a rule can specify that a sharing item should only have PDF files.

[0084] A sharing item scheduler 331 can also reside on the local database 327 and can contain a schedule that specifies how and when content can be automatically shared in a programmed manner in accordance with the sharing profile or rules 329. The sharing item scheduler 331 can also be used to schedule when synchronization will occur, but the type of synchronization is determined by the type of rule set (e.g., one-way or two-way synchronization) that applies to the sharing item being synchronized. The instructions received by the management UI 321 from the administrator are passed through the sharing item scheduler 331 to the synchronizer 340 in the form of a list of sharing items. The list of sharing items can contain information about what folders (one sharing item) of files can be shared in accordance with the rules that apply to the sharing item.

[0085] In response, the graph builder 342 of the synchronizer 340 is operable to build an object graph for each sharing item in the list of sharing items received from the sharing item scheduler 331. The graph is used by the synchronizer 340 to track changes to objects in the corresponding sharing item. This is further described below.

[0086] Once a sharing item (e.g., a folder) in the managed repository (e.g., in the managed repository 360) is designated (e.g., by the management 321) to be shared by an external system (e.g., the external system 380), everything in the sharing item is published from the managed repository to the external system through the interface 310. More specifically, the content and its associated metadata can be retrieved by the synchronizer 340 from the managed repository 360 through the connector agent for the repository 364, the repository adapter 363, and the repository connector interface 362, and provided to the external system 380 through the external system connector interface 312 and the connector agent for the external system 382.

[0087] As discussed above, once a shared item is published, the synchronizer 340 can operate to monitor and determine whether any changes have been made to the shared content. The determination of whether any changes have been made to the shared content can be made by polling. In some embodiments, the polling can be triggered by a one-way synchronization or a two-way synchronization. Whether a one-way synchronization or a two-way synchronization is performed can depend on whether a one-way synchronization rule set or a two-way synchronization rule set applies to the shared item that is to be synchronized. For example, if the one-way synchronization rule set provides that only the version of the shared content in the external system 380 can be modified (e.g., the version of the shared content in the managed repository 360 is locked from editing), the synchronizer 340 can operate to ping the external system 380 for updates on the shared item. When this occurs, the graph builder 342 can operate to build another graph for the shared item. The two graphs built by the graph builder 342 for the same shared item at different times are compared by the analyzer 344 to detect any discrepancies.

[0088] In some embodiments, when a change to a shared item is detected, the analyzer 344 operates to determine whether any conflicts exist (e.g., what files in the shared item have been changed since the last synchronization (publication), what the changes are, etc.). For example, if a file name has been changed by a user in the external system 380 from "XYZ.doc" to "ABC.doc", the managed repository 360 will not recognize "ABC.doc". The analyzer 344 can operate to communicate its findings to the conflict resolver 346. The conflict resolver 346 can operate to find a resolution that corrects the version mismatch.

[0089] Version mismatches can also occur in a two-way synchronization scenario. That is, the shared content can be modified by a user using the external system 380, a user using the managed repository 360, or a user on both sides. The synchronizer 340 can operate to poll the list of shared items from the local database 327 and also poll the external system 380 for updates on the shared items that have been published from the managed repository 360 to the external system 380.

[0090] Assume that a file in a shared item ("XYZ.doc" version 1.0) subject to a two-way synchronization ruleset is first published from the managed repository 360 to the external system 380. Thereafter, a user of the external system 380 creates a new version of the file in the external system 380 and names it "ABC.doc". At this point, the managed repository 360 has no version of the file named "ABC.doc". Meanwhile, a user of the managed repository 360 updates the file ("XYZ.doc" version 2.0) stored in the managed repository 360. By analyzing the graphs built by the graph builder 342 at different times for different systems for a shared item (in this example, two graphs are built for the managed repository 360 and one graph is built for the external system 380), the analyzer 344 is operable to determine that the shared content in the managed repository 360 ("XYZ.doc" version 1.0) has changed (to "XYZ.doc" version 2.0) in the managed repository 360 and that the shared content in the external system 380 has been modified to "ABC.doc". This detection is possible by traversing each graph and comparing the nodes (objects) in the respective graphs.

[0091] Because the file name has been changed, the managed repository 360 does not recognize the file. Likewise, because the file in the managed repository 360 has been updated to version 2.0, the external system 380 does not recognize the updated file. Thus, the updated file (version 2) in the managed repository 360 needs to be synchronized with the external system 380 and the file with the modified name needs to be synchronized from the external system 380 to the managed repository 360. This is an example of two-way synchronization. The analyzer 244 can identify conflicts such as these and pass them to the conflict resolver 346.

[0092] In some embodiments, the conflict resolver 346 is operable to handle finding a resolution to the conflicts detected by the analyzer 344. In some embodiments, the conflict resolver 346 can create a new object or conflict file. The conflict file can have a specific file type, for example, a specific file extension (e.g., ".conflict"). As a non-limiting example, the conflict resolver 346 can change the extension from "ABC.doc" to "ABC.conflict" and send the "ABC.conflict" file to the user (or notify the user) who can then review and resolve the conflict. These mappings, conflicts, and tasks 352 are executed by the conflict resolver 346 in accordance with the task scheduler 354. The executor 356 is a handler for the conflict resolver 346.

[0093] Figure 4A flowchart depicting an example method for content sharing with an external system in accordance with some embodiments disclosed herein is illustrated. In some embodiments, the method 400 can include receiving instructions to publish a shared item by a sharing module included on a non-transitory computer readable medium (401). As discussed above, a shared item can represent a folder or directory in a managed repository. The managed repository can be managed by an EIM system operating in an enterprise computing environment.

[0094] The sharing module can implement embodiments of the sharing module 110, the sync-n-share connector 211, or the synchronizer 340 described above. The instructions to publish a shared item can be received through an administrator UI, such as the administration console 221 or the administration UI 321. The instructions can be stored in a local database accessible to the sharing module, such as the database 227 or the database 327, and can be provided to the sharing module using a scheduler, such as the shared item scheduler 331. The instructions can include a sharing profile for the list of shared items (e.g., the sharing profile 329) and content sharing rules defined by an administrator as applicable to the list of shared items (e.g., the rule set 223).

[0095] In response, a graph builder (e.g., the graph builder 342) can build a graph for the list of shared items based on each shared item (403). Each graph includes objects representing files in a particular shared item and their relationships. The graph builder can be part of the sharing module.

[0096] The sharing module then publishes the shared items to the external system as described above (405), publishing everything in the shared items, including the files and metadata associated with the files. For example, when a user of the EIM system places a file in a shared item, the publishing by the sharing module to the external system can include providing information identifying the user of the external system and a role granted by the user of the EIM system to the user of the external system.

[0097] In response to user instructions (e.g., user instructions to update a shared item) or automatically (e.g., according to a scheduled event), the sharing module can operate to communicate with the managed repository and / or the external system and obtain (synchronize) a current version of the shared item (407). Whether to communicate with the managed repository, the external system, or both, can depend on whether the shared item is subject to a one-way synchronization rule set or a two-way synchronization rule set.

[0098] As discussed above, communication between the sharing module and the managed repository is through two special APIs - the sharing module API and the repository-specific API. The sharing module API is configured to interface between the sharing module and the repository-specific API. The repository-specific API is configured to interface between the sharing module API and the managed repository. Likewise, communication between the sharing module and the external system is through two special APIs - the sharing module API and the external system-specific API. The sharing module API is configured to interface between the sharing module and the external system-specific API. The external system-specific API is configured to interface between the sharing module API and the external system.

[0099] For each shared item that has been synchronized back to the sharing module, the graph builder is operable to build a new graph (409). The analyzer of the sharing module (e.g., analyzer 344) is operable to compare graphs built for the same shared item at different times (e.g., when the shared item was first published to the external system, and when the shared item was synchronized back to the sharing module from the external system or the managed repository), and / or graphs synchronized from different sources. As described above, the analyzer can be operable to detect any changes made to content in the shared item (411), and determine whether any conflicts caused by such changes exist (413). If so, the analyzer can invoke the conflict resolver (e.g., conflict resolver 346) to resolve any conflicts found by the analyzer (e.g., version mismatches). In turn, the conflict resolver can be operable to handle versions of the same file (e.g., by creating a conflict file with a special file extension) for conflict resolution (415). For example, the conflict resolver can prepare a request for the user of the managed repository (e.g., the owner of the file in dispute) containing information about the two versions and / or links to the two versions to decide which version, if any, is to be stored (synchronized) back to the managed repository (417). The correct version is then synchronized to the backend to update the version in the managed repository (419).

[0100] Figure 5 A diagram depicting a distributed network computing environment in which the disclosed embodiments can be implemented. In Figure 5 In the example of network computing environment 500, network 514 can be bidirectionally coupled to user computer 512, user computer 515, server computer 514, and server computer 516. Server computer 514 can be bidirectionally coupled to database 538, and server computer 516 can be bidirectionally coupled to database 518. Network 530 can represent a combination of wired and wireless networks that network computing environment 500 can use for various types of network communications known to those skilled in the art.

[0101] For purposes of illustration, a single system is shown for each of user computer 512, user computer 515, server computer 514, and server computer 516. However, within each of user computer 515, server computer 514, and server computer 516, multiple computers (not shown) can be interconnected through network 530. For example, multiple user computers can be communicatively connected to server computer 514 that operates an IM system in an enterprise computing environment through network 530, multiple user computers can be communicatively connected to server computer 516 that implements an external system outside of the enterprise computing environment, the IM system, and / or a database 538 managed by the IM system through network 530.

[0102] User computer 512 can include a data processing system for communicating with server computer 514. Likewise, user computer 515 can include a data processing system for communicating with server computer 516.

[0103] User computer 512 can include a central processing unit ("CPU") 520, read only memory ("ROM") 522, random access memory ("RAM") 524, a hard disk drive ("HD") or storage memory 526, and input / output device(s) ("I / O") 528. I / O 529 can include a keyboard, a monitor, a printer, an electronic pointing device (e.g., a mouse, a trackball, a stylus, etc.), and the like. User computer 512 can include a desktop computer, a laptop computer, a personal digital assistant, a cellular telephone, or virtually any device capable of communicating over a network. User computer 515 can be similar to user computer 512 and can include CPU 550, ROM 552, RAM 554, HD 556, and I / O 558.

[0104] Likewise, server computer 514 can include CPU 540, ROM 542, RAM 544, HD 546, and I / O 548, and server computer 516 can include CPU 560, ROM 562, RAM 564, HD 566, and I / O 568. Server computers 514 and 516 can each include one or more back-end systems configured to provide instances of an application to user computer 512 through network 530. Many other alternative configurations are possible and known to those skilled in the art.

[0105] Figure 5Each of the computers in the network can have more than one CPU, ROM, RAM, HD, I / O, or other hardware components. For simplicity, each computer is illustrated as having one of each of the hardware components, even though more than one can be used. Each of the computers 512, 514, 515, and 516 is an example of a data processing system. The ROMs 522, 542, 552, and 562; the RAMs 524, 544, 554, and 564; the HDs 526, 546, 556, and 566; and the databases 518 and 538 can include media that can be read by the CPUs 520, 540, 550, or 560. Thus, these types of memories include non-transitory computer-readable storage media. These memories can be internal or external to the computers 512, 514, 515, or 516.

[0106] Portions of the methods described herein can be implemented with suitable software code that can reside in the ROMs 522, 542, 552, or 562; the RAMs 524, 544, 554, or 564; or the HDs 526, 546, 556, or 566. In addition to these types of memories, the instructions in the embodiments disclosed herein can be contained on data storage devices with different computer-readable storage media, such as hard disks. Alternatively, the instructions can be stored as software code elements on data storage arrays, magnetic tape, floppy disks, optical storage, or other suitable data processing system readable media or storage devices.

[0107] Those skilled in the relevant art will appreciate that the application can be practiced with other computer system configurations, including, but not limited to, multiprocessor systems, networked appliances, mini-computers, mainframe computers, data processors, and the like. The application can be practiced in distributed computing environments where tasks or modules are performed across several computers or processing devices linked through a communications network (such as a Local Area Network (LAN), Wide Area Network (WAN), and / or the Internet). In a distributed computing environment, program modules or subroutines can be located in both local and remote memory storage devices. These program modules or subroutines can be stored or distributed on computer- readable media (including magnetic and optical and removable computer disks), stored as firmware in chip sets, and electronically distributed over the Internet or other networks (including wireless networks). Example chip sets can include Electrically Erasable Programmable Read-Only Memory (EEPROM) chip sets. The embodiments discussed herein can be implemented with suitable instructions that can reside on non-transitory computer-readable media, hardware circuitry, and the like, or any combination thereof, and can be interpreted by one or more server machines. Examples of non-transitory computer-readable media are provided below in this disclosure.

[0108] As known to those skilled in the art, a suitable computer system can include a central processing unit ("CPU"), at least one read only memory ("ROM"), at least one random access memory ("RAM"), at least one hard drive ("HD"), and one or more input / output ("I / O") devices. The I / O devices can include a keyboard, a monitor, a printer, an electronic pointing device (e.g., a mouse, trackball, stylus, touchpad, etc.), and the like. The ROM, RAM, and HD are non-transitory computer storage for storing computer-executable instructions that are executable by the CPU or that can be compiled or interpreted to be executable by the CPU.

[0109] Suitable computer-executable instructions can reside on non-transitory computer-readable media (e.g., ROM, RAM, and / or HD), hardware circuitry, etc., or any combination thereof. Within the present disclosure, the term "non-transitory computer-readable medium" is not limited to ROM, RAM, and HD, and can include any type of data storage medium that can be read by a processor. Examples of non-transitory computer-readable storage media can include, but are not limited to, volatile and non-volatile computer memory and storage devices such as random access memory, read only memory, hard drives, data boxes, direct access storage array, magnetic tape, floppy diskettes, flash drives, optical data storage, compact disc read-only memory, and other appropriate computer memories and data storage devices. Thus, a computer-readable medium can refer to a data box, a data backup tape, a floppy disk, a flash drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, etc.

[0110] The processes described herein can be implemented with suitable computer-executable instructions that can reside on a computer-readable medium (e.g., a magnetic disk, a CD-ROM, a memory, etc.). Alternatively, the computer-executable instructions can be stored as software code components on a direct access storage array, a magnetic tape, a floppy disk, an optical storage device, or other appropriate computer-readable medium or storage device.

[0111] Any suitable programming language can be used to implement the routines, methods, or programs of the embodiments of the application described herein, including C, C++, Java, JavaScript, HTML, or any other programming or scripting code. Other software / hardware / network architectures can be used. For example, the functions of the disclosed embodiments can be implemented on one computer or shared between two or more computers or processors connected over a network. Communications between computers or processors can be accomplished using electrical, optical, radio frequency signals, or other suitable communications methods and tools.

[0112] Different programming techniques can be employed such as procedural or object oriented. Any particular routine can be executed on a single computer processing device or multiple computer processing devices, a single computer processor or multiple computer processors. Data can be stored in a single storage medium or distributed through multiple storage mediums, and can reside in a single database or multiple databases (or other data storage techniques). Although steps, operations, or calculations can be presented in a particular order, such an order can be changed in different embodiments. In some embodiments, where multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments can be executed concurrently. The order of the operations described herein can be interrupted, suspended, or otherwise controlled by another process, such as an operating system, kernel, etc. The routines can operate in an operating system environment or as stand-alone routines. The functions, routines, methods, steps, and operations described herein can be performed in hardware, software, firmware, or any combination thereof.

[0113] The embodiments described herein can be implemented in software or hardware or a combination of both, in the form of control logic. The control logic can be stored in an information storage medium, such as a computer readable medium, as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in the various embodiments. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and / or methods to implement the present application.

[0114] It is also within the spirit and scope of the application to implement the steps, operations, methods, routines, or portions thereof described herein in software or code programming, where such software or code programming can be stored in a computer readable medium and can be operated on by a processor to enable a computer to perform any of the steps, operations, methods, routines, or portions thereof described herein. The present application can be implemented by using software programming or code in one or more digital computers, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nano-engineered systems, components and mechanisms can be used. In general, the functions of the present application can be achieved by any means as is known in the art. For example, distributed or networked systems, components and circuits can be used. In another example, communication or transfer of data (or otherwise from one location to another) can be wired, wireless, or by any other means.

[0115] A "computer-readable medium" can be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, system, or device. The computer-readable medium can be, by way of example only but not by limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, system, device, propagation medium, or computer memory. Such computer-readable medium shall generally be machine readable and include software programming or code that can be human readable (e.g., source code) or machine readable (e.g., object code). Examples of non-transitory computer-readable medium can include random access memories, read-only memories, hard drives, data boxes, magnetic tapes, floppy diskettes, flash drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices. In the illustrated embodiment, some or all of the software components can reside on a single server computer, or on any combination of separate server computers. As one skilled in art can appreciate, a computer program product that implements the embodiments disclosed herein can include one or more non-transitory computer-readable media storing computer instructions that are executable by one or more processors in a computing environment.

[0116] A "processor" includes any hardware system, mechanism or component that processes data, signals or other information. A processor can include a system with a central processing unit, multiple processing units, dedicated

[0117] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," "containing," "with," "wherein" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, product, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but can include other elements not expressly listed or inherent to such process, product, article, or apparatus.

[0118] Furthermore, the term "or" as used herein is generally intended to mean "and / or" unless otherwise indicated. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), both A and B are true (or present). As used herein, including the appended disclosure, the term "a" or "an" preceding an element or intervention is intended to be inclusive of both singular and plural of the element or intervention unless otherwise indicated (i.e., the discussion proceeds based on a singular "a" or "an" or "said" explicitly only in the context of a single instance, or only in the context of a plural instance). Furthermore, as used herein, including the description and the appended claims, "comprising" or "comprise" means "including, but not limited to," and "comprises" or "comprising," "having," "including," and the like can have the same

[0119] While the foregoing specification describes certain embodiments, many changes can be made to the embodiments and additional embodiments in accordance with the disclosure herein without departing from the scope of the disclosure. The specification and drawings are, accordingly, to be regarded as illustrative rather than a restriction on the scope of the disclosure. The disclosure is not intended to be limited to the embodiments described herein, but is to be accorded the full scope that the claims can be read to have.

Claims

1. A method for content sharing with an external system, the method comprising: receiving, by a sharing module executing on a processor, an instruction to publish shared items in a repository to an external system based on at least content sharing rules, the sharing module communicatively connected to a first sharing module application programming interface (API), a repository API, a second sharing module API, and an external system API, the repository managed by a content management system operating in an enterprise computing environment, the external system external to the enterprise computing environment, wherein the sharing module is adapted for a many-to-many connection between the managed repository and the external system, and wherein the repository API, the first sharing module API, the second sharing module API, and the external system API together provide a one-to-one mapping of communication protocols used by the repository and the external system; in response to the instruction to publish shared items in the repository to the external system based on at least content sharing rules, retrieving objects and metadata from the shared items in the repository and transferring the objects and metadata to the external system, the retrieving and the transferring performed by the sharing module; monitoring, by the sharing module, for any changes to the shared items in the repository and in the external system, the monitoring including performing, by the sharing module, a bidirectional synchronization operation for updates on the shared items from the repository and the external system; and resolving, by the sharing module, any conflicts for the objects in the shared items, the resolving including synchronizing a resolved version of the objects to the repository, the external system, or both.

2. The method of claim 1, wherein, the content management system comprises an on-premise enterprise information system operating in an enterprise computing environment, and wherein the external system comprises a cloud-based storage system operating in a cloud computing environment.

3. The method of claim 1, wherein, the sharing module performs the retrieving using the first sharing module API and the repository API, and wherein the sharing module performs the transferring using the second sharing module API and the external system API.

4. The method of claim 1, wherein, the content sharing rules are part of a ruleset governing at least one of when content in the shared items in the repository will be published or externally shared, when synchronization will occur, how often synchronization will occur, whether the synchronization is one-way or bidirectional, or when shared content will be sent back into the repository.

5. The method of claim 1, wherein, the bidirectional synchronization operation is performed on-demand, continuously, or every predetermined time interval.

6. The method of claim 1, wherein, the content sharing rules are part of a sharing profile defined by an administrator of the repository.

7. The method of claim 1, wherein, the content sharing rules are stored in a database accessible to the sharing module.

8. A system for content sharing with an external system, the system comprising: a processor; a non-transitory computer readable medium; and stored instructions executable by the processor to: receiving instructions to publish shared items in a repository to an external system based on at least content sharing rules, the repository managed by a content management system operating in an enterprise computing environment, the external system external to the enterprise computing environment, the system communicatively connected to a first sharing module application programming interface (API), a repository API, a second sharing module API, and an external system API, wherein the system is adapted for a many-to-many connection between the managed repository and the external system, and wherein the repository API, the first sharing module API, the second sharing module API, and the external system API together provide a one-to-one mapping of communication protocols used by the repository and the external system; retrieving objects and metadata from shared items in the repository and communicating the objects and metadata to the external system in response to the instructions to publish shared items in the repository to the external system based on at least content sharing rules; monitoring for any changes to shared items in the repository and in the external system, the monitoring including performing a bidirectional synchronization operation for updates on shared items from the repository and the external system; and resolving any conflicts for objects in the shared items, the resolving including synchronizing resolved versions of the objects to the repository, the external system, or both.

9. The system of claim 8, wherein, the content management system includes an on-premise enterprise information system operating in an enterprise computing environment, and wherein the external system includes a cloud-based storage system operating in a cloud computing environment.

10. The system of claim 8, wherein, the retrieving is performed using the first sharing module API and the repository API, and wherein the communicating is performed using the second sharing module API and the external system API.

11. The system of claim 8, wherein, the content sharing rules are part of a ruleset governing at least one of when content in shared items in the repository will be published or externally shared, when synchronization will occur, how often synchronization will occur, whether synchronization is one-way or bidirectional, or when shared content will be sent back into the repository.

12. The system of claim 8, wherein, the bidirectional synchronization operation is performed on demand, continuously, or every predetermined time interval.

13. The system of claim 8, wherein, the content sharing rules are part of a sharing profile defined by an administrator of the repository.

14. The system of claim 8, wherein, the content sharing rules are stored in a database accessible to the sharing module.

15. A method comprising: receiving, by a sharing module executing on a processor, instructions to publish shared items residing in a repository in an enterprise computing environment to a content consumption system external to the repository via a repository adapter, wherein the sharing module is adapted for many-to-many connections between multiple repositories via the repository adapter and between multiple content consumption systems via a content consumption system adapter; retrieving, by the sharing module via the repository adapter, objects and metadata from the shared items residing in the repository in the enterprise computing environment; communicating, by the sharing module via the content consumption system adapter, the objects and metadata retrieved from the shared items residing in the repository in the enterprise computing environment to the content consumption system external to the repository, thereby publishing the shared items to the content consumption system external to the repository, wherein the metadata provides context for the objects published thereby; receiving, by the sharing module via the repository adapter, instructions to publish shared items residing in the repository in the enterprise computing environment to the content consumption system external to the repository, wherein the content consumption system is adapted for many-to-many connections between multiple repositories via the repository adapter and between multiple content consumption systems via the content consumption system adapter; monitoring, by the sharing module, for any changes to the shared item in the repository residing in the enterprise computing environment and in the content consumption system external to the repository; and synchronizing, by the sharing module, the shared item in the repository residing in the enterprise computing environment and in the content consumption system external to the repository in response to detecting a change to the shared item in the repository residing in the enterprise computing environment or in the content consumption system external to the repository.

16. The method of claim 15, wherein, The repository adapter is configured to map a taxonomy language for conflict resolution, the mapping triggered by a change to the shared item.

17. The method of claim 15, wherein, The content consumption system adapter is configured to map a communication protocol for content consumption by the content consumption system.

18. The method of claim 15, wherein, The repository adapter includes a sharing module application programming interface (API) and a repository-specific API.

19. The method of claim 15, wherein, The content consumption system adapter includes a sharing module application programming interface (API) and a content consumption system-specific API.

20. The method of claim 15, wherein, The instructions are received from a rules-based engine based on rules specifying how the sharing module programmatically and automatically publishes the shared item to the content consumption system external to the repository.

21. The method of claim 15, further comprising: storing tracking information in a database local to the sharing module, the tracking information including information identifying the shared object, information identifying a user of the content consumption system, information identifying a role granted by a user of the repository to the user of the content consumption system, changes to the shared object, or a combination thereof.

22. A system comprising: a processor; a non-transitory computer readable medium; and stored instructions that are interpretable by the processor to cause a sharing module to: receive, by a repository adapter, instructions for publishing a shared item residing in a repository in an enterprise computing environment to a content consumption system external to the repository, wherein the sharing module is adapted for many-to-many connectivity between multiple repositories through the repository adapter and between multiple content consumption systems through a content consumption system adapter; retrieve, by the repository adapter, objects and metadata from the shared item residing in the repository in the enterprise computing environment; communicate, by the content consumption system adapter, the objects and metadata retrieved from the shared item residing in the repository in the enterprise computing environment to the content consumption system external to the repository, thereby publishing the shared item to the content consumption system external to the repository, wherein the metadata provides context for the objects published thereby; monitoring, by the sharing module, for any changes to the shared item in the repository residing in the enterprise computing environment and in the content consumption system external to the repository; and synchronizing, by the sharing module, the shared item in the repository residing in the enterprise computing environment and in the content consumption system external to the repository in response to detecting a change to the shared item in the repository residing in the enterprise computing environment or in the content consumption system external to the repository.

23. The system of claim 22, wherein, The repository adapter is configured to map a taxonomy language for conflict resolution, the mapping triggered by a change to the shared item.

24. The system of claim 22, wherein, The content consumption system adapter is configured to map a communication protocol for content consumption by the content consumption system.

25. The system of claim 22, wherein, The repository adapter includes a shared module application programming interface (API) and a repository-specific API.

26. The system of claim 22, wherein, The content consumption system adapter includes a shared module application programming interface (API) and a content consumption system-specific API.

27. The system of claim 22, wherein, The instructions are received from a rules-based engine based on rules that specify how the shared module programmatically and automatically publishes shared items to content consumption systems external to the repository.

28. The system of claim 22, wherein, The stored instructions are further translatable by the processor to cause the shared module to perform the following operations: store tracking information in a database local to the shared module, the tracking information including information identifying the shared object, information identifying a user of the content consumption system, information identifying a role that a user of the repository granted to the user of the content consumption system, changes to the shared object, or a combination thereof.

29. A method comprising: receiving, by a shared module executing on a processor, instructions for publishing a shared item in a repository of a computing environment to an external system through a repository adapter, wherein the external system is external to the repository, wherein the shared module is adapted for a many-to-many connection between multiple repositories through the repository adapter and between multiple external systems through an external system adapter, wherein the shared item includes content and metadata associated with the content; retrieving, by the shared module, the content and associated metadata from the repository of the computing environment through the repository adapter; communicating, by the shared module, the content and metadata retrieved from the shared item in the repository of the computing environment to the external system through the external system adapter, thereby publishing the shared item to the external system; determining, by the shared module, any changes to the shared item in the repository of the computing environment and in the external system; and in response to determining a change to the shared item in the repository of the computing environment or in the external system, synchronizing, by the shared module, the shared item residing in the repository in the computing environment and in the external system external to the repository.

30. The method of claim 29, wherein, The instructions are received from a rules-based engine based on a ruleset that specifies how the shared module polls the external system for updates on the shared item in the external system.

31. The method of claim 29, wherein, The shared item includes a folder in the computing environment, wherein the computing environment is an enterprise environment.

32. The method of claim 29, wherein, The synchronizing includes updating the content in the repository of the computing environment.

33. The method of claim 29, wherein, The repository adapter includes a shared module application programming interface (API) and a repository-specific API.

34. The method of claim 29, wherein, The external system adapter includes a shared module application programming interface (API) and an external system-specific API.

35. The method of claim 29, wherein, The external adapter is configured to map a communication protocol for content consumption of the external system.

36. A system comprising: a processor; a non-transitory computer readable medium; and stored instructions translatable by the processor to cause the shared module to perform the following operations: receiving, by a shared module executing on a processor, instructions for publishing a shared item in a repository of a computing environment to an external system through a repository adapter, wherein the external system is external to the repository, wherein the shared module is adapted for a many-to-many connection between multiple repositories through the repository adapter and between multiple external systems through an external system adapter, wherein the shared item includes content and metadata associated with the content; retrieving content and associated metadata from a repository of the computing environment through a repository adapter; communicating the content and metadata retrieved from the shared item in the repository of the computing environment to the external system through an external system adapter, thereby publishing the shared item to the external system; determining any changes to the shared item in the repository of the computing environment and in the external system; and synchronizing the shared item residing in the repository of the computing environment and in the external system in response to determining a change to the shared item in the repository of the computing environment or in the external system.

37. The system of claim 36, wherein, receiving the instructions from a rules-based engine based on a ruleset specifying how the sharing module polls the external system for updates on the shared item in the external system.

38. The system of claim 36, wherein, the shared item comprises a folder in the computing environment, wherein the computing environment is an enterprise environment.

39. The system of claim 36, wherein, the synchronizing comprises updating content in the repository of the computing environment.

40. The system of claim 36, wherein, the repository adapter comprises a sharing module application programming interface (API) and a repository-specific API.

41. The system of claim 36, wherein, the external system adapter comprises a sharing module application programming interface (API) and an external system-specific API.

42. The system of claim 36, wherein, the external adapter is configured to map a communication protocol for content consumption by the external system.

43. A method for content sharing through an external system, comprising: receiving, by a sharing module, instructions for publishing a shared item to an external system, the shared item representing a folder or directory in a managed repository, the sharing module running on a server machine operating in an enterprise computing environment, the managed repository residing in the enterprise computing environment, the external system operating independently outside the managed repository, the server machine having a processor and a non-transitory computer readable medium; and publishing, by the sharing module, objects in the shared item and metadata associated with the objects from the managed repository to the external system, the publishing comprising: making a first application programming interface (API) call through a first sharing module API and a repository API to retrieve the objects and metadata from the shared item in the managed repository; and making a second API call through a second sharing module API and an external system API to communicate the objects and metadata to the external system; the first sharing module API interfaces the sharing module and the repository API, the repository API interfaces the first sharing module and the managed repository; the second sharing module API interfaces the sharing module and the external system API, the external system API interfaces the second sharing module API and the external system; and wherein the sharing module is adapted to a many-to-many connection between the managed repository and the external system, and wherein in the many-to-many connection, the repository API, the first sharing module API, the second sharing module API, and the external system API together provide a one-to-one mapping of a communication protocol used by the managed repository and the external system.

44. A system for content sharing through an external system, comprising: A server machine operating in an enterprise computing environment, the server machine having a processor, a non-transitory computer readable medium, and stored instructions capable of being translated by the processor to implement a sharing module, the server machine connected to a managed repository residing in the enterprise computing environment and an external system operating independently outside the managed repository, the sharing module configured to: receive instructions to publish a shared item to the external system, the shared item representing a folder or directory in the managed repository; and publish objects and metadata associated with the objects in the shared item from the managed repository to the external system, the publishing comprising: making a first application programming interface (API) call through a first sharing module API and a repository API to retrieve the objects and metadata from the shared item in the managed repository; and making a second API call through a second sharing module API and an external system API to communicate the objects and metadata to the external system; the first sharing module API interfacing the sharing module and the repository API, the repository API interfacing the first sharing module and the managed repository; the second sharing module API interfacing the sharing module and the external system API, the external system API interfacing the second sharing module API and the external system; and wherein the sharing module is adapted to a many-to-many connection between the managed repository and the external system, and wherein in the many-to-many connection, the repository API, the first sharing module API, the second sharing module API, and the external system API together provide a one-to-one mapping of a communication protocol used by the managed repository and the external system.

Images