One of the trends we are seeing with our Alfresco clients is a desire to move away from custom interface coding to more configuration or no code approaches. This post will highlight the differences between coding approaches for Alfresco Share and the Alfresco Development Framework (ADF) and configuration approaches with TSG’s OpenContent Management Suite.
Alfresco Low Code Approach
While Alfresco provides a very robust API for custom development, many clients aren’t looking to build an entire interface from scratch for common document functions like adding, searching and viewing. Clients will leverage either Alfresco Share or the ADF’s Content Application for the “out of the box interface” and look to add specific customizations for their implementation. To illustrate the differences, let’s assume that the client would like to modify the standard search interface to add a custom metadata fields for certain object type searches.
In Alfresco Share, customizing search is not straightforward. This post contains more details, but in order to make this change, a developer would need to:
- Edit multiple configuration XML files on the server to set up the custom search page. Separate XML files are needed to set up the search form for the custom type.
- Test the search in a development and QA environments
- For each environment, Stop Alfresco, deploy the changes via an AMP, and restart Alfresco
The complexity of a similar update in the ADF is dependent upon the particular ADF application. If the target application was built from the ground up to support custom type searching and metadata criteria, this update could be relatively simple. However, it would involve updating code, likely TypeScript and possibly HTML and CSS. As with the Share example above, application downtime is needed to deploy changes.
We suspect that most ADF applications will start by copying the Alfresco Content Application that is provided on GitHub. To date, this application provides a different approach to searching where the search is a “Google” style search that scans the entire repository. After results are returned, filters can be used to narrow down results. To make our desired change for a custom metadata filter, we either need to follow this approach, or entirely re-develop a search page to provide a custom search screen.
Issues with a low code approach to Alfresco deployments include:
- Having to build, test, and deploy necessitating system downtime
- Having to find resources trained in the development
- Having some concern (Share more than ADF) that changes will be required with new releases of Alfresco
Alfresco No Code Approach
The OpenContent Management Suite takes a different approach to building the search application. Instead of a development framework, the OpenContent Search module is configured in the administration components using a GUI interface.
Here are the configurations that an administrator can make in order to build a search interface:
- Object Type Config – Tells OCMS what repository object types are to be exposed in the application. Per type, the administrator can change any attribute labels as well as filters.
- Search Form – Configure the form for a particular object type search. The administrator can choose particular metadata fields and controls, whether or not full text search is available, and whether or not saved searches should be exposed.
- Search Config – Configure the search sort order and results processing. This is where the administrator can choose how the results table should look, any actions that can be performed on the documents, as well as what happens when the user clicks on a search result.
- Trac Config – The concept of a ‘Trac’ allows OCMS to segment the application based on business function. For example, an Invoice trac could be used for Accounts Payable, and a separate Legal trac could be configured for contracts. Security can be applied to ensure that these two tracs are separate if desired. Once the Search config is configured in the previous step, we assign it to a trac.
In our example use case, the update steps are trivial:
- Login to the OCMS application as an administrator
- Edit and save the necessary search configuration changes
Changes are immediately reflected in the user interface with no application downtime. Since the above concepts can be difficult to envision, here’s a demo video that shows how to configure a search in OCMS from scratch:
In utilizing the OpenContent Search application to build our search interface, no development time is required. Once OCMS is installed, a configuration-only approach is taken to build the interface. If users want updates to the search (additional types, metadata, etc) or new departments want to come online with new document types, no additional development is needed. The application can be configured and updated with no downtime since no deployments are necessary to update and apply configurations.
There are major differences between a low-code and no-code approach to Alfresco deployment. Clients should look to understand their needs and evaluate both options to consider which approach makes the most sense for their application deployment efforts.
[…] Code Configuration – OpenContent Managememnt Suite features configuration with a no code approach rather than low code approaches to allow for easy support and adoption of new documents and object […]
[…] Code Configuration – OpenContent Management Suite features configuration with a no code approach rather than low code approaches to allow for easy support and adoption of new documents and […]
[…] Posts – Individual posts for Building a Search Interface, No Code versus Low Code environment as well as ADF and OpenContent – REST Web Services […]