Users can access the application through a browser. OpenKM implements a Web 2.0 user interface framework based on GWT (Google Web Toolkit) that supports Firefox, Internet Explorer, Safari, Chromium and Google Chrome and the latest versions of Opera.
Also available, a user interface adapted for mobile devices based on JQuery Mobile, Add-ins for Microsoft Office, WebDAV and CIFS protocol for connecting OpenKM repository as a network drive and FTP protocol.
OpenKM implements a CMIS (Content Management Interoperability Services) protocol, an OASIS open standard that defines an intermediate layer, which allows the interconnection and control of various document management systems and repositories using Web protocols.
Additionally, OpenKM exposes a complete API via Webservices (SOAP) and REST that can be used as a point of integration with third-party applications.
SDK (Software Development Kit) for Java, NET, and PHP are available. These encapsulate all OpenKM API.
OpenKM is a Java EE application using Spring Framework. The most important module is the security layer - Spring Security - that centralizes management of access allowed to users based on their credentials. The security control rests with an Access Manager module that implements the logic of safety assessment in the application. The Java EE OpenKM architecture allows you to execute custom security logic.
The OpenKM authentication process can be carried out by a CAS service (Authentication Centralized Service), LDAP, or via a database where users are registered.
The OpenKM Core centralizes and implements the management and processing logic for different types of objects that are stored in the repository. These objects are nodes of type document, folder, emails, and records as well as the combination of metadata structures.
OpenKM incorporates into the default JBPM workflow engine. The Java EE architecture implemented in OpenKM allows to work - connect - with other Workflows engines transparently.
OpenKM uses Hibernate for OMR (Object Relation Mapping) data mapping and supports different relational databases (DBMS) such as PostgreSQL, MySQL, Oracle, MS SQL Server, DB2, and others. The entire metadata layer is stored in a DBMS database, while the binary objects (documents), based on the selected type are DBMS, these stored either on the file system, in a database or a specific implementation of DataStore. Thanks to Java EE architecture implemented in OpenKM, you can create specific DataStore
OpenKM uses Lucene as a search engine. All objects that OpenKM works, whether or not binary, are indexed by the search engine. In the case of binary objects such as Microsoft Office documents, PDFs or images, are added to a queue of indexing.
Before being processed by Lucene, documents are analyzed by text extractors (Text Extractors). For example, in the case of images, they are processed by an OCR engine for identifying text strings, which will be used during Lucene's indexing process. The search engine results are filtered by the Security Manager. Users can only access information that they have privileges.
Barcode Engine allows to identify and read barcodes on the documents. The Java EE architecture implemented in OpenKM enables you to extend the capacity of reading and processing of barcode formats.
OpenKM is integrated with several open source OCR engines (such as Tesseract or Cuneiform) and commercial (as Abby, Kofax or Cognitive among others).
Scripting - Shell Bean - combined with events system, smart tasks, task scheduler (Crontab) and reports (Jasper Reports) allow plan, implement and control the process of automatic metadata capture and complex automate processes in a completely transparent way for the user.
OpenKM can be integrated with most antiviruses. All binary objects are processed by the antivirus engine, ensuring the integrity of the repository and the safety of users in daily use documentation.
The OpenKM statistics and reports system put into the hands of administrators a powerful source of information through which to control the state of the applicación. Thus, they can analyze values: regarding the use of Hibernate layer, the second-level cache metrics and methods concerning API and core.
This information helps in decisions taking to establish the optimum values for the objects in the second-level cache, the parameterization of the resources used by the DBMS and how they are used and anticipate problems that may arise in the future, like those that involve the hardware, among others.