Monday, August 22, 2016

Alfresco IMAPS: Secure Email Client Integration with Alfresco

 Alfresco IMAP integration is a lightweight integration of Alfresco with email clients, like Outlook, Thunderbird and Mail.  IMAP integration enables an Alfresco folder to be mounted as an IMAP folder in the email client.  The mounted folder allows the user to browse through the Alfresco repository and to easily file email messages and attachments by just dragging items into the mounted folder.

As an aside, if your email client is Outlook and you are running on Windows, you might consider using instead the Alfresco Outlook Integration which provides a deeper email client integration than just IMAP.

How do you get IMAP working?  I described that some time ago in this blog and the information there is still relevant.  Since that post was written, the latest Alfresco documentation has also added a good explanation for how to set up IMAP too.  IMAP configuration can be done by setting parameters either in the file or, in the enterprise version, by changing settings in the Admin console.
The tip described here though is how to configure secure IMAP or IMAPS with Alfresco.  Although this is covered in the standard Alfresco documentation here, and it's also discussed on an older wiki page here, it may be confusing.  From the description on those pages, it isn't totally clear where to set all the parameters needed for IMAPS to work.

Once you have standard IMAP working, add the following two parameters to the file or enter them on the Admin Console:


Then there are still two other parameters that need to be configured.  Those parameters don't go into the file.  Those parameters are:

The parameters are passed to the JVM so that it can find and use the SSL certificates needed for IMAPS.

If you don't already have a keystore file, you can create a test certificate as shown next.  The steps given here are for a Linux system, but similar commands can be run for a Windows server.  Note in this example that the keystore that I create uses the password MPaI43a.  You'll use the password you configure when making the certificate later as the value for one of the JVM parameters.

cd /opt/alfresco-one/java/bin
rm imapkeystore.jks

./keytool -genkeypair -alias imapalfresco -keystore ./imapkeystore.jks -storepass MPaI43a -keypass MPaI43a -keyalg RSA -validity 999 -keysize 2048 -storetype JKS
./keytool -list -v -keystore ./imapkeystore.jks

Once the keystore file is created, the javax parameters shown above need to be passed to the JVM.  This can be done by adding them to the JAVA_OPS setting.

For example, if you are using Tomcat on Linux, add the following to the /opt/alfresco-one/ file at the beginning right after "#!/bin/sh", as shown here:



Depending on the application server that you use and how you start it, just where you need to add these JAVA_OPS settings will differ.  If you are using Tomcat as a service in Windows, for example, you can get to the JVM settings used by Tomcat by running the program tomcat7w.exe found in the <ALFRESCO_HOME>\tomcat\bin directory.  In that setup app, you can add them to the "Java Options" area under the Java tab.  (Remember to prefix the options with a "-D")

tomcat7w.exe //ES//AlfrescoTomcat

After making that change, restart the server and IMAPS should then be available.

Wednesday, August 17, 2016

Ephesoft Queries - Compare Validation Patterns, Compare OCR Confidence Values

Sometimes it's easier to compare settings across index fields by looking at the values in the database instead of navigating down to each field in the Ephesoft UI.  However, changes to the values still need to be made in the Ephesoft UI.
Compare Validation Patterns
The following query can be used to view validation rules across index fields grouped by index field. This is helpful for making sure that the same validation rules are applied to the same fields across different document types. Query the batch_class table to find the batch_class_id value for your batch class (in red).
field_type a,
regex_validation b,
document_type c
where = b.field_type_id
and a.document_type_id =
and c.batch_class_id = "12"
order by 1;

Compare OCR Confidence Threshold Values
The following query can be used to view field-level OCR Confidence Threshold values on a form. Higher values will result in more batches stopping in Validation, but overall accuracy should be improved as a result. For Ephesoft installations where multiple forms have similar fields, this query can be used to ensure that the same index field has consistent OCR confidence values across different forms. Query the batch_class table to find the batch_class_id value for your batch class (in red).
field_type a,
document_type c
a.document_type_id =
and c.batch_class_id = "12"
order by 1;

Additionally, care should be taken to ensure that hidden fields (is_hidden = 1) have OCR confidence threshold values of 0 (zero). I've seen situations where a hidden field with a high OCR confidence value can cause a batch to stop in Validation even though all of the non-hidden fields have good confidence values, causing the user to wonder why the batch stopped in Validation.

Tuesday, August 9, 2016

Configuration for Handling Failing Thumbnails in Alfresco

Some content cannot be thumbnailed or can take a significant amount of time to generate a thumbnail. Failed thumbnail generation can add up to a significant cpu cost on the repository server. This is the reason Alfresco limits the frequency with which the repository tries to recreate thumbnails. It is based on previous failed thumbnail attempts for that definition on that source node, as well as some configuration data.

The details of how these thumbnail creations are limited is described in JavaDocs for NodeEligibleForRethumbnailingEvaluator class.

When the first attempt to generate a thumbnail for a node fails, Alfresco records that attempt by assigning a cm:failedThumbnailSource aspect to the source node and it also creates a cm:failedThumbnail child to store the failure data.

You can examine the source node in Alfresco Node Browser to see the applied cm:failedThumbnailSource aspect and the cm:failedThumbnail child.

The cm:failedThumbnail child stores failure data like failed thumbnail attempts(cm:failureCount) and the datetime of the last failed thumbnail generation attempt(cm:failedThumbnailTime).

The configuration for handling failing thumbnails is defined in the file; here are the default configuration values from file:

# Configuration for handling of failing thumbnails.
# See NodeEligibleForRethumbnailingEvaluator's javadoc for details.
# Retry periods limit the frequency with which the repository will attempt to create Share thumbnails
# for content nodes which have previously failed in their thumbnail attempts.
# These periods are in seconds.
# 604800s = 60s * 60m * 24h * 7d = 1 week

These property values can be overridden in the file to change the behavior for how the repository retries to create the thumbnails.
If a thumbnail is not successfully produced for a node after the number of attempts specified in “system.thumbnail.retryCount” then it is considered to be a 'difficult' piece of content with respect to thumbnailing. The attempts to thumbnail difficult pieces of content can be disabled by setting “system.thumbnail.quietPeriodRetriesEnabled” to false.

Increasing the “system.thumbnail.retryPeriod” value would reduce the frequency of the initial tries to produce a thumbnail. If the initial try to produce a thumbnail failed because the server was overloaded at that time and the thumbnail attempt timed out then increasing the "retryPeriod" should help.

If in your installation software patches are installed on a nightly basis then the content may become thumbnailable after the patch is installed so reducing “system.thumbnail.quietPeriod” value from 1 week should help in successfully generating the thumbnail sooner.

These property values can be changed to increase the frequency of the repository retries to create the thumbnail but make sure that the new values don't add significant cpu cost and overload the repository server.