Alfresco Developer Guide



The following diagram illustrates the idea that Alfresco One can be thought of as consisting of three main components (and this is a vast simplification), Platform, User Interface (UI), and Search. These components are implemented as separate web applications:

The main component with all the core Enterprise Content Management functionality is called the Platform and is implemented in the alfresco.war web application. It provides the repository where content is stored plus all the associated content services. AlfrescoShare provides a web client interface (i.e. UI) for the repository and is implemented as the share.war web application. Share makes it easy for users to manage their sites, documents, users and so on. The search functionality is implemented on top of Apache Solr 4 and provides the indexing of all content, which enables powerful search functionality. Besides the web clients accessing the Repository via Share there are also mobile clients that will access the content via REST APIs provided by the platform.

If we dive deeper into the platform (i.e. alfresco.war) we will see that it also supports workflow in the form of the embedded Activiti Workflow Engine. The platform is usually also integrated with a Directory Server (LDAP) to be able to sync users and groups with Alfresco. And most installations also integrates with an SMTP server so the Alfresco Platform can send emails, such as site invitations.

For more information about the internals of the Alfresco Platform, and specifically the content Repository, see the concepts section.

Besides Share there are also many other clients that can connect to the Alfresco repository, including any CMIS-compatible client, and via the Microsoft SharePoint protocol any SharePoint client. Alfresco Cloud Sync can synchronize content between an on-premise installation of Alfresco and Alfresco in the Cloud, under user control.

The Alfresco Platform also contains numerous APIs, Services, and Protocols.

The following diagram illustrates this extended platform architecture:

Note that content metadata is stored in a relational database system such as PostgreSQL, MySQL, Oracle, and so on. The content itself is stored on the file system.

Developer Guide

This Developer guide attempts to lay out the various options available to you, so you can use the right approach, depending on what you want to achieve.

You can read the material in this Developer guide sequentially, or the following table with give you some starting points if you want to dive in:

What do you want to do? Documentation
You would like to get an overview of the architecture of Alfresco from the developer’s perspective Architectural overview
You want to write client applications for Alfresco using a REST API Alfresco REST API
You are going to build a Platform Extension. Developing extensions
You want to write small extensions to Alfresco in JavaScript and FreeMarker Web Scripts
You want to create a custom REST API for Alfresco Web scripts
You want develop applications for Alfresco using RAD Alfresco SDK
You want to get developing for Alfresco using Maven Alfresco SDK
You would like to know what APIs are available for Alfresco, and when you should use them Overview of Alfresco APIs
You would like to know how to package your extensions for distribution Extension packaging
You want to write new Alfresco services in Java, and need to check what APIs are supported Alfresco Public Java API
You want to configure and customize Share Share Extensions
You would like to develop extensions to Share Developing Share Extensions
You would like to know about the new UI framework Aikau Aikau
You want to develop applications for iOS. Alfresco Mobile SDK for iOS
You want to develop applications for Android. Alfresco Mobile SDK for Android

Alfresco APIs

The following diagram illustrates the key Alfresco APIs:

As the above picture shows, there are three different kinds of customizations that you can build for Alfresco. Platform embedded extensions, Share embedded extensions, and remote extensions, also referred to as integrations.

On the platform (i.e. server) side we can add Java code and JavaScript code to extend the platform with new custom functionality such as Java Services, Repository Web Scripts, Actions, Scheduled jobs and more. These extensions are embedded in the Platform application and runs in the same JVM as the Alfresco Platform. When developing platform extension we use the Public Java APIand the Repository JavaScript API and Repository Freemarker Template API.

On the web client side we can extend Alfresco Share with new pages, dashlets, document library actions and more. These extensions are embedded in the Share web application and runs in the same JVM as Alfresco Share. When developing Share extension we use the Aikau Widget and Services Reference/API and the Spring Surf API.

Finally we can also build completely stand-alone applications and web clients that talk to the Alfresco Repository remotely. These integrations will use the REST API.

