Cross Repository Aggregation

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

Cross Repository Concepts

Table of Contents

• 1 Overview


• 2 Type


• 3 Actors


• 4 Executives


• 5 Exceptions

Overview

There is a clear desire on the part of large enterprises to provide seamless searching and discovery of information, content and documents in multiple vendors� repositories. One of the principal drivers of this is discovery of content that is in breach of any compliance policies. They are also interested in the discovery and exchange of knowledge between different divisions. A simple Google style of appliance has not been sufficient for most of these organizations since they want to use metadata and process information as part of the search process. A Java-only interface such as JCR is not really sufficient since it needs to apply to non-Java stores and Microsoft SharePoint. There also needs to be a way to identify the scope of the search through a consistent naming and discovery mechanism.

The pattern of cross repository searches is to present the search as portlet or web application. The user should either be able to express a simple Google-like query or be provided with a web interface for specifying a more meta-data or classification oriented search. The scope of the query should be more than one repository or JCR Workspace and should be able include multiple repositories and sub-repositories. The results should be blocked (i.e. 1-10, 11-20, etc.) and returned instantaneously. Sorting options should be supplied. The language that implements this pattern should be understandable and constructible by a SQL-literate programmer.

Some of the applications of cross repository searching are discovery of knowledge in various departmental repositories, compliance discovery of infractions and identification of knowledgeable individuals based upon the material they have contributed to various repositories. Some of these applications may be automated, but most will probably be interactive. It may be enough to return the results, but it is worth considering adding a follow-up action (a pattern in itself?) that either creates a new object in a central repository or invokes a workflow to perform a follow up action, such as send out a compliance notice.

Functionality required beyond baseline:

• UDDI discovery of available repositories
  
• A universal repository identifier
  
• Repository or workspace reference for a query
  
• Multiple credential handling
  
• Context of search for follow-up action
  

Type

User Goal

Actors

1. User � searching for content among many different repositories
   
2. System � providing the search service
   

Executives

1. User LoginCentralAuthentication logs into a central authentication service.
   
2. System ListContentTypes presents a set of content types (e.g. Case Folder, Policy, SOP, Record, ...) to select.
   
3. User SelectContentType selects the type of content in which they are interested.
   
4. System ListAvailableRepositories presents repositories available for that user and that type of content.
   
5. User SelectRepository selects repositories he wishes to search.
   
6. System ListSearchCriteria presents valid search criteria to refine the search.
   
7. User SpecifySearchCriteria specifies search criteria.
   
8. User ExecuteQuery executes query.
   
9. System ListQueryResults returns query results.
   
10. User ViewContentItem views results items.
    

Exceptions

1.a. User fails login.

2.a. System presents default metadata where none is specified.

4.a. System cannot determine what repositories are accessible by this user.

6.a. User cannot determine what valid search criteria are and provides defaults.

7.a. User specifies no search criteria.

7.b. User specifies required metadata.

9.a. System fails to run query.

9.b. System returns huge amount of data.

9.c. System times out on running query.

10.a. User has no permission to access.

10.b. Information is out of date.