IECM Use Cases

[resplin]

Obsolete Pages{{Obsolete}}

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

IECM
Unfortunately, IECM wiki is currently private, but I thought that I would post some of the things that we have been posting in that wiki here. The following are the use cases driving the definitions of the interfaces for iECM.

Click here for iECM Security Discussion

There are four main use cases based upon the business scenarios supported so far. As described by Alistair Cockburn, use case description should provide a clear actor or set of actors, the task (in this case high-level task or activity), a list of goals of the task or executives, success criteria, any extensions, any constraints, design notes, and any packages (in this case used, rather than used by). There should also be links to the detailed use cases that compose the higher level business case.

Actors as people should be clear, but some architectural use cases have systems participating as actors. I think there are two types of systems that can be considered actors, or should at least be added to the uses cases, which are the repositories being accessed and the registry that identifies the repositories being accessed and how to access them. The IECM layer / system / apps may also need to be included.

The four main business cases derived from the Business Uses Cases and Requirements document are as follows.

• Library Services Remote Repository Access - To distinguish from the JCR and WebDAV usages and to address the issues of cross platform access to and from non-Java repositories, there are the basic high-level use cases of managing content from a non-Java platform or accessing a non-Java enabled repository such as Microsoft Sharepoint. This is the uber-usecase of using a content management application that can create, read, update, delete, query, browse and review content.
  

• Cross Repository Aggregation - This is the aggregation of content from one or more repository by allowing search across many repositories, presentation of metadata about the discovered content, access of the discovered and the ability to create permanent links to the discovered content. The primary actor is the user searching for a record, document or web page that exists somewhere in a set of repositories.
  

• Inter-Repository Exchange - This is the delivery of content from one repository to another. The principal actors are the repository that is sending content, the repository that is receiving the content and the administrators who are managing this exchange. There will probably multiple use cases including the push of content from one to many repositories and the pull of content from one repository to another. There are also ancillary use cases around the follow-up actions that can occur to the exchange or the compensation to failure of the exchange.
  

• Cross Repository Notification - This is the notification of events from one or more repository. A user registers for notification of a change in a specific piece of content, a content container, or a qualification of a piece of content. The principal actor is the user who is interested in the changed content and the system that registers the event and notifies the user.
  

After discussion on the conference call of 4-March-2006, we decided that the following business use case would be put into the higher-level scenario section as it had many of the same interoperability requirements as Cross Repository Aggregation.

• Cross Repository Reporting and Business Intelligence - Cross repository reporting is used to collect information from multiple repositories and present that information in a report. Usually, this information will reside in repositories acting as a records management system, but it could also include information managed in a typical web site. The business purpose of this reporting is either to analyze records or information in multiple repositories or to report form regulatory reasons.