The following table provides a brief overview of each API, with links to further information:

API Type Description Support Status

This is the main public API for interfacing your client application with Alfresco. This RESTful API can be used to access both Cloud and On-Premise Alfresco repositories.

The REST API provides the ability to access core repository functionality through aCMIS REST API, such as uploading a file, and Alfresco-specific functionality, such as management of sites, can be accessed through the Alfresco REST API.

Fully supported.
Repository JavaScript API Embedded

This API is a JavaScript API used primarily for the development of Web Scripts that execute embedded in the Alfresco platform.

Web scripts are extensions to Alfresco that can be written and built without requiring compilation, and therefore have a reduced development time.

The web scripts are accessed using URLs, so can be thought of as providing the ability to create custom REST APIs.

Fully supported.
Repository Freemarker Template API Embedded

This API provides a wide-range of objects and methods for creating scripts using the FreeMarker templating language, that execute embedded in the Alfresco platform.

It provides a more limited API than the Repository JavaScript API, but with the convenience of using a simpler templating language, rather than a more complex scripting language such as JavaScript.

Fully supported.
Spring Surf API Embedded

Spring Surf is a server-side UI development framework that is used by Share. Both legacy Surf pages and new Aikau pages are based on Spring Surf. A Spring Surf page is backed by one or more presentation Web Scripts, referred to as Spring Surf Web Scripts.

The Surf Platform API is used in Surf Web Script controllers and provides a JavaScript API to allow you to access URL and page contexts, as well as calling remote REST services.

Fully supported.
Aikau Widget and Service Reference/API Embedded

This is the reference, and API, for all the new Aikau widgets and services that are used in the Share user interface. These are fully available when developing custom pages, dashlets, and menus for Share.

Fully supported.
Public Java API Embedded

When you are extending the Alfresco Platform with new content models and workflows it is often useful to provide corresponding new custom services implemented in Java. The business logic in Web Script controllers sometimes also need to be implemented in Java to use 3rd party libraries etc.

Alfresco provides numerous Java-level APIs, which are documented through the JavaDoc system. Links to the JavaDoc documentation can be found on the Alfresco Developer Site.

While in theory it is possible to access the complete range of out-of-the-box Java classes (APIs), there is a public API of classes and interfaces that you should stick to. This is to ensure that your application works on future versions of Alfresco and that you get appropriate support.

Fully supported.
Mobile SDK for iOS Remote

The SDK/API to use for developing mobile applications for iOS.

Fully Supported. Current version 1.4.
Mobile SDK for Android Remote

The SDK/API to use for developing mobile applications for Android.

Fully Supported. Current version 1.4.
Repository REST API Remote

This is the older deprecated REST API based on Web Scripts. Moving forward you should use the new REST API, which consist of the CMIS REST API and the Alfresco REST API.


Use Cases

Typical use cases that you might come in contact with when developing content management solutions, and what API to use.

The following table lists use cases and what Alfresco API to use:

Use case API
Accessing content metadata from a Platform extension such as a web script or workflow Repository JavaScript API
Accessing text content (e.g. txt, xml, html) for files from a Platform extension such as a web script or workflow Repository JavaScript API
Implementing a workflow service task that should publish content metadata to an external system via a 3rd party Java library. Public Java API
Accessing binary content (e.g. docx, pdf) for files from a Platform extension such as a web script or workflow Public Java API
Implementing a scheduled job that should access content and metadata Public Java API
Implementing a repository action that should access content and metadata Public Java API
Creating a stand-alone client talking remotely to Alfresco REST API
Changing the view for a Web Script, Dashlet, Page Repository Freemarker Template API
Creating a new Share Page or Share Dashlet Have a look at the Aikau page extension point in the Share Architecture. See also Aikau Widget Reference.
Modifying an existing Share Page or Dashlet Have a look at the Surf page extension points in the Share Architecture. Also, look at the Alfresco Share JavaScript APIs (client-side)
Developing a mobile content management application for iOS Mobile SDK for iOS
Developing a mobile content management application for Android Mobile SDK for Android

