enaio® releases
More Mobile. More Flexible. More Performance.
The new Version 9 of enaio® will be available from 17 September 2018. While developing this update, we focused on adapting tried-and-tested architectures and shifting the frameworks and third-party systems used to new technologies, algorithms, and versions. Learn more about the new features, components, and updates related to the proven ECM solution from OPTIMAL SYSTEMS.
The web client is available as a native app for iOS and Android
Simplification of the index forms for enaio® clients
Electron framework for bridging the browser sandbox
Autofocus, MIME type, suspending columns, and multiple sorting criteria
Modern e-mail processing as a microservices component
Rights groups add-on 2.0 and folder fields in document clauses
Windows API, multilingualism, full-text engine, and microservices
The web client is now available as a native tablet app for iOS and Android starting with the release of enaio® Version 9.0. The Cordova framework can be used to make the enaio® webclient available as an app (without sacrificing its functional scope). The apps can be downloaded from the App Store and the Google Play Store. MDM is also supported.
All apps (Web-only, Electron Windows Desktop, and Android/iOS) have largely the same functionalities, since the code base of the web client and the iOS/Android apps is identical. Every service pack or hotfix will update all platforms simultaneously.
The web client content in this case can be downloaded to the tablet’s file system directly, either as a PDF or in its original format. Links in e-mails or other documents that refer to a document in enaio® can also be opened in the app.
Provided the device is connected to the Internet, you can also use the features that enable you to check out documents, edit them using applications on the device-specific operating system, and then check in the documents again. Furthermore, the apps support workflow editing, just like the Web-only client.
The interface metaphors are adjusted to the respective touch screens, guaranteeing a smooth experience for users.
In short: The tablet apps from enaio® make working with and editing documents convenient – at any time and from any place.
Previous versions of the enaio® webclient and enaio® client used different positioning algorithms to place form fields and labels for the index forms. This process has now been harmonized in the enaio® webclient.
Starting with enaio® Version 9.0, the enaio® webclient now displays index data forms as if they had been designed in a graphic editor by a system supervisor.
Since the tablet apps and the desktop web client are both technologically based on the web client, these clients also present index data forms in the same way. This makes it easier for the user to switch between clients if they are using a different device.
Index data forms need to correspond to the design guidelines of the web client forms in order to be presented in the appropriate design in the enaio® webclient. Essentially, the minimum distances between the controls need to be ensured here. The controls must also not be superimposed.
The design guidelines will be made available on our documentation page in the future. If the forms in the project cannot be adjusted to the design guidelines quickly enough, the old positioning algorithm can be temporarily activated in the enaio® webclient.
The browser sandbox must be bridged to integrate the web client into the operating system and Office. In the case of enaio®, we use the Electron framework to bridge the sandbox.
The framework makes the web client available locally on the computer as an EXE. The EXE contains a web control and the web client script code, as well as options for integration with the computer’s operating system. It can be downloaded either from the browser web client or administratively as an MSI. Installation without administrative rights is possible, and the automatic update process for feature or error patches ensures that you are always up-to-date. Since the same code base is used in both the Electron web client and the browser web client, they have largely the same functionalities.
enaio® can be integrated into the Office applications Word, Excel, PowerPoint, and Outlook NG, which makes it possible to create documents in Office, file them in enaio®, check in and check out Office documents, open the location of enaio® documents in Office and Outlook, and file e-mails in Outlook from an open location.
One advantage of using Electron that it makes it possible to work offline with enaio®. We are currently working on this and will deliver this offline functionality in a service pack soon.
Autofocus
You can decide which list should be the focus when you open a location (register tree on the left, hit list on the right). The previous default setting focused on the hit list. This focus allows the appropriate view to be operated with cursor keys directly.
MIME type
The MIME type of objects can now be displayed in the hit lists with the corresponding icon, allowing you to immediately identify, for example, whether the file is a JPEG, a TIF, a PowerPoint presentation, or an Excel table, or if it’s in another file format.
Suspending columns
Similarly to the corresponding function in Excel, an index column can be pinned so that every column to the left of the pinned column remains visible while the columns to the right of the pinned column continue to be moveable. This feature is useful when dealing with expansive hit lists.
Multiple sorting criteria
Starting with Version 9.0, additional columns can be sorted using a keyboard command if a column has been sorted by a criterion.
The version 9.0 contains our new enaio® mail storage (EMS) – a microservice that runs in the Service Manager and is critical in terms of migrating enaio® to a modern microservices architecture.
The aims and benefits that we associate with EMS include the consolidation of e-mail processing into one component as well as the ongoing processing of e-mails across all components. All e-mail is processed in the same way, regardless of where it comes from.
The migration to EMS means that the client no longer files e-mails itself; instead, EMS assumes this task. The client only opens e-mails externally.
The digest field is essential for the new service. If you create a new mail object type in the editor, this field is already available. However, mail object types that already exist must be adjusted in the project. The database is then automatically adjusted by EMS. Empty digest fields are updated using existing mail objects in a nighttime batch. You can configure the time at which this update process runs.
Migrating mail storage to EMS represents a step towards achieving the aim of being able to communicate with cloud applications such as Office 365 in the future.
Previously, it was possible to position controls for user groups on index data form text fields and to set a corresponding rights clause ‘field in #RIGHTGROUP#.’ Very large SQL statements were generated by the enaio® system due to the heavy use of this feature, which had a significantly detrimental impact on performance. This effect was also intensified when users were assigned to large numbers of groups and the group names were made up of a lot of characters due to a legibility requirement.
This mechanism has been completely changed in enaio® Version 9.0. A new field type has been introduced that is only intended for use in rights groups clauses. Data management and statement generation have also been completely changed for this field type, resulting in extreme performance increases for search requests and authorization checks in these systems. Tests have proven that individual statements now require just 58 milliseconds instead of four seconds.
A two-stage update mechanism for each automatic action is available for the update. This two-stage setup means there is less system downtime when migrating large databases, which has a positive effect on the update process.
The first stage, which can be performed in live operation, involves migrating the data from the previous fields (provided that the data is designated for conversion by the admin). The second stage, which absolutely requires system downtime, involves systematically migrating the database that has accumulated since the first stage was carried out. Users cannot work or run imports into the system during this stage. The fields are then converted in the object definition. The system administrator is solely responsible for deciding if and when the fields of individual object types are to be converted to the new field types. Both the old and the new rights groups fields can be used in the system at the same time.
The new security system clause mode introduced with enaio® Version 8.50 is required for the new rights groups field.
It is now possible to also use the fields of the folder containing the objects in rights clauses for registers or documents. The new clause mode also allows you to refer clauses to a folder using the newly introduced command word ‘FOLDER.’ A ‘FOLDER(field1 = ‘xyz’)’ clause in a document right refers to the index data field ‘field1’ of the respective folder that contains the document.
If the document is present in several locations, every location is always factored in to the evaluation of rights. As soon as a location is permitted access to the document, this permission also applies for the document in other locations.
A combination of the two new developments enables targeted, highly efficient, and user-controlled management of rights for both individual objects and large object trees in the enaio® system database.
Once again, a lot of work has gone into the enaio® product platform to keep it technically superb into the future; this also holds true for enaio® Version 9.0, especially in terms of technical modernizations ‘under the hood.’
All C++ based client and server components (rich client/admins/editors) have been migrated to the most recent version of the Microsoft Windows API, and we are developing these using the latest development tools Microsoft has to offer. As part of this, we have updated numerous third-party tools and replaced them with advanced libraries; as a result, we can provide the most comprehensive range of features possible by appropriately using up-to-date software libraries.
The previous localization mechanisms used to provide you with multilingual applications has also been adapted to the latest standards in technology. The full-text OSFTS engine has been updated to the newest Elasticsearch Version 6.2. This promises a high level of performance and stability.
To ensure the future viability of enaio®, we must also continue down the path of implementing new components as microservices that can be hosted and administrated in the simplest and most flexible way in the enaio® Service Manager. In this version, we have made enaio® mail storage available as a microservice and undertaken the first step to reimplementing our rest service (OSRest) in the form of several microservices.
Those microservices will gradually replace OSRest in the coming versions as the base communication interfaces for the enaio® webclient.
Alongside these developments, we will of course make sure to integrate the most up-to-date versions of JAVA, Tomcat, and so on.
We are also pleased to announce that the PDF-based document preview, which we have also adapted to the newest version of PDF.JS, is out of BETA status, so that we can now offer you the final version.