[go: up one dir, main page]

WO2018176139A1 - Systèmes, procédés et produits de programme informatique de services d'intégration destinés à des outils etl indépendants d'ecm - Google Patents

Systèmes, procédés et produits de programme informatique de services d'intégration destinés à des outils etl indépendants d'ecm Download PDF

Info

Publication number
WO2018176139A1
WO2018176139A1 PCT/CA2018/050377 CA2018050377W WO2018176139A1 WO 2018176139 A1 WO2018176139 A1 WO 2018176139A1 CA 2018050377 W CA2018050377 W CA 2018050377W WO 2018176139 A1 WO2018176139 A1 WO 2018176139A1
Authority
WO
WIPO (PCT)
Prior art keywords
repository
category
cmis
type
application
Prior art date
Application number
PCT/CA2018/050377
Other languages
English (en)
Inventor
Alexander Lilko
Martin Brousseau
Original Assignee
Open Text Sa Ulc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/471,823 external-priority patent/US10073956B2/en
Application filed by Open Text Sa Ulc filed Critical Open Text Sa Ulc
Priority to EP18777079.7A priority Critical patent/EP3602323A1/fr
Publication of WO2018176139A1 publication Critical patent/WO2018176139A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/93—Document management systems

Definitions

  • This disclosure relates generally to information management. More particularly, embodiments disclosed herein relate to an inventive versatile and extensible solution for integrating information across disparate data sources such as information systems.
  • Information integration refers to the merging of information from heterogeneous sources with differing conceptual, contextual and typographical representations.
  • information integration refers to textual representations of data mined and consolidated from unstructured or semi-structured resources.
  • An information integration technology is based on data warehousing where a data warehouse system extracts information from source databases, transforms the extracted information, and then loads the transformed information into a data warehouse. This technology, however, requires that the information must be stored in a single database with a single schema. Thus, when a new source is added to a system such as a content server, the entire new data set from the new source would need to be manually integrated to comply with the existing database schema.
  • a virtual data integration solution may be used.
  • application developers may construct a virtual schema against which users can run queries. Additionally, the application developers may design wrappers or adapters for each data source.
  • the query is transformed into appropriate queries over the respective data sources.
  • the wrappers or adapters simply transform local query results returned by the respective data sources into a processed form.
  • a virtual database combines the results of these queries into the answer to the user's query. This technology, however, is not extensible.
  • a new source is added to a system, a virtual schema must be constructed and new wrappers or adapters written for the new source.
  • An object of the invention is to address challenges and needs in the field of information management. Another object of the invention is to extend control and influence over content owned or under control by an entity such as a business or organization. Yet another object of the invention is to enable entities to manage content stored in disparate information systems and perhaps shared among users having different job functions and/or roles.
  • an information integration system that enables applications to access, aggregate, analyze, manage, and present information stored in disparate information systems to end users and developers alike in a unified, cohesive, synchronized, efficient, and secure manner.
  • applications may include various enterprise applications such as web based applications, search based applications, and non-search applications, etc.
  • an information integration system may include a set of integration services embodied on one or more server machines in a computing environment.
  • the set of integration services may include connectors communicatively connected to disparate information systems. These connectors, which may be of a single type or of different types, may be configured for integrating data stored in the disparate information systems utilizing a common model employed by the set of integration services.
  • the common model may overlay, augment, integrate, or otherwise utilize a content
  • CMIS management interoperability services
  • CMIS is an open standard that allows different content management systems to interoperate over the Internet.
  • the common security model may include permissions particularly defined for use by the set of integration services. These common property definitions and permissions may be uniquely defined and utilized by the information integration system.
  • a method for information integration may include deploying a set of integration services on one or more server machines in a computing environment, the set of integration services having a set of connectors communicatively connected to disparate information systems.
  • the method may further include integrating, via the set of connectors, data stored in the disparate information systems utilizing a common model employed by the set of integration services.
  • the common model may implement an embodiment of the common model overlaying the CMIS data model and may include common property definitions and a common security model.
  • the common security model may include permissions particularly defined for use by the set of integration services.
  • the CMIS data model may include a feature called "secondary type” which defines named sets of properties that can be dynamically added to and removed from CMIS objects.
  • Some enterprise content management (ECM) systems such as Open Text Content Server (OTCS)
  • OTCS Open Text Content Server
  • categories are primary type objects and can be created, modified, or deleted as regular objects.
  • ECM Open Text Content Server
  • certain components of the integration services are modified to leverage the CM IS secondary types.
  • a content server connector may be enhanced to support, in addition to CMIS documents and CMIS folders, CMIS primary types and CMIS secondary types.
  • new object types are added to an ECM extract, transform, and load (ETL) tool at the application tier.
  • ECM ETL tool can be Open Text Integration Center (OTIC).
  • OTIC may have an ECM abstract model of ECM objects and operations.
  • OTIC may support ECM Document, ECM Folder, CS Category, CS Record Management (RM) Classification, and CS RM Hold. Adding a new ECM type in OTIC and performing operations on the new ECM type may require generalization based on a few examples of the ECM system. To this end, OTIC can be considered an ECM-dependent ETL tool.
  • OTIC can be decoupled from the ECM and operate independently of an ECM system at the storage tier. For example, enhanced ECM connectors may map ECM-supported types to one of CMIS primary or secondary types.
  • OTIC (or the like) can immediately process the new ECM type without additional development on the OTIC side.
  • This provides a technical effect of allowing OTIC to implement the CMIS model and support ECM Document, ECM Folder, CMIS Item, and CMIS Secondary types and operations on these types independent of the ECM system, making the improved OTIC an ECM-independent ETL tool.
  • One embodiment comprises a system comprising a processor and a non-transitory
  • Another embodiment comprises a computer program product having a non-transitory computer-readable storage medium that stores computer instructions translatable by a processor to perform a method substantially as described herein.
  • FIGURE 1 depicts a diagrammatic representation of one example of a network environment in which embodiments disclosed herein can be implemented
  • FIGURE 2 depicts a diagrammatic representation of one embodiment of a system having a set of integration services for integrating data across disparate information systems;
  • FIGURE 3 depicts a diagrammatic representation of one embodiment of a common model utilized by a set of integration services for integrating data across disparate information systems;
  • FIGURE 4 depicts a diagrammatic representation of one embodiment of an information integration system through which a search application can access objects in disparate information systems;
  • FIGURE 5 depicts a diagrammatic representation of one embodiment of a set of connectors configured for integrating data stored in disparate information systems according to a common model utilized by a set of integration services;
  • FIGURE 6 depicts a flow diagram illustrating one embodiment of a method of dynamically creating a new connector in an information integration system post-installation
  • FIGURE 7 depicts a diagrammatic representation of one embodiment of an information integration system having a set of connectors through which a data collector can collect data from disparate information systems and through which a search system can search data across the disparate information systems;
  • FIGURE 8 depicts a diagrammatic representation illustrating example operations of an information integration system having a set of integration services and a search system according to some embodiments
  • FIGURE 9 depicts a diagrammatic representation of one embodiment of an information integration system with optional components
  • FIGURE 10 depicts a diagrammatic representation of an information integration system with different possible configurations according to some embodiments;
  • FIGURE 1 1 depicts a flow diagram illustrating one embodiment of a method for information integration across disparate information systems for non-search based applications;
  • FIGURE 12 depicts a flow diagram illustrating one embodiment of a method for information integration across disparate information systems for search based applications
  • FIGURE 13 depicts a diagrammatic representation of a user interface of an example
  • discovery application displaying search results provided by one embodiment of an information integration system disclosed herein;
  • FIGURE 14 depicts a diagrammatic representation of a user interface of an example
  • Iifecycle management application displaying a dashboard generated using an embodiment of an information integration system disclosed herein;
  • FIGURE 15 a diagrammatic representation of a page view of an example Iifecycle
  • FIGURE 16 depicts a diagrammatic representation of CMIS-compliant integration services architecture that provides an EC -independent ETL solution, according to some embodiments disclosed herein;
  • FIGURES 17A-17B provide example types and operations of a repository-specific connector
  • FIGURE 18 depicts a diagrammatic representation of an example view of a graphical user interface of an integration services server
  • FIGURES 19-20 depict examples of OTIC "secondary type" documents
  • FIGURE 21 depicts an example of a document with two "secondary types" attached
  • FIGURES 22-23 depict diagrammatic representations of example views of a graphical user interface of a content server
  • FIGURES 24 and 25A-25B depict diagrammatic representations of example views of a
  • FIGURE 26 depicts a diagrammatic representation of an example view of a graphical user interface of an application
  • FIGURE 27 depicts a diagrammatic representation of an example view of a graphical user interface of a property editor
  • FIGURE 28 is a flow chart illustrating an example method of providing an ECM-independent
  • FIGURE 29 is a flow charge illustrating an example use case of an EC -independent ETL tool.
  • FIGURE 30 depicts a diagrammatic representation of a data processing system for
  • network environment 100 may include client devices 101 a, 101 b...101 n communicatively connected to web server 20 over network 10.
  • Web server 20 may be communicatively connected to a plurality of information systems 40a, 40b...40n directly or by way of information integration system 30.
  • information systems 40a, 40b...40n may include backend systems such as data storage systems residing in a storage tier and described in more detail below.
  • Information integration system 30 may reside on one or more server machines.
  • Each of the client devices and server machines illustrated in FIGURE 1 can be a data processing system, an example of which is shown in FIGURE 14.
  • FIGURE 2 depicts a diagrammatic representation of one embodiment of a system having a set of integration services for integrating data across disparate information system.
  • system 200 may include application tier 220, integration tier 230, and storage tier 240.
  • Information integration system 30 shown in FIGURE 1 may implement an embodiment of information integration system 200 shown in FIGURE 2.
  • Storage tier 240 may comprise repositories 280 and database 290.
  • Repositories 280 may include multiple disparate information systems. Data in such information systems may be formatted differently and/or structured using different data models. Examples of information systems can include various data storage systems and repositories such as document management systems, content management systems, content repositories, document repositories, content servers, document servers, etc. In this disclosure, these systems may be collectively referred to herein as backend systems.
  • Database 290 may be
  • database 290 may store configurations for connecting to the repositories 280. These configurations may include configuration parameters defined by service providers.
  • database 290 may be a relational database.
  • Application tier 220 may comprise a plurality of applications, including application 222.
  • application tier 220 There can be various types of applications, including mobile applications, web based applications, and enterprise-class applications, at application tier 220.
  • applications including mobile applications, web based applications, and enterprise-class applications, at application tier 220.
  • enterprise-class applications readers are directed to U.S. Patent Application No. 13/939,946, filed July 1 1 , 2013, and entitled "SYSTEMS AND METHODS FOR IN- PLACE RECORDS MANAGEMENT AND CONTENT LIFECYCLE MANAGEMENT," which is incorporated herein by reference.
  • application 222 can be a client application called Open Text Integration Center (OTIC), which is discussed below.
  • OTIC Open Text Integration Center
  • Integration tier 230 may comprise information integration server 250.
  • various applications may access data in backend systems through an information integration server in various ways.
  • an In-Place Records Management (RM) application (available from Open Text, headquartered in Waterloo, Ontario, Canada) may manage records "in-place" as they are stored in backend systems through an embodiment of an information integration server.
  • RM In-Place Records Management
  • a search application may search information across disparate backend systems by way of an embodiment of an information integration server.
  • a browser may access information across disparate backend systems by way of an embodiment of an information integration server.
  • information integration server 250 may include integration services 260.
  • Integration services 260 may provide application 222 with synchronous access to backend systems 280 residing at storage tier 240.
  • integration services 260 may include authentication filter (servlet component) 261 , CMIS gateway (servlet component) 263, service provider interface (interface component) 265, credential storage (servlet component) 267, credential store (storage component) 269, and connectors (connector component) 270.
  • integration services 260 may be implemented in various ways. For example, one or more components of integration services 260 shown in FIGURE 2 may be optional, as further described below. Furthermore, in some embodiments, integration services 260 may include one or more components not explicitly shown in FIGURE 2.
  • Authentication filter 261 can be implemented in various ways. For example, in one
  • authentication filter 261 may implement a single sign-on (SSO) solution.
  • SSO single sign-on
  • Other access control solutions such as layering Hypertext Transfer Protocol Secure (HTTPS) on top of the secure sockets layer (SSL)/Transport Layer Security (TLS) protocol may also be possible.
  • HTTPS Hypertext Transfer Protocol Secure
  • SSL secure sockets layer
  • TLS Transport Layer Security
  • authentication may be optional. For example, if application 222 is responsible for handling authentication or if authentication is not required in system 200, then authentication filter 261 may be optional.
  • integration services 260 may operate to determine if the user already has a session on the requested information system at the backend. For example, referring to FIGURE 1 , user 101 a may already have a session open with backend system 40a without going through information integration system 30. If the user already has a session on the requested information system at the backend, application 222 may call integration services 260 with a session identifier (ID) which is then stored in credential store 269 via credential storage 267.
  • ID session identifier
  • integration services 260 may operate to check credential store 269 and, if the user is permitted to access the requested information system per information stored in credential store 269, cause CM IS gateway 263 to open a session on the requested information system (using an appropriate connector, explained below).
  • User credentials stored in credential store 269 may be encrypted.
  • CMIS Content Management Interoperability Services
  • CMIS defines an abstraction layer that allows different content management systems to inter-operate over the Internet using web protocols.
  • CMIS includes a set of services for adding and retrieving documents and provides a data model referred to as the CMIS data model.
  • the CMIS data model covers typed files and folders with generic properties that can be set or read.
  • the CMIS data model is based on common architectures of the backend systems. Consequently, CMIS does not define how a backend system can be mapped to the CMIS data model.
  • CMIS gateway 263 may decouple the CMIS data model from disparate backend systems while allowing frontend applications which utilize the CMIS to access content stored in the disparate backend systems.
  • one way to decouple CMIS data model 215 from disparate information systems 280 is to overlay CMIS data model 215 with integration services (IS) common model 210.
  • CMIS gateway 263 may maintain IS common model 210.
  • IS common model 210 may overlay, integrate, augment, or otherwise utilize CMIS data model 215.
  • CMIS gateway 263 may call one of connectors 270 to communicate with a particular information system 280 at storage tier 240.
  • Connectors 270 may be configured or otherwise adapted to communicate with information systems 280.
  • Service provider interface 265 may allow a new connector to be deployed into system 200. Examples of connectors 270 are described below with reference to FIGURES 3-5. An example of a method for adding a new connector to an information integration system is described below with reference to FIGURE 6.
  • FIGURE 3 depicts a diagrammatic representation of how an information integration system may operate to integrate data across disparate information systems utilizing connectors and an IS common model. As described above, these disparate information systems may implement different data models.
  • metadata stored in an information system according to repository specific data model 305 may be mapped to CMIS conventions conforming to CMIS data model 315 using connectors such as connectors 270 shown in FIGURE 2, connectors 465, 475 shown in FIGURE 4, or connectors 770 shown in FIGURE 7.
  • this CMIS mapping can be bi-directional. That is, in some
  • an information integration system may be configured to provide a two-way translation for a repository data model and the CMIS data model.
  • this two-way translation can be characterized by: 1) repository objects are unambiguously translated into instances of CMIS types; and 2) instantiation of CMIS types result in unambiguous instantiation of repository objects.
  • a connector may be configured with several components
  • Java classes including a type manager class, for interfacing with a specific information system at the backend, mapping the data model used by the specific information system at the backend to the CMIS data model maintained by the CMIS gateway, creating types appropriate for the specific information system, and exposing the types through the CMIS gateway to the application tier.
  • This kind of connectors may be preconfigured as part of the information integration system. Post-installation of the information integration system, extensible connectors may be added, as explained below. Extensible connectors may not create types on the information systems at the backend, although they can still create instances of types and expose those types.
  • An example type can be a document type that defines a document guaranteed to have an integer in its metadata and the integer is some file number. Suppose the file number is guaranteed to have a certain length and fit into two bytes. Also, suppose a second document type defines a different file number that fits into four bytes. In an information system, these types maybe called type 1 and type 2 or type short and type long. These types are created and defined in the same information system.
  • a repository connector configured for this information system may create type 1 or type 2 as well as instances thereof, while an extensible connector may create instances of type 1 or type 2.
  • a repository connector may be created, configured, and installed as part of the information integration system.
  • the repository connector would have the knowledge as to the length of numbers that are used by the two types and how to map between the lengths of numbers to be exposed.
  • An extensible connector may be configured and deployed by a service provider into the information integration system post-installation using a connector service provider interface such as connector service provider interface (SPI) 265 shown in FIGURE 2.
  • SPI connector service provider interface
  • the extensible connector is not required to have the knowledge to create the types. Rather, it creates instances of the types and exposes them accordingly.
  • Common property definitions 31 1 and common permissions 313 may be uniquely defined and utilized by an information integration system such as system 200 shown in FIGURE 2. Specifically, common permissions may be particularly defined for use by integration services such as integration services 260 shown in FIGURE 2. In one embodiment, common permissions 313 may comprise access control list (ACL) permissions.
  • ACL access control list
  • the CMIS data model may cover typed files and folders with generic properties that can be set or read.
  • data exposed by CMIS data model 315 may not fully cover the types of data held according to repository specific data model 305 in the given information system
  • data exposed by CMIS data model 315 (referred to as CMIS data in FIGURE 3) may cover a set of data types sufficient for mapping data held in a given information system.
  • a model mapping operation (e.g., an operation that maps data in repository specific data model 305 to common model 310) using a connector may unambiguously translate a repository object into a list of CMIS typed key-value pairs, resulting in a "flattened” output.
  • CMIS have items that have metadata, items that have metadata and a content stream, items that have metadata and children, policies and relationships, and so on.
  • the metadata in those cases is flattened into multivalued properties that have, for instance, names, types, integers, and strings.
  • flattened output 320 may include the C IS data (CMIS typed key-value pairs) and some additional data (key-value pairs) originated from additional analysis. Such additional data may not map to instances of data in the CMIS data model.
  • CMIS has the notion of property definitions such as name, value, and type. For example,
  • Common model 310 includes common property definitions 31 1 that are far more comprehensive. In some embodiments, these are referred to as “common keys” or “keys” and may include, but are not restricted, to:
  • Connectors are an important part of this bi-directional C IS mapping.
  • a service provider develops a connector, they have to develop the C IS portion described above and an authorization portion and a principals service portion described below.
  • the authorization portion and the principals service portion are completely outside of the conventional CMIS data model and are used for the common security model disclosed herein.
  • the CMIS allows access to an ACL in a typical content management system, if a service provider wants to use the common security model, they have to implement special common model permissions used by the search API.
  • the common security model also uses ACL permissions, although it supports additional common permissions.
  • a data collector such as data collector 473 described below with reference to FIGURE 4 or data collector 773 described below with reference to FIGURE 7 can be configured to supply ACLs for objects.
  • ACLs are defined as in the CMIS specification as a list of access control entries (ACEs) where each ACE contains a principal and a permission.
  • ACEs access control entries
  • a principals service reports principals that might show up in the ACEs inside of an ACL.
  • permissions may be modified by updating all the ACLs for the information systems at the backend.
  • the common security model may be considered a CMIS ACL
  • a data collector may support a list of named "read” and/or
  • One embodiment of a connector may map these permissions to the common security model disclosed herein as follows:
  • the connector will always follow the common security model's definition of order (per the logical evaluation of priorities defined above). From this perspective, the connector is transforming the permission evaluation from one logical order to another. To do that, the connector follows the inheritance chain defined by the information system and whenever there is a switch from Allow to Deny, the connector hops to the next available Deny according to the common security model's definition of order.
  • a connector can map a filename used in the information integration system to a C IS object name (e.g., LocalName).
  • a user's principal may be encoded as "SYSTEM 16344 1003" in a content server and as "#AUTHENTICATED-USERS#” in a file management system. They are commonly encoded for the principals service.
  • Documents which can be seen by all users on a system may be treated by constructing a repository specific principal representing all users.
  • the data collector may ensure that every document with these permissions has the principal in the correct permissions level.
  • the principals service may ensure that only super users have this principal, and the data collector may ensure that every document has a super user principal associated with the correct permissions level.
  • the principals service uses common permissions mapped by the connectors.
  • different types of connectors may be used by different components of an information integration system.
  • FIGURE 4 provides an example of an information integration system that may employ different types of connectors.
  • information integration system 400 may include application tier
  • Database 490 may be the same or similar to database 290 shown in FIGURE 2.
  • system 400 may be the same or similar to system 200 shown in FIGURE 2.
  • Application 422 can be a search application. A method of implementing information
  • integration system 400 in a network computing environment may include installing information integration server 450 which includes integration services 460.
  • integration services 460 may include components the same as or similar to those described above with regard to integration services 260.
  • integration services 460 include connectors 465.
  • Connectors 465 can be the same as, similar to, or different from connectors 270 described above with reference to FIGURE 2.
  • each of connectors 465 is particularly configured for communicating with a specific information system of information systems 480.
  • Information integration server 450 may further include search system 410 and indexer 470.
  • Search system 410 may comprise search API 41 1 , search engine 413, and unified index 415.
  • Indexer 470 may comprise ingestion pipeline 471 , data collector 473, and connectors 475. These components will be further described below.
  • the method may further include running data collector 473 to obtain data (e.g., document metadata) from disparate information systems 480 for indexing by search system 410.
  • Data collector 473 may utilize connectors 475 to communicate with information systems 480.
  • connectors 475 can be the same as, similar to, or different from connectors 270 described above with reference to FIGURE 2.
  • each connector 475 may be particularly configured for a specific information system of information systems 480 such that data mined from the specific information system can be mapped to the CMIS conventions as explained above.
  • Data collected by data collector 473 may be provided to ingestion pipeline 471 for
  • a document may be processed through a flow involving several components such as a document extractor, a path processor, a field mapper, a file type normalizer, a detagger, a summarizer, an indexer, and a cleaner in order to extract data that can be used by search engine 413 to build unified index 415.
  • a document extractor e.g., a document extractor, a path processor, a field mapper, a file type normalizer, a detagger, a summarizer, an indexer, and a cleaner in order to extract data that can be used by search engine 413 to build unified index 415.
  • a document extractor e.g., a document extractor, a path processor, a field mapper, a file type normalizer, a detagger, a summarizer, an indexer, and a cleaner in order to extract data that can be used by search engine 413 to build unified index 415.
  • Other implementations of indexer 470 may also be possible.
  • Indexer 470 may feed the processed data to search system 410 to build unified index 415.
  • Search engine 413 may use unified index 415 and may support faceted search (explained below). Other implementations of search system 410 may also be possible.
  • application 422 may, through integrated services 460 of information integration server 450 at integration tier 430, have access to some indexed data. This allows application 422 to search and synchronize access to information systems 480 at storage tier 440 even before unified index 415 is completely built.
  • indexer 470 may be used to synchronize with information systems 480 at the backend and keep unified index 415 up-to-date.
  • application 422 is fully configured. For example, a user may now perform a faceted search utilizing application 422.
  • Faceted search refers to a technique for accessing organized information, combining text search with navigational search using a hierarchy structure.
  • information stored in a repository may be augmented with facets corresponding to properties of data elements such as author, descriptor, format, language, etc.
  • a facetted search module may comprise a search application programming interface (API) and a search interface configured to allow a user to enter search text into a text box.
  • API application programming interface
  • application 422 may run an instance of a search interface on a client device associated with the user.
  • the user input text is communicated to search system 410 via search API 41 1.
  • Search API 4 1 may, in turn, return search results to the user via the search interface
  • the search interface may present the organized search results. For example, the search results may be shown in facets or categories. Each of the categories may be shown with a number of hits (counts).
  • the user can refine the search results by browsing or navigating down a path that begins with one of the categories. Each time a facet is selected, a new search query is automatically generated and passed down through the search interface and search API 41 1 to search engine 413 to begin a new, narrower search. The new search results are returned and presented to the user in a similar manner. This process can be repeated until the user enters a new search query, ends the session, closes application 422, or otherwise terminates the process.
  • Other search interface may present the organized search results. For example, the search results may be shown in facets or categories. Each of the categories may be shown with a number of hits (counts).
  • the user can refine the search results by browsing or navigating down a path that begins with one of the categories. Each time a facet is selected, a new search query is automatically generated and passed down through the search
  • search engine 413 may also be possible.
  • application 422 may, via the search interface, present a page with a tree map view of the search result to the user.
  • the tree map can be an automatically generated diagram that lays out items of information in information systems 480 that match the search query or queries.
  • mapping the data to the common model may be hard coded and realized on-the-fly through integration services.
  • the mapping may include specifying a document type in a connector such as connector 475 for indexer 470, querying a particular information system for documents of the specified document type, collecting the data returned by the information system, and providing the data to the search application.
  • connectors 475 may comprise a set of proprietary drivers and scripting and data mapping structure built over the drivers. Other implementations are also possible.
  • mapping may be synchronized across the integration tier. Specifically, data type
  • each connector 465 is configured for or otherwise adapted to a particular information system 480 and each connector 465 is configured for or otherwise adapted to a particular information system 480.
  • a new connector 465 for integration services 460 is to be configured for or otherwise adapted to communicate with the new repository and a new connector 475 for indexer 470 is to be configured for or otherwise adapted to the same repository.
  • some components of an information integration system may employ a connector framework to communicate with disparate information systems 480.
  • a connector framework is illustrated in FIGURE 5.
  • connector framework 500 may comprise connector API 505 and connectors 510.
  • Connectors 510 may include preconfigured connectors such as Connectorl for a first information system, Connector2 for a second information system, and various existing connectors for various information systems at the backend. These preconfigured connectors may be referred to as repository connectors as they are particularly configured for and can communicate directly with respective repositories.
  • Connectors 510 may also include extensible connectors. Extensible connectors may be created, configured, and deployed into connector framework 500 and useable by an information integration system post-installation (e.g., an information integration system that is operational in an enterprise computing environment). An example of this process is described below with reference to FIGURE 6.
  • a connector service provider interface (e.g., connector SPI 515) allows a service provider (e.g. , repository providers 520) to deploy and configure connectors used by the information integration system to communicate with a particular backend system (repository).
  • a connector SPI may comprise a set of interfaces that a service provider is to implement if they wish to add a connector to the information integration system.
  • an SPI JAR file may be provided as an example which has the classes that can be used to create the connector. The service provider will create a connector using the classes provided in the JAR file, debug as usual, deploy the connector into the information integration system and use the connector SPI to configure the connector.
  • process 600 may receive or retrieve a configuration specification of a new connector for a repository from a repository provider.
  • the configuration specification may contain types of configuration parameters for their new connector.
  • process 600 may create necessary entries in a database (e.g., database 290 shown in FIGURE 2, database 490 shown in FIGURE 4, database 790 shown in FIGURE 7, or database 990 shown in FIGURE 9) based on the configuration specification and enable an administrator for the repository to configure (using a connector SPI) the new connector for the specific repository. For instance, SPI configuration parameters as well as whatever information that connector needs may be stored in the database.
  • the new connector may be configured for a set of integration services such as CM IS
  • the new connector may also be configured to use the common property definitions if the repository provider wishes to participate in a unified index provided by the information integration system. In some embodiments, the new connector may also be configured to use the common model permissions if the repository provider wishes to implement the principals service.
  • the configured connector may provide a connection factory and service methods particular to the repository.
  • the connection factory may reside at the repository level and may be used to create a connection which is managed by the information integration system (and thus is referred to as a managed connection). Additionally, the connection factory may process credentials for accessing the repository.
  • process 600 may send the configuration information of the new connector to the specific repository which encapsulates the CMIS services.
  • the new connector can be used to create a managed connection to the repository. For example, when there is a service call for an object, an instance of the connector may be called with an appropriate object ID to get the object from the repository.
  • the integration services may be restarted before the newly configured connector can be used.
  • FIGURE 7 An example of an information integration system having such a connector framework is illustrated in FIGURE 7.
  • system 700 may include application tier 720, integration tier
  • Application tier 720 may have applications 722 and 724.
  • Application 722 may be a non-search based application and communicate directly with integration services 760.
  • Application 724 may be a search based application and communicate directly with search system 710 which utilizes integration services 760.
  • Integration tier 730 may have integration services 760, search system 710, ingestion pipeline 771 , and data collector 773.
  • Storage tier 740 may have information systems 780 and database 790.
  • non-search based application 722 may utilize search based application 724 to search disparate information systems 780.
  • system 700 Some components of system 700 such as search API, search engine 713, unified index 715, ingestion pipeline 71 1 , and data collector 773 may be the same or similar to those described above with reference to system 400 shown in FIGURE 4. Some components of system 700 such as authentication filter 761 , C IS services 763, connector SPI 765, credential storage (servlet) 767, and credential store 769 may be the same or similar to those described above with reference to system 200 shown in FIGURE 2.
  • integration services 760 reside between search system 710 and information systems 780 and also between data collector 773 and information systems 780.
  • data collector 773 can collect data from disparate information systems 780 using connectors 770 and search system 710 can search data across disparate information systems 480 also using connectors 770.
  • the connector framework of integration services 760 handles all the complexities in dealing with disparate information systems 780. Thus, data collector 773 does not need to know how to connect to information systems 780 or how to map all their repository formats to the format ingestion pipeline 771 needs.
  • extensible connectors can be readily created, configured, and deployed into the connector framework of integration services 760.
  • the extensible connectors, along with any preconfigured connectors, can provide managed connections for system 700 to communicate with disparate information systems 780. Thus, although they could, there is no need for data collector 773 and search system 710 to use different kinds of connectors to communicate with the same repository at the backend.
  • a connector may be configured for a set of integration services such as
  • connectors disclosed herein may vary from implementation to implementation, although their principle functions (e.g., bidirectional C IS mapping, providing managed connections, etc.) remain the same.
  • FIGURE 8 depicts a diagrammatic representation illustrating example operations of an information integration system having a set of integration services and a search system according to some embodiments.
  • information integration system 800 may comprise integration services 860 and search system 810.
  • Information integration system 800 may include additional components such those described above with reference to FIGURES 2, 4, and/or 7.
  • Integration services 860 may comprise principals service 861 and authorization service 863.
  • Search system 810 may comprise search API 81 1 , search engine 813, and unified index 815.
  • Search API 81 1 may comprise authorization post filter 806.
  • Search engine 813 may comprise security query parser 802 and query evaluator 804.
  • connectors in system 800 would be configured to use the common property definitions and the common model permissions (e.g., common property definitions 31 1 and common permissions 313 shown in FIGURE 3) described above.
  • an information system at the backend may be configured for "early binding,” “late binding,” or “early followed by late binding.” Early binding of permissions is done by looking up the user's principals at query time and modifying the query to return only results with correct permissions. The query is modified to include the union of the user's principals from all repositories being searched.
  • a principals service in the integration services can provide the principals for a user in response to a service call. This is further explained below.
  • an information integration system can support a first security model configured for performing an inbound check at query time ("early binding"), a second security model configured for performing an outbound check after a search is done (“late binding"), a third security model configured for performing an inbound check and an outbound check after a search is done ("early followed by late binding," and a fourth security model where no check is performed (which, in one embodiment, common permissions may be defined but not used).
  • a first security model configured for performing an inbound check at query time
  • a second security model configured for performing an outbound check after a search is done
  • late binding a third security model configured for performing an inbound check and an outbound check after a search is done
  • a fourth security model where no check which, in one embodiment, common permissions may be defined but not used.
  • the late binding can be an option for repositories that use non-C IS based permission models.
  • search API 81 1 may call principals service 861 to find out with what principal(s) this user is associated (or of which group the user is a member) and call search engine 813 to modify (via security query parser 802) a query and determine (via query evaluator 804) to find out what that user can see per their association with the principal(s) based on permission information in unified index 815.
  • security query parser 802 may augment the query with the principals for the user.
  • Query evaluator 804 may evaluate the permissions as part of query evaluation. These permissions are common permissions. As described above, common permissions are logically evaluated in order of priorities defined in the common security model.
  • Security query parser 802 may translate or modify the query into a complex Boolean to support evaluation by query evaluator 804.
  • a single call to a principals service may be as follows:
  • the state is one of the following:
  • the GET principals call is used to construct the query at query time. For it to be fast,
  • caching can be used.
  • the query is modified in different ways.
  • One example is provided in the table below:
  • search API in this case is configured to treat both information systems
  • the query may be modified to include (AND) the following filter:
  • such an inbound check can only be performed if the permission information has been collected (e.g., via a data collector such as data collector 473 or data collector 773) and the permission information is indexed and stored (e.g., in unified index 415 or unified index 715). If the permission information has changed, that change will not be in the index until the next time the permission information is collected. So, this is as accurate and current as the information that is in the index. However, it is fast because a user's permission is evaluated as part of a search and can be appended to a query (e.g., in one embodiment, by using "AND GROUPID").
  • an outbound check can be performed even if the permission
  • the query is received and a search performed.
  • the question as to what search result that user can see is federated (via search API 81 1 and authorization service 863) to the information systems at the backend as they are the authorities on what their users are permitted to view.
  • the authorization information is returned (via authorization service 863) to search API 81 1 and authorization post filter 806 is used to filter search results for the user based on the authorization information.
  • the filtered search results are then returned for presentation to the user.
  • the authorization would be accurate and current because it comes from the authority (a backend system).
  • the backend system is the authority, no modeling of permissions is necessary. However, this can be slow for users with sparse permissions.
  • the third security model can provide the benefits of inbound check 801 and outbound check
  • inbound check 801 can provide a fast and efficient way to define a scope of search for the query.
  • outbound check 803 the authorization can be verified to make sure that the user's authorization to view the search results is up-to-date.
  • an administrator for an information integration system can decide which one common security model to use, by changing the configuration file and restarting the service.
  • Other implementations may also be possible.
  • reusable components may be configured to enable a plurality of functions, including discovery, data migration, data synchronization, content lifecycle management, in-place records management, search, etc.
  • a set of reusable components may be provided for a search engine.
  • an application may utilize some of the reusable components to search and/or manage documents in disparate information systems at the backend.
  • FIGURE 9 depicts a diagrammatic representation of one embodiment of an information integration system with optional components, as denoted by the dashed line boxes.
  • System 900 may include application tier 920 having application 922, integration tier 930 having integration services 960, and storage tier 940 having information systems 940 and database 990.
  • Database 990 may store configuration information as well as encrypted credential information for use by integration services 960.
  • Integration services 960 may reside at a layer between search system 910 and information systems 980 and between data collector 973 and information systems 980.
  • Search system 910 may have search API 91 1 , search engine 913, and unified index 915.
  • Data collector 973 may collect data from disparate information systems 980 through integration services 960 and the collected data may be processed by ingestion pipeline 971 and used by search system 9 0 to build and/or update unified index 915 in the same or similar way as described above.
  • Some embodiments of integration services 960 such as authentication filter 961 , CMIS services 963, SPI 965, credential storage 967, and credential store 969 may be the same or similar to those described above with reference to integration services 760.
  • system 900 may further include a unique user interface (Ul) layer 924.
  • Ul layer 924 may be built on top of an embodiment of an information integration platform (e.g., integration tier 930) and configured to utilize a search system running on the information integration platform.
  • Ul layer 924 may be configured to communicate with search API 91 1 , filter data from disparate information systems at the backend using search engine 913 and unified index 915, and display the filtered data in various ways, as explained below.
  • system 900 may not need to include all the components of integration services 960.
  • integration services 960 may comprise only connectors 970 through which search system 910 and data collector 973 can fully enable application 922 in performing search functions, including faceted search described above.
  • data collector 973 may collect data via connectors
  • Ingestion pipeline 971 may process the collected data and provide the processed data to search system 910 for indexing.
  • Connectors 970 may map data from repository specific data models used by information systems 980 at the backend to an information integration common model as described above.
  • a user may not be able to act on a search result through integration services 960.
  • the user may not be able to directly manipulate an item of information (e.g., a document) referenced in the search result.
  • the user can perform search via application 922 and view the search result.
  • search result say, a document
  • the user is taken directly to the document, directly in the content management system where the document resides.
  • search systems and data collectors can be specific to search based applications.
  • embodiments of an information integration system can be configured in various ways.
  • FIGURE 10 depicts a diagrammatic representation of an information integration system with different possible configurations according to some embodiments.
  • system
  • 1000 may include browser 1001 running on a client device associated with a user.
  • Browser may include browser 1001 running on a client device associated with a user.
  • Backbone.jr for event based interaction of models, views, and controllers and jQuery for Document Object Model (DOM) manipulations.
  • Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to an existing API over a RESTful JavaScript Object Notation (JSON) interface.
  • JSON JavaScript Object Notation
  • jQuery is a multi-browser JavaScript library. DOM, JSON, Backbone.js, and jQuery are known to those skilled in the art and thus are not further described herein.
  • Browser 1001 may implement the model-view-controller (MVC) software architecture that separates the representation of information from the user's interaction with it.
  • MVC model-view-controller
  • a model in the MVC architecture (referred to hereinafter as a browser model) may contain application data, business rules, logic, and functions; a view can be any output representation of data, such as a document or a diagram; and multiple views of the same data are possible.
  • the same set of data points may be represented using a histogram or a table.
  • the controller mediates input and converts it to commands for the browser model or view.
  • the browser models employed by browser 1001 are what communicate with application 1022 on the server side. Specifically, when a user clicks on a search form presented in a view, an underlying browser model communicates to application servlet 1024.
  • Application servlet 024 in one embodiment, can be a document server (DS) resource.
  • system S1 can be a document server communicatively connected to application servlet 1024 and hence application 1022 via managed connection M1 to connector C1 and hence integration services 1060. Integration services 1060 may also be a DS resource. All DS resources are registered with the document server.
  • search API 1051 may authenticate the user (via authentication filter 061), make sure that the search query has the authenticated user information in it, and call search engine 1013.
  • search engine 1013 may implement Solr Cloud.
  • Solr Cloud is multiprocess distributed Solr. It may have multiple Solr nodes. Solr Cloud and Solr nodes are known to those skilled in the art and thus are not further described herein.
  • search engine 1013 may utilize a unified index such as unified index
  • unified index 715 may be built by running data collector 1073A to collect data from information systems S1 , S3, S5, and S7 at the backend, processing the collected data using ingestion pipeline 1053, and indexing the processed data.
  • data collected from information systems at the backend may be stored in shared folder 1085 and ingestion pipeline 1053 may read data from shared folder 1085, process the data, and provide the output to search engine 1013 for indexing.
  • shared folder 1085 can be implemented utilizing an Extensible Markup Language (XML) file and a binary file.
  • XML Extensible Markup Language
  • data collector 1073A may collect data from information systems using repository specific connectors and without using integration services 1060 in a manner similar to data collector 473 described above with reference to FIGURE 4.
  • data collector 1073B may collect data from information systems through integration services 1060 using connectors C1 , C3, C5, and C7 in connector framework 1070 in a manner similar to data collector 773 described above with reference to FIGURE 7.
  • console based administration 1087 may allow an administrator user to perform command line tasks (other than using a graphical user interface) relating to data collector 1073A.
  • administration API 1057 may allow an administrator user to perform administrative tasks relating to ingestion pipeline 1053.
  • authorization servlet 1066 may check with information system(s) at the backend as to what this user is permitted to view. If the user does not already have a session with a requested information system, credential servlet 1067 may access credential store 1069 to retrieve the user's credentials (e.g., a user ID and password) and calls CMIS servlet 1063 to open a session.
  • the user password may be padded or normalized, encrypted and stored in database 1090 which may reside behind a firewall.
  • search API 1051 may call principals servlet 1068 to find out what the user is permitted to view per their principal(s), as explained above, before calling search engine 1013.
  • Both authorization servlet 1065 and principals servlet 1068 can be optional in some embodiments.
  • CMIS servlet 1063 may utilize connectors C1 , C3, C5, and C7 to map metadata from information systems S1 , S3, S5, and S7 to an IS common model.
  • Each of the connectors C1 , C3, C5, and C7 may be communicatively connected to information systems S1 , S3, S5, and S7 via managed connections 1 , M3, M5, and 7.
  • Connectors C1 , C3, C5, and C7 are capable of performing bi-directional CMIS mapping described above.
  • CMIS servlet 1063 knows which connector to call for which information system by utilizing the repository identifier (ID) in the search result.
  • the repository ID is placed in the index along with the object ID for each object indexed in the unified index.
  • CMIS servlet 1063 may call a connector associated with the repository ID in the search result to obtain an object having the associated object ID.
  • a search result may be provided to a user in various ways.
  • a link may be provided to the user via browser 1001 .
  • the user may be connected directly to a repository application (e.g., a content management application running on information system S1).
  • the user may be presented with an option to share the search result via a secure content sharing and synchronization system.
  • a suitable secure content sharing and synchronization system readers are directed to U.S. Patent Application No. 13/651 ,367, filed October 12, 2012, entitled “SYSTEM AND METHOD FOR SECURE CONTENT SHARING AND SYNCHRONIZATION,” which is incorporated by reference herein.
  • S3, S5, and S7 may be preconfigured connectors provided by system 900.
  • a connector service provider may add an extensible connector C9 to create managed connection M9 for communicating with information system S9.
  • An administrator may configure connector C9 using connector SPI 1065, as explained above.
  • authentication filters such as authentication filter 1061 may be utilized to control access to information systems S1 , S3, S5, and S7. In some cases, there may not be a need to have control over access.
  • an external authentication server may be used.
  • application 1022 may perform or otherwise handle authentication. Accordingly, depending upon applications, authentication filter 1061 and credential servlet 1067 may be optional.
  • application 1022 may be a non-search based application and, therefore, search components such as search API 1051 and search engine 1013 may be optional. Depending upon whether application 1022 may be used for search purposes, different methods of information integration may be implemented, as illustrated in FIGURES 1 1 and 12.
  • FIGURE 1 1 depicts a flow diagram illustrating one embodiment of a method for information integration across disparate information systems for non-search based applications.
  • Method 1 100 may comprise connecting an information integration system to a non-search based application and disparate information systems (step 1 102).
  • Step 1 102 may be optional when adding extensible connector(s) post-installation of the information integration system.
  • Method 1 100 may further comprise configuring the connectors for bi-directional CMIS mapping as described above (step 1 104). Once the connectors are configured, method 1 100 may start integration services and service the non-search based application using the configured connectors.
  • FIGURE 12 depicts a flow diagram illustrating one embodiment of a method for information integration across disparate information systems for search based applications.
  • Method 1200 may comprise connecting an information integration system to a search based application and disparate information systems (step 1202).
  • Step 1202 may be optional when adding extensible connector(s) post-installation of the information integration system.
  • Method 1200 may further comprise configuring the connectors for bi-directional CMIS mapping as described above (step 1204); collecting data from the information systems (step 1206); analyzing data (which may entail converting content to text, summarizing the content, and determining keywords from the content, etc.) (step 1208); and building a unified index using data mapped to the IS common model as described above (step 1210). Depending upon implementation, data can be collected and then mapped or mapped and then collected. The unified index may be synchronized with the information systems at the backend (step 1212). Finally, method 1200 may start integration services and service the search based application using the configured connectors and the unified index (step 1214). From time to time, or on demand, the unified index may be synchronized with the information systems at the backend to ensure that the indexed information is up-to-date.
  • document conversion may be performed by a data collector.
  • document conversion may be performed by an ingestion pipeline.
  • this document conversion component may take a text based document and extract the text from it for indexing, takes a portable document format (PDF) document and extract the text from it for indexing, etc.
  • PDF portable document format
  • This can be useful because some applications can write to the ingestion pipeline and do the conversion there and the data thus processed gets indexed without having to use a data collector or integration services.
  • the ingestion pipeline is configurable, so it will also work when the document conversion is performed by a data collector.
  • Embodiments disclosed herein can work with various types of applications.
  • Example use cases may include, but are not limited to discovery, content assessment, data migration, lifecycle management, etc.
  • Embodiments of an information integration system disclosed herein provide a unified way for an application to analyze, search, manage, manipulate, and/or access disparate information systems at the backend while providing an easy way to add new information systems via extensible connectors without requiring custom integration.
  • search results from various information systems can be integrated at the information integration system and provided to an application connected thereto.
  • the application may present the search results in various ways, one example of which is illustrated in FIGURE 13.
  • FIGURE 13 depicts a diagrammatic representation of user interface (Ul) 1300 of an example discovery application displaying search results provided by one embodiment of an information integration system disclosed herein.
  • the discovery application may implement various functions of the information integration system via a unique Ul layer (e.g., user interface layer 924 shown in FIGURE 9).
  • the Ul layer may comprise a library of various user experience (UX) Ul components that can be used as building blocks by application developers and that can be combined in various ways to create different applications.
  • UX user experience
  • these UXUI components can take advantage of a unified index provided by the information integration platform.
  • the UXUI components can be configured to interface with a search API running on the information integration platform. Since the Ul layer communicates with disparate information systems through integration services, no complicated programming is required.
  • the UXUI components can be used to create one or more filter widgets in an application to allow an end user to effortlessly create various visualizations of data across disparate information systems.
  • This approach (using UXUI components built on top of an information integration platform to create applications) makes for a very flexible and efficient way to develop custom applications for the information integration platform.
  • the example discovery application may have search function 1310 and filtering function 1320.
  • Filtering function 1320 may include various filter widgets 1322-1338.
  • Each filter widget may be associated with a UXUI component configured for visualizing data from disparate information systems according to certain metadata indexed and stored in the unified index. Examples of such metadata may include location, file system path (e.g., folder, file type, etc.), age (e.g., last modified), creator, file size, keywords, phrases, phrases, personal identifiable information (Pll), companies, language, country, departments, etc.
  • the UXUI components may implement various visualization techniques.
  • Repositories B, E, and F may store different types of information.
  • repository B may store documents written in languages of different countries
  • repository E may store information related to departments in the user's company (e.g., management, human resources, etc.); and repository F may store contents created by various authors for use in various countries.
  • Location widget 1322 may be used to select repositories B, E, and F; creator widget 1328 may be used to select author(s); and keywords widget 1332 may be used to select departments, countries, and/or language(s).
  • These user selections/inputs may be communicated to the search API running on the information integration platform.
  • the search engine uses the unified index to locate the requested data and returns the search results via the search API.
  • Filtering function 1320 may interpret the search results and use a tree map methodology to display a visualization of the search results where each box displayed in Ul 1300 represents a node in the tree, and the size of the box represents the number of the results for the metadata of interest.
  • the discovery application may allow a user to set credentials for their access to a repository at the backend, browse the data on the repository (e.g., select by type), delete a file in the repository, add an object to the repository, and/or download a document from the repository.
  • Other implementations may also be possible.
  • FIGURE 14 depicts a diagrammatic representation of a user interface of an example lifecycle management application displaying a dashboard generated using an embodiment of an information integration system disclosed herein.
  • Ul 1400 shows different visualizations 1410, 1420, 1430, and 1440. Each visualization can be a manifestation of a particular combination of UXUI components. This is further illustrated in FIGURE 15.
  • FIGURE 15 depicts a diagrammatic representation of page view 1500 illustrating filtering function 1520 having classification widget 1522, age widget 1524, access widget 1526, retention widget 1528, and document type widget 1530. Similar to what is described above with reference to FIGURE 13, user interactions with these widgets (e.g., user selections and/or inputs) may be communicated to a search API running on an embodiment of an information integration platform disclosed herein.
  • a search engine may use a unified index maintained by the information integration platform to locate the requested data (selected via one or more of widgets 1522-1530, in this example) and returns search results via the search API.
  • Filtering function 1520 may interpret the search results and display a visualization of the search results using a bar chart. Various other visualization techniques are also possible.
  • the bar chart provides a visualization of classified vs.
  • Classified means that a records management classification (or any other category) has been assigned to these documents.
  • a classification can be assigned by various ways: manually by end user, by inheritance from a folder or by an automated system such as Auto-Classification.
  • Unclassified means that these documents do not have a records management classification or any other categories. Records management classifications are used to organize information and drive retention and disposal of content as required by law and/or policy. This chart provides an overview of the proportion of content that is under a retention policy vs. content that is not subject to classification.
  • an extract, transform, and load (ETL) tool called Open Text Integration Center (OTIC) can provide a non-limiting example of application 222.
  • OTIC provides core ETL capabilities, combining database functions such as extract, transform, load into one tool to pull data out of one database and place it into another database.
  • Extract refers to the process of reading data from a database.
  • Transform refers to the process of converting the extracted data from its previous form into the form it needs to be in so that it can be placed into another database.
  • Load refers to the process of writing the data into the target database.
  • information integration server 250 may include integration services 260 which can provide OTIC with synchronous access to backend systems 280 residing at storage tier 240, allowing OTIC to serve as a hub of enterprise content management (ECM) and process data among databases.
  • An EC system such as Open Text Content Server (OTCS) can provide a non-limiting example of a backend system.
  • FIGURE 16 depicts a diagrammatic representation of improved, CMIS-compliant integration services architecture that provides an ECM- independent ETL solution.
  • FIGURE 16 depicts a diagrammatic representation of improved, CMIS-compliant integration services architecture that provides an ECM- independent ETL solution.
  • an object of the invention is to generalize ECM support through CMIS- compliant components at integration tier 1630, eliminating a need to configure each individual application 1622 with ECM-specific support.
  • application 1622 can be enhanced, for instance, by adding a new object type called "Secondary Type.” Using OTIC as a non- limiting example of application 1622, a new OTIC object type "Secondary Type" would be added.
  • CMIS-compliant connectors 1670 can map ECM-specific object types from ECM system
  • CMIS-compliant connectors 1670 are repository-specific. Accordingly, suppose OTCS exemplifies ECM system 1680, CMIS-compliant, repository-specific connectors for OTCS may be referred to as OTCS connectors or CS connectors.
  • CS connectors are particularly configured to map CS types, including CS categories, to CMIS secondary types (which can be used by any application that follows the CMIS data model).
  • a CS connector can map "properties" from OTCS, Documentum, ECM, etc. to a secondary type (if there is not a primary type to map to) so that regardless of where content comes from (e.g., OTCS or Documentum or ECM, etc.), the CS connector can map the content to some primary type or secondary type in CMIS. In this way, every piece of content gets a "type" (either primary or secondary), regardless of the source of the content.
  • Any "secondary type” could be attached to any "primary type” (e.g., a document, a folder, a CMIS item , etc.).
  • a technical effect is that documents from disparate systems 1680 can be linked through IS server 1650 to one another even if they were created in distinct systems 1680.
  • the C IS "secondary object types" (also referred to herein as “secondary types") feature was introduced in CMIS 1.1.
  • a secondary type defines a set of properties that can be dynamically added to and/or removed from objects. This is different from primary object types (also referred to herein as "primary types").
  • Primary types such as documents and folders have a predefined set of properties that are fixed. With secondary object types, additional properties can be added to and/or removed from CMIS objects.
  • each instance of a primary type corresponds to a distinct object; whereas, each instance of a secondary object type does not correspond to any object.
  • Secondary types are not permanent and do not exist on their own, without being applied to a primary type.
  • a secondary type definition can be provided for a "category,” but this "category" is not created until it is applied to an object (e.g., a file or a folder) so that the object has can additional property called "category.”
  • the secondary type is not creatable, file-able, or controllable.
  • the "creatable,” “fileable,” “controllablePolicy,” and “controllableACL” object type attributes are not applicable to a secondary type and are set to FALSE by default. Secondary types can be applied at object creation time (e.g., by populating the multi-value property
  • cmis:secondaryObjectTypelds property either through the updateProperties service or the checkln service (in CMIS service). Adding the id of a secondary type to this multi value property adds the secondary type. Providing values for the associated properties of this secondary type may be done in the same operation. Removing the id of a secondary type from this multi-value property removes the type and all associated properties and values.
  • Secondary types can be markers without properties. For example, if a document has a CS record management (RM) hold, a secondary type attached to the document may indicate that there is a CS RM hold and no additional properties.
  • RM CS record management
  • a repository (e.g., ECM system 1680) at storage tier 1640 is to be connected to IS 1660 via its own CMIS- compliant connector 1670. All secondary types should be inherited directly or indirectly from a CMIS secondary type base object type (e.g., "cmis:secondary"). If a repository does not support secondary types, the secondary type base object type will not be returned by a service call (e.g., getTypeChildren) and no secondary types will appear next to the document or folder being called.
  • a repository that does not support secondary types may throw a constraint exception when, for instance, a user of application 1622 tries to apply a secondary type to an object managed by the repository. The exception may notify the user that a secondary type cannot be added to or removed from the object.
  • a repository may support create, read, update and delete (CRUD) operations for secondary types through CM IS repository services (e.g., via methods such as getTypeDefinition, createType, updateType, deleteType).
  • CRUD create, read, update and delete
  • Such CRUD support can be connector-specific.
  • a goal in implementing CMIS secondary types in IS 1660 is to support OTCS's category feature. Similar to a secondary type, a CS category defines additional attributes that can be dynamically applied to or removed from an object. That is, once a CS category is applied to a CS object, that CS object has additional properties.
  • CMIS categories in CS appear as primary type objects in the CS object tree and can be created, modified, deleted as regular objects. Recall that secondary types cannot exist on their own and must be applied to a primary type object. This is a technical conflict between CMIS and CS implementations or, more specifically, between CMIS secondary types and CS categories.
  • connectors 1670 can be particularly configured to implement CMIS-compliant, CS-specific, and non-application-specific REST Connector Web Services (REST/CWS connectors).
  • REST/CWS connectors are referred to herein as CS connectors.
  • CS connectors allow seemingly unrelated applications to connect dynamically through REST.
  • a CWS universal resource locator (URL) may specify the location of IS server 1650 that provides the connector web services and with which a particular CS connector communicates directly.
  • FIGURES 17A-17B provide, as a non-limiting example, types and operations 1700 of an embodiment of a CS connector.
  • the primary type is defined for the CS connector as being inherited from "cmis:document" for category objects appearing in the CS object tree.
  • all category objects may have a specific CMIS document type identified by subtype identifier 1701 (e.g., "131 " as shown in FIGURES 17A-17B).
  • Each instance of a CS category has a definition and can be viewed in a C IS type definition tree as a secondary type with "131 : ⁇ category_id>" value as a type id. This type id can be used when applying or removing a category from primary type objects.
  • a category object When a user views a CS category object through CMIS, the user can see that the CS category object has a special property which points to a secondary type associated therewith. That is, in the content server and in its connectors, a category object is defined so that when a user navigates, for instance, via an administrative graphical user interface (GUI) of IS server 1650, to the content server's object tree, the category object can be viewed as a document which has a type "131 " inherited from "cmis:document.” An example view is shown in FIGURE 18.
  • GUI administrative graphical user interface
  • FIGURE 18 three documents are shown. Two of the documents are actually category objects having the specific CMIS document type "131 " and one document has a type having a subtype identifier "141 .” Referring to FIGURES 17A-17B, both subtypes "131 " and "141 " are inherited from the primary type "cmis:document.” As illustrated in FIGURE 18, in addition to CMIS information pertaining to object properties and version properties, the user can also view category properties, classification properties, and hold properties.
  • FIGURES 19 and 20 depict diagrammatic representations of screenshots from a GUI of application 1622 illustrating how a user of application 1622 may view "secondary types" (e.g., CS categories) as "documents.”
  • FIGURE 19 shows an example of an OTIC "secondary type” with three date attributes
  • FIGURE 20 shows another example of an OTIC "secondary type” with three int attributes. Only the CMIS representation of each attribute is shown.
  • FIGURE 21 shows a document with two "secondary types" ("Ext1 " and "Ext2”) attached.
  • the GUI of application 1622 shows only CMIS representation of each attribute.
  • Operations on these special "documents" can be limited to management functions (e.g., view, delete, etc.). For example, if a user wishes to delete a folder which contains categories, the user should first delete those categories "documents.” Furthermore, each category as an object and as a secondary type should be in sync. For example, deleting a "category" as an object from the CS object tree also removes the secondary type from the CMIS type definition tree. Likewise, deleting the secondary type from the CMIS type definition tree, the corresponding object in the CS object tree should also be deleted.
  • management functions e.g., view, delete, etc.
  • CS connector 1670 may try to import (e.g., from OTCS
  • CS connector 1670 can retrieve whatever CS connector 1670 is allowed to retrieve (e.g., category definitions, CS RM classification definitions, RM holds, etc.) from OTCS 1680, if available based on user account privileges.
  • CS connector 1670 may only import the CS definition created by the same user and not import CS definitions created by other CS users.
  • FIGURE 24 provides an example view of what a user can view via an administrative GUI of
  • the user can view properties (also referred to herein as attributes) with the appropriate category attached. When a category is attached, the properties will come across with the category type id (e.g., "131 "). As shown in FIGURE 24, the user gets the "Secondary Type Id" property as part of the object property. This tells the user that category "77037” is attached. Because the value for this property, the object type id is therefore "131 :77037,” as shown in FIGURE 24. With this object type id, the user can view (and it references) all the category attributes and information provided by this category "77037.” Here, the user can view this category as a primary type, meaning that it is viewed as a CMIS document.
  • properties also referred to herein as attributes
  • FIGURES 25A-25B provide an example view of "Types” showing imported category
  • FIGURES 25A-25B show in more detail a classification called
  • CMIS RepositorylD a repository field referred to as "CMIS RepositorylD" 2610 as shown in FIGURE 26
  • OTIC can be implemented with a new OTIC object type called
  • secondary type and the parent object for "secondary type” can be an OTIC repository based on the CMIS connection.
  • "Secondary type” cannot have another "secondary type” attached to it. Any “secondary type” could be attached to any "primary type” (e.g., document, folder, CMIS item, etc.).
  • secondary type attributes or properties will be editable (e.g., add, modify, delete, etc.) to the OTIC user via the GUI.
  • Each attribute will have CMIS representation.
  • An attribute representation for "secondary type” may be called “native view” and may consist of the view of all attributes represented in the native format (e.g. , XML as an example for atom pub binding).
  • a "native view” may be editable by the user and could be created during a metalink flow.
  • metalinks refer to pluggable metadata bridges embedded in an EMC service provided by the integration services.
  • a “native view” could have a hierarchical representation of attributes. Both "native view” and
  • CMIS representations may be stored in the OTIC object (e.g., inside application 1622).
  • a "native view” representation may be used only in case when a user wants to create an instance of a "secondary type” object on the server. In all other cases, CMIS
  • Objects of "secondary type" could be created manually by a user or via a metalink.
  • following logic will be applied:
  • “native view” can be stored as an empty string.
  • a module instruction e.g., a modeled script called
  • “CreateTypedEcmltem" will become invalid with a proper message.
  • it is up to the CS connector (e.g., connector 1670 in FIG. 16) to present to OTIC (e.g., application 1622) with a flatten structure.
  • OTIC can use the same flatten structure to communicate back to the CS connector.
  • the CS connector may provide a 'key' to link the "native view" for each attribute to its "CMIS definition.”
  • CMIS Item can be added to OTIC. This object type can be similar to an OTIC object ECM Document. It covers C IS objects that do not fit into “documents” and “folders," for example, "CS URL.”
  • the parent object for "CMIS Item” is the OTIC repository based on the CMIS connection.
  • CMIS Item is considered as one of the "primary type” and could have "secondary type(s)” attached to it. However, “CMIS Item” itself cannot be attached to any object. Attribute definition and business rules for "CMIS Item” are the same as those for the new OTIC object "secondary type” discussed above.
  • FIGURE 27 depicts a diagrammatic representation of property editor 2700 which a user can use to manually attach or detach secondary types.
  • OTIC primary objects "Document” and "Folder” based on a CMIS repository can also be modified.
  • a document and a folder may allow a user to attach object(s) of "secondary type” the same way as "Livelink” categories can be attached to documents and/or folders.
  • "Livelink” was the first Web-based collaboration and document management system from Open Text, which is part of the Open Text ECM Suite. More than one "secondary type” can be attached to the same document/folder. Attributes from an attached "secondary type” is visible on the document/folder GUI of OTIC.
  • OTIC user can attach or detach "secondary type” from a document/folder.
  • a metalink can attach "secondary type(s)" during import (e.g., using typed module instructions "to write,” as explained below).
  • OTIC objects (which contain metadata) can be stored inside of OTIC (e.g., application 1622) and the corresponding definition can be stored inside the OTIC repository (e.g., ECM system 1680). This provides a technical effect of allowing OTIC to retrieve or create a document using CMIS-compliant types to manipulate CMIS data.
  • application 1622 may include generic module instructions "to read.”
  • LoadEcmltem can allow loading metadata of "secondary type” object at run-time. New type id for object "secondary type” should be included into UID line. Loaded “secondary type” data can be placed under data tree node “/Secondary Types.” Furthermore, each "secondary type” can have its own node under “/Secondary Type.”
  • application 1622 may also include typed module instructions "to write.”
  • Typed module instructions can allow creating document, folder, CMIS item, secondary type with attached “secondary type,” providing attribute values at run-time.
  • FIGURES 19 and 20 provide examples of “secondary types” (CS categories transformed as OTIC objects of the "secondary types,” unbeknownst to application 1622) created using typed module instructions "to write.” They can be created using the following typed module instructions:
  • ParamValue /SecondaryTypes/SecondaryType /Ext2/Attr_lnt2 0
  • ParamValue /SecondaryTypes/SecondaryType /Ext2/Attr_lnt3 0
  • an ECM-independent ETL tool comprising a CMIS-compliant, repository-specific connector is provided to resolve technical conflicts between CMIS secondary types and certain ECM features such as content server categories, and allow the underlying ECM system to be fully C IS-compliant. Any application can be adapted to leverage and/or take advantages of the ECM-independent ETL tool disclosed herein.
  • ECM-independent ETL tool may include configuring a CMIS-compliant, repository-specific connector to support CMIS documents, CMIS folders, CMIS primary types, and CMIS secondary types and operations (see FIGURES 17A-17B) (2801).
  • the repository-specific connector can be particularly configured for a repository having categories as primary objects.
  • the repository-specific connector can operate on an integration services server at an integration tier between an application tier and a storage tier where the repository resides.
  • Method 2800 may further comprise configuring an application operating at the application tier on a user device to add a secondary type object type and a CMIS item object type, as described above (2805).
  • the secondary type object type and the CMIS item object type for the application are primary object types such that C IS secondary types are attachable to the secondary type object type and the CMIS item object type for the application.
  • the user device can be communicatively connected to the integration services server over a network.
  • FIGURE 29 is a flow chart illustrating an example use case when a user of the application has requested to access a repository via the integration services server on which the C IS- compliant, repository-specific connector operates.
  • a CMIS connection may be established with the repository and the connector started (2901).
  • the connector may operate to import any category definition from the repository
  • this operation may be based on an account privilege of the user, as described above.
  • the category definition contains properties associated with a category in the repository that can be dynamically applied to or removed from an object managed by the repository. As a result of this import operation, all the properties are now viewable via a GUI of the integration services server.
  • a document of the secondary type object type can be created within the application, for instance, responsive to an instruction from the user of the application (2910).
  • the document can be created using typed module instructions that obtain the properties from the category definition at run-time via the repository-specific connector.
  • the repository-specific connector is configured with a category object type having a category type identifier.
  • the category object type can be inherited from a primary C IS document type. The category has a category identifier and, if the category is attached to the document, the document is automatically associated with the properties from the category definition via the category type identifier and the category identifier, as explained above.
  • a view of the document of the secondary type object type can be generated (2920).
  • the view may contain the properties from the category definition.
  • the view can then be displayed on the user device (2925).
  • FIGURE 30 depicts a diagrammatic representation of a data processing system for
  • data processing system 3000 may include one or more central processing units (CPU) or processors 3001 coupled to one or more user input/output (I/O) devices 3002 and memory devices 3003.
  • I/O devices 3002 may include, but are not limited to, keyboards, displays, monitors, touch screens, printers, electronic pointing devices such as mice, trackballs, styluses, touch pads, or the like.
  • memory devices 3003 may include, but are not limited to, hard drives (HDs), magnetic disk drives, optical disk drives, magnetic cassettes, tape drives, flash memory cards, random access memories (RAMs), read-only memories (ROMs), smart cards, etc.
  • Data processing system 3000 can be coupled to display 3006, information device 3007 and various peripheral devices (not shown), such as printers, plotters, speakers, etc. through I/O devices 3002.
  • Data processing system 3000 may also be coupled to external computers or other devices through network interface 3004, wireless transceiver 3005, or other means that is coupled to a network such as a local area network (LAN), wide area network (WAN), or the Internet.
  • LAN local area network
  • WAN wide area network
  • Internet the Internet
  • the invention can be implemented or practiced with other computer system configurations, including without limitation multiprocessor systems, network devices, mini-computers, mainframe computers, data processors, and the like.
  • the invention can be embodied in a general purpose computer, or a special purpose computer or data processor that is specifically programmed, configured, or constructed to perform the functions described in detail herein.
  • the invention can also be employed in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network such as a LAN, WAN, and/or the Internet.
  • program modules or subroutines may be located in both local and remote memory storage devices.
  • program modules or subroutines may, for example, be stored or distributed on computer- readable media, including magnetic and optically readable and removable computer discs, stored as firmware in chips, as well as distributed electronically over the Internet or over other networks (including wireless networks).
  • Example chips may include Electrically Erasable Programmable Read-Only Memory (EEPROM) chips.
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • Embodiments discussed herein can be implemented in suitable instructions that may reside on a non-transitory computer readable medium, hardware circuitry or the like, or any combination and that may be translatable by one or more server machines. Examples of a non-transitory computer readable medium are provided below in this disclosure.
  • ROMs, RAMs, and HDs are computer memories for storing computer-executable instructions
  • Suitable computer-executable instructions may reside on a computer readable medium (e.g., a ROM, a RAM, and/or a HD), hardware circuitry or the like, or any combination thereof.
  • a computer readable medium e.g., a ROM, a RAM, and/or a HD
  • a computer-readable medium may refer to a data cartridge, a data backup magnetic tape, a floppy diskette, a flash memory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.
  • the processes described herein may be implemented in suitable computer-executable instructions that may reside on a computer readable medium (for example, a disk, CD-ROM, a memory, etc.).
  • the computer-executable instructions may be stored as software code components on a direct access storage device array, magnetic tape, floppy diskette, optical storage device, or other appropriate computer-readable medium or storage device.
  • Any suitable programming language can be used to implement the routines, methods or programs of embodiments of the invention described herein, including C, C++, Java, JavaScript, HTML, or any other programming or scripting code, etc.
  • software/hardware/network architectures may be used.
  • the functions of the disclosed embodiments may be implemented on one computer or shared/distributed among two or more computers in or across a network. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.
  • Any particular routine can execute on a single computer processing device or multiple computer processing devices, a single computer processor or multiple computer processors.
  • Data may be stored in a single storage medium or distributed through multiple storage mediums, and may reside in a single database or multiple databases (or other data storage techniques).
  • steps, operations, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, to the extent multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments may be performed at the same time.
  • the sequence of 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. Functions, routines, methods, steps and operations described herein can be performed in hardware, software, firmware or any combination thereof.
  • Embodiments described herein can be implemented in the form of control logic in software or hardware or a combination of both.
  • the control logic may 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.
  • an information storage medium such as a computer-readable medium
  • a person of ordinary skill in the art will appreciate other ways and/or methods to implement the invention.
  • a "computer-readable medium” may 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).
  • non-transitory computer-readable media can include random access memories, read-only memories, hard drives, data cartridges, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices.
  • some or all of the software components may reside on a single server computer or on any combination of separate server computers.
  • a computer program product implementing an embodiment disclosed herein may comprise one or more non-transitory computer readable media storing computer instructions translatable by one or more processors in a computing environment.
  • a "processor” includes any, hardware system, mechanism or component that processes data, signals or other information.
  • a processor can include a system with a general-purpose central processing unit, multiple processing units, dedicated circuitry for achieving functionality, or other systems. Processing need not be limited to a geographic location, or have temporal limitations. For example, a processor can perform its functions in "real-time,” “offline,” in a “batch mode,” etc. Portions of processing can be performed at different times and at different locations, by different (or the same) processing systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un outil ETL indépendant d'ECM comprenant un connecteur conforme à CMIS et spécifique au référentiel, destiné à résoudre un conflit entre des types secondaires CMIS et certaines caractéristiques d'ECM telles que des catégories de serveur de contenu, et à permettre au système ECM sous-jacent d'être pleinement conforme à CMIS. Fonctionnant sur un serveur de services d'intégration au niveau d'un niveau d'intégration entre un niveau d'application et un niveau de stockage où se situe le référentiel, le connecteur est spécialement configuré pour prendre en charge des types secondaires CMIS et est spécifique au référentiel. Lors du démarrage, le connecteur peut importer n'importe quelle définition de catégorie à partir du référentiel. La définition de catégorie contient des propriétés associées à une catégorie dans le référentiel. Lorsque la catégorie est liée à un document, les propriétés sont visibles par l'intermédiaire d'un type d'objet de catégorie spéciale et d'un identifiant de catégorie pour la catégorie. N'importe quelle application peut être adaptée afin d'exploiter l'outil ETL indépendant d'ECM de la présente invention.
PCT/CA2018/050377 2017-03-28 2018-03-28 Systèmes, procédés et produits de programme informatique de services d'intégration destinés à des outils etl indépendants d'ecm WO2018176139A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP18777079.7A EP3602323A1 (fr) 2017-03-28 2018-03-28 Systèmes, procédés et produits de programme informatique de services d'intégration destinés à des outils etl indépendants d'ecm

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/471,823 US10073956B2 (en) 2013-03-14 2017-03-28 Integration services systems, methods and computer program products for ECM-independent ETL tools
US15/471,823 2017-03-28

Publications (1)

Publication Number Publication Date
WO2018176139A1 true WO2018176139A1 (fr) 2018-10-04

Family

ID=63673837

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2018/050377 WO2018176139A1 (fr) 2017-03-28 2018-03-28 Systèmes, procédés et produits de programme informatique de services d'intégration destinés à des outils etl indépendants d'ecm

Country Status (2)

Country Link
EP (1) EP3602323A1 (fr)
WO (1) WO2018176139A1 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109474418A (zh) * 2019-01-22 2019-03-15 网易（杭州）网络有限公司 文档加密方法、文档解密方法、装置、介质和计算设备
CN110134728A (zh) * 2019-05-09 2019-08-16 浪潮软件集团有限公司 一种基于全文搜索提供地图空间数据的方法及系统
US20220200994A1 (en) * 2020-12-21 2022-06-23 Dropbox, Inc. Evaluating access based on group membership
CN114880169A (zh) * 2022-06-09 2022-08-09 杭州比智科技有限公司 一种基于JavaSPI实现热更新动态适配的方法及系统
US11789976B2 (en) 2020-12-21 2023-10-17 Dropbox, Inc. Data model and data service for content management system
US11803652B2 (en) 2020-12-21 2023-10-31 Dropbox, Inc. Determining access changes
US12001574B2 (en) 2020-12-21 2024-06-04 Dropbox, Inc. Evaluating an access control list from permission statements
US12019599B2 (en) 2020-12-21 2024-06-25 Dropbox, Inc. Data model and data service for content management system
US12174814B2 (en) 2020-12-21 2024-12-24 Dropbox, Inc. Aggregates index

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050044530A1 (en) * 2003-08-21 2005-02-24 Lev Novik Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by a hardware/software interface system
US20060026162A1 (en) * 2004-07-19 2006-02-02 Zoran Corporation Content management system
US20060074906A1 (en) * 2004-10-05 2006-04-06 Luc Steels Self-organization approach to semantic interoperability in peer-to-peer information exchange
US20070198539A1 (en) * 2001-04-13 2007-08-23 Warshavsky Alex S Method and apparatus for mapping between XML and relational representations
US20100076992A1 (en) * 2004-06-01 2010-03-25 Symyx Software, Inc. Methods and Systems for Data Integration
US20100211489A1 (en) * 2007-07-25 2010-08-19 Intraco Technology Pte Ltd Content management and delivery system
US20130219456A1 (en) * 2012-01-06 2013-08-22 Rahul Sharma Secure Virtual File Management System
US20140019426A1 (en) * 2012-07-12 2014-01-16 Open Text S.A. Systems and methods for in-place records management and content lifecycle management
US20140282910A1 (en) * 2013-03-14 2014-09-18 Open Text S.A. Systems, methods and computer program products for information integration across disparate information systems

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070198539A1 (en) * 2001-04-13 2007-08-23 Warshavsky Alex S Method and apparatus for mapping between XML and relational representations
US20050044530A1 (en) * 2003-08-21 2005-02-24 Lev Novik Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by a hardware/software interface system
US20100076992A1 (en) * 2004-06-01 2010-03-25 Symyx Software, Inc. Methods and Systems for Data Integration
US20060026162A1 (en) * 2004-07-19 2006-02-02 Zoran Corporation Content management system
US20060074906A1 (en) * 2004-10-05 2006-04-06 Luc Steels Self-organization approach to semantic interoperability in peer-to-peer information exchange
US20100211489A1 (en) * 2007-07-25 2010-08-19 Intraco Technology Pte Ltd Content management and delivery system
US20130219456A1 (en) * 2012-01-06 2013-08-22 Rahul Sharma Secure Virtual File Management System
US20140019426A1 (en) * 2012-07-12 2014-01-16 Open Text S.A. Systems and methods for in-place records management and content lifecycle management
US20140282910A1 (en) * 2013-03-14 2014-09-18 Open Text S.A. Systems, methods and computer program products for information integration across disparate information systems

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109474418A (zh) * 2019-01-22 2019-03-15 网易（杭州）网络有限公司 文档加密方法、文档解密方法、装置、介质和计算设备
CN110134728A (zh) * 2019-05-09 2019-08-16 浪潮软件集团有限公司 一种基于全文搜索提供地图空间数据的方法及系统
CN110134728B (zh) * 2019-05-09 2023-02-14 浪潮软件集团有限公司 一种基于全文搜索提供地图空间数据的方法及系统
US20220200994A1 (en) * 2020-12-21 2022-06-23 Dropbox, Inc. Evaluating access based on group membership
US11789976B2 (en) 2020-12-21 2023-10-17 Dropbox, Inc. Data model and data service for content management system
US11799958B2 (en) * 2020-12-21 2023-10-24 Dropbox, Inc. Evaluating access based on group membership
US11803652B2 (en) 2020-12-21 2023-10-31 Dropbox, Inc. Determining access changes
US12001574B2 (en) 2020-12-21 2024-06-04 Dropbox, Inc. Evaluating an access control list from permission statements
US12019599B2 (en) 2020-12-21 2024-06-25 Dropbox, Inc. Data model and data service for content management system
US12174814B2 (en) 2020-12-21 2024-12-24 Dropbox, Inc. Aggregates index
CN114880169A (zh) * 2022-06-09 2022-08-09 杭州比智科技有限公司 一种基于JavaSPI实现热更新动态适配的方法及系统

Also Published As

Publication number Publication date
EP3602323A1 (fr) 2020-02-05

Similar Documents

Publication Publication Date Title
US12235935B2 (en) Integration services systems, methods and computer program products for ECM-independent ETL tools
US12255896B2 (en) Security systems, methods, and computer program products for information integration platform
US12235919B2 (en) Systems, methods and computer program products for information management across disparate information systems
US20240385996A1 (en) Systems and methods for in-place records management andcontent lifecycle management
WO2018176139A1 (fr) Systèmes, procédés et produits de programme informatique de services d'intégration destinés à des outils etl indépendants d'ecm

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18777079

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018777079

Country of ref document: EP

Effective date: 20191028