The two main categories of API are embedded and remote APIs.

The Embedded API is used for developing extensions to the Alfresco content application server. Extensions deployed into the server often depend on existing services provided by the server. Therefore, developers of extensions use the Embedded API to gain access to those services.

The Embedded API comes in several forms, where each form is structured for a particular need or kind of extension:

  • Alfresco Public Java API – a set of public Java interfaces exposed by services built into the Alfresco content application server
  • JavaScript API – an object-oriented view of the Java Foundation API specifically tailored for use in JavaScript. There is aJavaScript API for the repository tier and a JavaScript API for the Share tier.
  • FreeMarker API – an object-oriented view of the Java Foundation API specifically tailored for use in FreeMarker templates
  • Content Definition – an API for creating and editing content models
  • Workflow Definition – an API for defining business processes

The JavaScript and Template APIs are the key building blocks for web scripts to develop the RESTful APIs.

Web scripts are a popular extension for the Alfresco content application server. They allow you to define your own Remote API for clients to interact with the Alfresco content application server. A web script implementation can use any of the Embedded APIs, such as the Public Java API, JavaScript, and FreeMarker, for its implementation. Developing your own Remote API is very useful for the following scenarios:

  • Exposing new extension services deployed into the Alfresco content application server to remote clients
  • Providing alternate batching or transaction demarcation of existing services
  • Creating a facade for integration with a third-party tool, such as a Forms engine

There is another use case for the Embedded API. An application or client can also directly embed the Alfresco content application server to inherit its suite of content services.

The infrastructure of the server means it can be deployed into a number of environments, not just as a web application. Essentially, the Alfresco content application server is treated as a library, where any of its services, including the content repository, can be chosen independently or mixed to provide a custom solution. The server can scale down as well as up.

For example, the Alfresco REST API is a remote API, designed to allow you to create remote client applications. The Repository JavaScript API is an embedded API that allows you to create server-side extensions in JavaScript. The Public Java API is an embedded API that allows you to create server-side extensions that require a lower level of access, such as required if you are writing new services or Java-backed web scripts.

The Remote API is primarily used to build ECM solutions against the Alfresco content application server.

There are three main remote APIs:

  1. Alfresco One API
  3. Repository REST API (Deprecated)

The Alfresco One API was introduced with Alfresco 4.x, and is also present in the public cloud version of Alfresco. It provides the main remote API, and is the recommended API for developing remote client applications to work across cloud, on-premise and hybrid deployments of Alfresco. It comprises two sub-APIs, the Alfresco One REST API for gaining access to Alfresco-specific functionality such as Sites, and a standard CMIS API for repository manipulation and management. Alfresco SDKs such as the Mobile SDK for Android and the Mobile SDK for iOS both use the services of the Alfresco One API.

CMIS provides a standardized set of common services for working with content repositories. CMIS is not language-specific, it does not dictate how a content repository works, and it does not seek to incorporate every feature of every content repository. Alfresco provides an implementation of CMIS Web service and RESTful bindings, as well as a CMIS client API for use in Alfresco Surf and other environments.

The Repository REST API provides access to the core repository functionality using a RESTful approach. This is useful where the developer does not want to, or have a need to, write custom web scripts, and is developing a client-side application. This API can be thought of as a ready-built collection of web scripts that can be called from any client capable of making REST requests and receiving the associated responses.

Public Java API services

Provides API information based on what type of operation that should be executed.

This information groups the APIs based on what entity or function they operate on. For example, if you wanted to access a node, you would look under the Nodes section. If you are looking for a way to start workflows then you would go to the Workflow section.

References to code in different languages such as REST, Java, and JavaScript are also included.

