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 alfresco-global.properties file or, in the enterprise version, by changing settings in the Admin console.

• IMAP configuration via alfresco-global.properties
• IMAP configuration via 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 alfresco-global.properties file or enter them on the Admin Console:

imap.server.imaps.enabled=true
imap.server.imaps.port=993

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

javax.net.ssl.keyStore=mySrvKeystore
javax.net.ssl.keyStorePassword=123456

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/alfresco.sh file at the beginning right after "#!/bin/sh", as shown here:

#!/bin/sh

export JAVA_OPTS="${JAVA_OPTS} -Djavax.net.ssl.keyStore=/opt/alfresco-one/java/bin/imapkeystore.jks -Djavax.net.ssl.keyStorePassword=MPaI43a"

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.

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).

select 
a.field_type_name,
b.pattern,
c.document_type_description
from 
field_type a,
regex_validation b,
document_type c
where
a.id = b.field_type_id
and a.document_type_id = c.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).

select 
a.field_type_name,
a.is_hidden,
a.ocr_confidence_threshold,
c.document_type_description
from 
field_type a,
document_type c
where
a.document_type_id = c.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.

Ephesoft Index Value Auto-complete

Adding a semicolon separated list of values to an individual index can improve over-all accuracy while decreasing the processing time required to complete an Ephesoft batch. The auto-completion of the index field happens during the Validation process. A simple example is a field where the possible responses are ‘Positive’, ‘Negative’ or ‘No Response’. The person processing the form can simply enter a character or two that matches the characters associated with the entries in the list of values. Once the corresponding value appears as the first entry in the list the user will strike the Down Arrow Key to populate the index with the selected value. Pressing the tab key will take the person to the next field so they can continue to process the form.

Setup for an Auto-complete Field
First collect the values that are valid for a particular field. Now open the Doc Type in which the index value resides. Under the header ‘Field Option Values List’ enter the list of values. A semicolon is used to separate the list of values. See the ‘Field Option Values List’ column entry below.

Screenshot #1:

Now look for the header label ‘Field Type’. Select the value ‘Combo’. See the entry in the 'Field Type' column below. Apply your changes and you can test the results.

Screenshot #2. 

Interacting with an Auto-complete Field

Open a batch file in the Validation module that matches the Doc Type where you added your list of values. Tab down to the field where you entered your list of values. Once there enter a character or two that match the first few characters for the value you want applied to this field.

NOTE: It is NOT case sensitive.

Once you see your value appear at the top of the list simple hit your Down Arrow Key and this value will be used to populate this field. Pressing the tab key will take you to the next field. This is simple change that can greatly decrease the processing time associated with a Doc Type within the Ephesoft application.

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 repository.properties file; here are the default configuration values from repository.properties 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

system.thumbnail.retryPeriod=60

system.thumbnail.retryCount=2

system.thumbnail.quietPeriod=604800

system.thumbnail.quietPeriodRetriesEnabled=true

These property values can be overridden in the alfresco-global.properties 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.