The Public Java API provides access to Alfresco through a number of services that are exposed. These services are accessed via a single point of access – the Service Registry. This information provides an overview of the services exposed by the Public Java API.
The following table summarizes the main services available to the developer. These services are available via the service registry.
Service Description Support Status
ActionService An action represents a unit of work that can be applied to a node. Using the Action Service, actions of specific types can be created. Full Support
ActivityService A service to manage activity feeds. Full Support
AttributeService This provides services for reading, writing, and querying global attributes. Full Support
AuditService This provides services for querying audit data and enabling and disabling auditing. Full Support
AuthenticationService This service provides an API to allow authentication of users using various methods, such as username and password and authentication tickets. Full Support
CategoryService Provides a system for creating and managing categories of nodes. Full Support
CheckOutCheckInService Service to provide document locking. If a document is locked, other users cannot change its content, until it is unlocked. Full Support
ContentService A service for accessing and transforming content. Full Support
CopyService This service provides methods to copy nodes within and across workspaces and to update the state of a node, with that of another node, within and across workspaces. Full Support
DictionaryService This service represents the repository Data Dictionary. The dictionary provides access to content meta-data such as Type and Aspect descriptions. Content meta-data is organised into models where each model is given a qualified name. This means that it is safe to develop independent models and bring them together into the same repository without name clashes (as long their namespace is different). Full Support
FileFolderService Provides methods specific to manipulating files and folders. This service provides a simple way of accessing simple trees of files and folders in Alfresco. Full Support
JobLockService This service ensures that a scheduled job can only run on one node of a cluster at a time. A scheduled job could be, for example, an Activities feed job that generates email to send to everyone every night or a content cleaner job that cleans up orphaned content. Full Support
LockService A low-level locking service, used by the CheckOutCheckIn service. Does not create a working copy. Full Support
MessageService Provides methods to access the locale of the current thread and to get localised strings. These strings may be loaded from resource bundles deployed in the Repository. Full Support
MimetypeService Provides support related to content mimetype. For example, provides methods to retrieve the extension for the specified mimetype. Full Support
ModuleService A service to control and provide information about the currently-installed modules. Full Support
NamespaceService Provides access to and definition of namespace URIs and prefixes. Full Support
NodeService Provides an API for managing nodes. Full Support
NodeLocatorService The NodeLocatorService looks up node locators registered via Spring configuration by name. Full Support
PermissionService Provides an API for managing the node permissions. Permissions specify users and groups that have access to a node. Each user and group can be assigned a role. Full Support
PersonService This service encapsulates the management of people and groups. People and groups may be managed entirely in the repository or entirely in some other implementation such as LDAP or via NTLM. Some properties may be in the repository and some in another store. Individual properties may or may not be mutable. Full Support
RenditionService Provides support for rendering content nodes into other forms, known as renditions. The rendition nodes are derived from their source node and as such can be updated automatically when their source node’s content (or other properties) are changed. Examples of renditions include reformatted content (essentially a transformation from one MIME-type to another), rescaled images (including thumbnails), and the output of a Freemarker or XSLT template. Renditions can be performed synchronously or asynchronously and can be created at a specified location within the Alfresco repository. By default they are created as primary children of their source node but it is possible to have them created at other nodes specified explicitly or as templated paths. Full Support
RetryingTransactionHelper A helper that runs a unit of work inside a UserTransaction, transparently retrying the unit of work if the cause of failure is an optimistic locking or deadlock condition. Full Support
SearchService This encapsulates the execution of search against different indexing mechanisms. Full Support
SiteService Provides an extensive API for managing Sites in the Alfresco Share web client. Full Support
TaggingService It is possible to tag (a text label) any content, including folders, in Alfresco. This service provides an API for creating, deleting, and adding tags, and other tag management methods. Full Support
TemplateService Provides an API for executing template engine against a template file and data model. The service provides a configured list of available template engines. The template file can either be in the repository (passed as NodeRef string) or on the classpath. Also a template can be passed directly as a String using the processTemplateString()methods. The data model is specified to the template engine. The FreeMarker template engine is used by default. Full Support
TenantService Provides APIs around Alfresco’s multi-tenancy capability. The service is applicable in both Single Tenancy and Multi Tenancy arrangements. Full Support
VersionService Provides an API for managing the versions of a piece of content. Full Support
WorkflowService Provides a client-facing API for interacting with Alfresco workflows and tasks. Full Support
The Alfresco Repository Java API provides the ability to build server-side extensions in Alfresco ECM.
Information How to access the Java API and how to manage transactions
Architecture Information Platform Architecture, API Intro
Description The Public Java APIs, such as NodeService and ContentService, provides the ability to develop server-side extensions for Alfresco ECM. There are a number of Extension Points that make use of the Public Java API, here are some of the most used ones:

When we want to use one of the public Java APIs from an implementation of one of these Extension Points, it follows a best practice way. The first thing we need to do is acquire a reference to AlfrescoServiceRegistry. The service registry is basically a database of services, their instances and their locations. Clients of a service, such as the NodeService, then query the service registry to find the available instance of that service. When making calls to the NodeService we use the RetryingTransactionHelperfor transaction management and redundancy.

The following code snippet illustrates how to first inject the ServiceRegistry into a Spring bean:

<bean id="acmeContentService" class="org.alfresco.tutorial.publicapiaccess.service.AcmeContentServiceImpl">
      <property name="serviceRegistry">
          <ref bean="ServiceRegistry" />

In this case the ServiceRegistry is injected into a custom Service implementation, but the principle is the same for other implementations, such as for Repository Actions and Java-backed Web Scripts. When we got the service registry available in our implementation we can start using the Public Java API services such as in the following example:

public class AcmeContentServiceImpl implements AcmeContentService {
    private static Logger logger = LoggerFactory.getLogger(AcmeContentServiceImpl.class);

     * The Alfresco Service Registry that gives access to all public content services in Alfresco.
    private ServiceRegistry serviceRegistry;

    public void setServiceRegistry(ServiceRegistry serviceRegistry) {
        this.serviceRegistry = serviceRegistry;

     * Create a contract file under the /Company Home folder.
     * This will be done in a read-write transaction, retry until successful or 20 trials.
     * Joins an ongoing transaction if one exists.
    public NodeRef createContractFile(String filename, String contractTxt, AcmeContract contract) {
        NodeRef nodeRefForContract = serviceRegistry.getRetryingTransactionHelper().doInTransaction(
                new RetryingTransactionHelper.RetryingTransactionCallback<NodeRef>() {
                    public NodeRef execute() throws Throwable {
                        NodeRef parentFolderNodeRef =
                                serviceRegistry.getNodeLocatorService().getNode(CompanyHomeNodeLocator.NAME, null, null);

                        // Create Node metadata
                        QName associationType = ContentModel.ASSOC_CONTAINS;
                        QName associationQName = QName.createQName(NamespaceService.CONTENT_MODEL_1_0_URI,
                        Map<QName, Serializable> nodeProperties = new HashMap<QName, Serializable>();
                        nodeProperties.put(ContentModel.PROP_NAME, filename);
                        nodeProperties.put(DocumentType.Prop.DOCUMENT_ID, contract.getDocumentId());
                        nodeProperties.put(ContractType.Prop.CONTRACT_NAME, contract.getContractName());
                        nodeProperties.put(ContractType.Prop.CONTRACT_ID, contract.getContractId());
                        ChildAssociationRef parentChildAssocRef = serviceRegistry.getNodeService().createNode(
                                parentFolderNodeRef, associationType, associationQName, ContractType.QNAME, nodeProperties);

                        NodeRef newFileNodeRef = parentChildAssocRef.getChildRef();

                        // Set content for node
                        boolean updateContentPropertyAutomatically = true;
                        ContentWriter writer = serviceRegistry.getContentService().getWriter(
                                newFileNodeRef, ContentModel.PROP_CONTENT, updateContentPropertyAutomatically);

                        return newFileNodeRef;

        return nodeRefForContract;

As we can see in the above code, the service registry is used to access the TransactionService,NodeService, NodeLocatorService, and ContentService. All the calls to these services are done withinRetryingTransactionHelper, which will automatically join any ongoing transaction or start a new read-write transaction. If something should go wrong during these calls then they will be retried until they succeed or we reach 20 retries, which is configurable.

Permissions are also automatically checked during these calls, so you can for example not use theNodeService to create a node in a folder that you don’t have write access to. Note that theRetryingTransactionCallback class is parametrized so you can pass in any type that represent the response from the operations done in the execute method. For example, if the operations in the executemethod should result in either true or false then initialize the callback as in the following example:

     * Apply the acme:webPublished aspect to the content item with passed in node reference.
     * This will be done in a read-write transaction, retry until successful or 20 trials.
     * Joins an ongoing transaction if one exists.
     * @param nodeRef the Alfresco Repo node reference to apply the aspect to
    public void applyWebPublishedAspect(NodeRef nodeRef) {
       Boolean result = serviceRegistry.getRetryingTransactionHelper().doInTransaction(
             new RetryingTransactionHelper.RetryingTransactionCallback<Boolean>() {
                 public Boolean execute() throws Throwable {
                     Map<QName, Serializable> aspectProperties = new HashMap<QName, Serializable>();
                     aspectProperties.put(WebPublishedAspect.Prop.PUBLISHED_DATE, new Date());
                     serviceRegistry.getNodeService().addAspect(nodeRef, WebPublishedAspect.QNAME, aspectProperties);

                     return true;

If we want to be sure that a new transaction is started when we do our calls in the execute method, which is useful for situations when we just want our updates to be rolled-back if something goes wrong, then we can use another method signature for the doInTransaction method as follows:

RetryingTransactionHelper txHelper = serviceRegistry.getRetryingTransactionHelper();
boolean readOnly = false;
boolean requiresNew = true;
txHelper.doInTransaction(new RetryingTransactionHelper.RetryingTransactionCallback<Void>()
      public Void execute() throws Throwable {
         // Do something in a new transaction...
         return null;
   }, readOnly, requiresNew);

If we are using these services in a cluster, then we need to remember that they are not cluster aware. So if we for example are using these services in a scheduled job, which will be kicked off on each node in the cluster, then we would have to use the JobLockService to lock the cluster so another node does not start executing the same job. For more information about this see Scheduled jobs.

To turn on logging so you can get details of ‘why’ transactions are retried use the following log level:

Deployment – App Server It is not likely that you will deploy Java extensions directly into an Alfresco Tomcat application server as classes and Spring context files. Use an SDK build project instead.

Deployment – SDK Project

When using the Public Java API you will most likely use a Repository AMP extension project or a Simple JAR module (5.1).

The Spring context files that you should use are usually found in the repo-amp/src/main/amp/config/alfresco/module/repo-amp/context directory.

More Information
Sample Code
Alfresco Developer Blogs


The REST API lets you access content in an on-premise Alfresco repository, and in Alfresco cloud, from your own applications. The API is RESTful, which means each call is an HTTP request, so you don’t even need a programming language to try it out. You can just type a URL address in a web browser.

The REST API consists of two parts, the CMIS REST API, which lets you manage and access folders and files in the repository, and the Alfresco REST API, which lets you manage Alfresco-specific features such as ratings and comments, that are not covered by the CMIS standard.

  • Use the CMIS REST API to manage files and folders and their generic properties in the repository. For example, if you want to read, write, modify, create, or delete a file, then this is the API you use.
  • Use the Alfresco REST API to manipulate Alfresco content features that are not part of the CMIS specification. Ratings and comments are two examples of such features, and you can find a full list here.


REST API | Alfresco Documentation



Alfresco fully implements both the CMIS 1.0 and 1.1 standards to allow your application to manage content and metadata in an Alfresco repository or in Alfresco cloud. Here is a brief overview of the URL format for CMIS REST API calls, and explains the format of responses.

CMIS (Content Management Interoperability Services) is a vendor-neutral OASIS Web services interface specification that enables interoperability between Enterprise Content Management (ECM) systems. CMIS allows rich information to be shared across Internet protocols in vendor-neutral formats, among document systems, publishers and repositories, in a single enterprise and between companies.

You can use basic HTTP methods to invoke CMIS methods, or you can use one of the many language-specific libraries that wrap CMIS. One such example for the Java language is the OpenCMIS Client API provided by the Apache Chemistry project. Apache Chemistry provides client libraries for many other languages such as Python, PHP, and .NET.


CMIS REST API | Alfresco Documentation


Alfresco REST API

The Alfresco REST API lets you manage alfresco-specific features of content in an on-premise Alfresco repository, and in Alfresco cloud from your own applications.

The API gives your application access to Alfresco Networks, Sites, Containers, Comments, Ratings, tags, and workflow objects. Response and request bodies are all specified with simple JSON.

API reference | Alfresco Documentation


JavaScript API

The Repository JavaScript API lets you develop JavaScript (ECMAScript) 1.6 compatible files to access, modify, and create Alfresco repository objects such as nodes, aspects, and properties.

Use the JavaScript API for web scripts that execute JavaScript in the repository.

You can use scripts to perform the following functions:

  • Find nodes
  • Perform searches
  • Walk node hierarchies
  • Modify the value of properties, aspects, and associations
  • Transform and manipulate content
  • Create groups, people, and modify permissions
  • Create new files, folders, or nodes
  • Copy, move, and delete nodes
  • Create, modify, and remove child and target associations between nodes
  • Include or import other scripts


FreeMarker API

FreeMarker templates can be used to generate the view component of the Model-View-Controller (MVC) pattern.

The Repository FreeMarker Template API lets you render output using the FreeMarker template engine. This is the full list of public APIs that compose the Repository FreeMarker Template API.

Important:Objects that are available to scripts running in the Repository context are explained here. They are not available to scripts running in the Share context.

Extension Packaging – Modules

Extensions can be packaged as loadable modules. These modules are registered with Alfresco and can be viewed from the Admin Console or the Share Admin Console.

There are two main types of extension that can be packaged as modules, Platform and Share extensions. Further, for modules there are two supported module packaging formats available Alfresco Module Package (AMP) and Simple JAR Module.

An extension must include a file to be identified as a module. It may also include a module-context.xml file if the extension uses Spring beans. The file is discussed in more detail here, and the module-context.xmlfile is discussed in more detail here.

Customization packaging matrix:

Extension type Package format
Platform extension that includes third-party library AMP
Platform extension that does not include third-party library Simple Module (JAR)
Share extension that includes third-party library AMP
Share extension that does not includes third-party library Simple Module (JAR)
Client Application Web application (WAR)

Alfresco Extension point

The following diagram illustrates the platform architecture and extension points. Note that this does not represent a complete list of extension points:

The Alfresco Platform consists of the repository and all services, developer extension points, and APIs. The Alfresco repository provides storage for documents and other content. The content metadata is stored in a relational database, while the content itself is stored directly on the file system. The relationships between content items, and their various properties (metadata) are defined in one or more content models.

Content models can be thought of as describing types of content and the relationships between pieces of content. For example, there is a relationship between a content that has a container functionality (that is, folder), and the piece of content contained within it (that is, sub-folders and files). There might be constraints defined in the content model, such as a content type cannot contain other content unless it is a container type.

As well as the basic content storage functionality, the platform provides a wide range of content-related services. These include core services such as the Node Service, and the Version Service. There are also higher-level services such as Thumbnail Service (for creating thumbnail images and renditions of documents), the Site Service used for creating and managing sites in the Share application, and the Tagging Service, which provides the ability to tag content with keywords. The following sections of this documentation provide a brief tour of the available services.

Content Model

Defining a custom content model for the Alfresco Repository is a fundamental task in almost every content management project. It will take your content management solution from being a glorified shared drive to being a system with classified content that can be searched, structured, and processed in many different ways.

One of the main differences between a network drive and a Content Management System (CMS) is that the latter provides extra classification features. If we look at a CMS behind the scenes, we can see that everything in the repository is typically a node or an object, depending on what we want to call it. Properties are then set on the nodes so they become folders, files, categories, rules, forums, web pages, e-mails, people, groups, and so on.

Basically, the nodes are classified so it is easier to search for them, so we know how to display them in the user interface, what they can be used for, and so on. The properties that can be used to classify nodes, or if you prefer content, cannot be just any properties, as then the system would not know what each one of these properties represents. Because of this a content management system usually comes preconfigured with properties that can be used to classify content in the repository. These properties are usually organized into two types of groups called Types and Aspects. The main difference between types and aspects is that a node can only have one type applied but it can have multiple aspects applied.

Nodes do not live by themselves in the repository. They are related to one another in different ways. How the nodes are related to each other is defined with so-called Associations. A typical association that comes out-of-the-box with Alfresco is the one between a folder node and its child nodes, this type of association is a child-association. So when you start using Alfresco you can immediately organize folders and files into a hierarchy, like with a file system.

The Types, Aspects, Properties, and Associations are in turn organized into models that we call Content Models. Alfresco comes with a number of Content Models out of the box for different things like general folder and file content, workflow-related content, records content, web content, and so on.

It is also useful to be able to create content models related to specific domains such as Finance or Marketing. Alfresco cannot possibly know about all kinds of content that will be stored in the repository, so they just supply some generic standard content models that we can build on to be able to classify the particular domain that we happen to work in for the current project.

So we can define new types and aspects forming new custom content models. But how do we know how to specify a type and a property with, for example, a data type integer? Alfresco also comes with a Meta Model. The Meta model defines what syntax we can use when defining our content models. It will, for example, define the syntax for how a type or an integer property should be defined. The following diagram gives a simplified overview of the relationship between Alfresco meta model, Alfresco content models, and custom content models:

In the image, we can see two nodes in the repository: one folder node and one ACME Contract document node. The Contract type extends the ACME Generic Document type, or base type if you like, which in turn extends the Alfresco generic Content type. The Contract document node also got versioning turned on by having the Versionable aspect applied.

Both the custom content model and the Alfresco content model is defined by the Alfresco Data Dictionary Schema, which is the same as the Meta Model.

The whole thing with content models, types, aspects, and properties are not that far away from object-oriented concepts in programming. If we are familiar with object-oriented modelling, then we should not have any problem with content modelling.

The Alfresco meta model contains the constructs or syntax that can be used to define content models, which are defined in XML.


  • Download Alfresco Community ECM Now | Alfresco

    Download Alfresco Community Edition to get started with open standards enterprise content management (ECM) now!


  • GitHub – Alfresco/alfresco-sdk: The Alfresco SDK based on Apache Maven, includes support for rapid and standard development, testing, packaging, versioning and release of your Alfresco integration and extension projects

    alfresco-sdk – The Alfresco SDK based on Apache Maven, includes support for rapid and standard development, testing, packaging, versioning and release of your Alfresco integration and extension projects


  • Alfresco Documentation | Alfresco Documentation


  • CMIS Server | Content Management Interoperability Services | Alfresco

    The server supports Content Management Interoperability Services 1.0 and the browser binding is based on the CMIS 1.1 draft. Please note, this serv…


  • Alfresco CMIS API | Alfresco Documentation



  • Setting up and using the Alfresco SDK 2.0 beta with Eclipse – YouTube

    This video will show how to setup and use the new features of the Alfresco SDK 2.0 beta. Features included: – Artifacts on Maven Central – Create new project…


  • Alfresco Blog