How to Configure the EDM Module to Ignore Uninitialized Drawing Views in the PDF Preview Rendition for Alfresco Share

One of the features of the Formtek Engineering Data Management Module (a.k.a EDM Module) is the ability to preview AutoCAD drawings in Alfresco Share. In previous EDM Module releases, you could only preview the drawing space (model or paper) that was active when the drawing was last saved. Starting with release 3.0, a multi-page PDF rendition is created that includes the model space and all available layout views. So, when you display a drawing in the Alfresco Share Document Details window, each available drawing view can be previewed as a separate page in the preview pane. For example, the drawing below is displayed as a 3-page PDF preview:

When we switch the Side Bar view to display bookmarks instead of thumbnails, you see the model space as the first page followed by two paper space layout views, Layout1 and Layout2, as the next two pages in the PDF preview:

When this drawing was first created as a new drawing in AutoCAD, the empty model space view and the two empty paper space views were created by default. However, the designer who created the drawing content only ever worked in the model space view. The layout views were never accessed, and thus, remained uninitialized in the saved drawing as you can see by the two empty thumbnails for Layout1 and Layout2 within AutoCAD:

By default, when the EDM Module creates the PDF rendition of a drawing, it automatically attempts to initialize any uninitialized layouts in the drawing and include them in the resulting PDF rendition. In the vast majority of cases, these auto-initialized layout views looks the same as if you had accessed (or initialized) the layout in AutoCAD.

I’ve you prefer not to include uninitialized layout views in the PDF rendition created by the EDM Module, your Alfresco administrator can modify the script that converts CAD drawings to PDF so that uninitialized layout views are ignored as follows:

1.      Open ALF_HOME/formtek/edm_module/bin/edm-cadtopdf.sh (on Linux) or ALF_HOME\formtek\edm_module\bin\edm-cadtopdf.bat (on Windows) for editing:

a.       Add the -nouninit parameter to the end of the following line:

               For Linux:

"${dwg_exename}" -i="${sourcename}" -o="${targetname}" -f=pdf -basic -axpath="${edmBinDir}/ax2011" -lpath="${edmBinDir}"

           For Windows: 

%dwg_exename% -i=%sourcename% -o=%targetname% -f=pdf -basic
-axpath="%edmBinDir%ax2011.exe"

For example:

"${dwg_exename}" -i="${sourcename}" -o="${targetname}" -f=pdf -basic -axpath="${edmBinDir}/ax2011" -lpath="${edmBinDir}" –nouninit

b.      Save and close the file.

Uninitialized layout views will no longer be included in any newly generated PDF renditions. For example, when this same drawing is uploaded a second time and previewed, you can see that only the model space view is available in the PDF preview:

 
Please note that any PDF rendition previously generated is stored in Alfresco along with its associated drawing and is not affected by this change unless a new version of the drawing is uploaded. Also note that the original drawing is unaffected by this change.

Exporting Documents from Ephesoft to Alfresco via CMIS: Identifying Alfresco Aspects and Properties

CMIS Export from Ephesoft to Alfresco - Identifying Alfresco Properties and Aspects

Configuring Ephesoft to export documents to Alfresco via CMIS is a fairly straightforward process:

1. Enable and configure the CMIS export plug-in for your batch class inside Ephesoft
2. Define your aspect mappings here:  <Ephesoft-Installation-Folder>\SharedFolders\<Batch Class #>\cmis-plugin-mapping\aspects-mapping.properties
3. Define your Alfresco document type and property mappings here:  <Ephesoft-Installation-Folder>\SharedFolders\<Batch Class #>\cmis-plugin-mapping\DLF-Attribute-mapping.properties
4. Create a drop location in Alfresco to receive the files, and configure rules or scripts to move the files to their final destination

(Both of the folders above represent the default locations of those properties files, but your environment may be configured differently.)

Ephesoft has this overall process well-documented on their public wiki (http://wiki.ephesoft.com/cmis-export-plugin).  However, when defining your mappings, it can be difficult to determine whether you’re dealing with aspects or properties on the Alfresco side.  You’ll need to look through the content model to know for sure, and this article will tell you how.

                               

If the documents are going to be identified as a custom content type in Alfresco, you’ll need access to the custom content model definition file.  Once you find the custom content model definition file, you can use the steps below to understand how to read it.

If you’re going to simply use Alfresco’s standard content model, the content model configuration file can be found inside the following jar file:  

<Alfresco-Installation-Folder>\tomcat\webapps\alfresco\WEB-INF\lib\alfresco-repository-5.1.jar

(the actual name may differ depending on your Alfresco version)

Copy that jar file to a temporary location, and change its extension from .jar to .zip.  Extract the zip file to a temporary folder, or use a zip reader to navigate through the structure to find the alfresco\model\contentModel.xml file.  Open the contentModel.xml file in an editor and look for the Alfresco aspect/property that you want to populate.  For example, if you want to populate the cm:description field inside Alfresco, search for “cm:description” in the xml file.  It will look something like this:

Work your way up the xml structure from the cm:description line, and you can see that cm:description is a property under the cm:titled aspect.  This means that the mapping to the Description field in Alfresco must be defined in the aspect-mapping.properties file in Ephesoft.  If you’re using CMIS 1.1, you can define that mapping like this:

PartsManuals= P:cm:titled|ManualDescription::cm:description

(Refer to the Ephesoft wiki page for details on how to set up the same mapping for CMIS 1.0.)

In the example above, PartsManuals is the document type in Ephesoft, and ManualDescription is the index field.  With this mapping, Ephesoft will create the dm:titled aspect on the document when it’s exported to Alfresco, then it’ll assign the value from the ManualDescription index field in Ephesoft into cm:description in Alfresco.

You can also combine multiple mappings onto a single line by separating them with a semicolon, like this:

PartsManuals= P:cm:titled|ManualDescription::cm:description;P:cm:auditable|Author::cm:creator

This example (also for CMIS 1.1) executes the same mapping as above, and also adds the cm:auditable aspect, populating the cm:creator value with the Author index field from Ephesoft.

Most well-designed custom content models will use aspects instead of properties, so you’ll rarely have to add anything to the DLF-Attribute-mapping.properties file other than the Alfresco document type.  However, older versions of Alfresco didn’t provide good support for mapping values into aspects, so it may be necessary to use properties instead of aspects in those cases.

For another example, say that you have a custom content model, and you want to populate the hvac:modelNum field in Alfresco with the model number extracted from Ephesoft.  If you search for hvac:modelNum in the content model XML file for your custom content model, it could look something like this:

Work your way back up the xml structure, and you’ll see that hvac:modelNum is a property of the hvac:hvacDocuments type.  This means that the mapping to the hvac:modelNum value in Alfresco must be defined in the DLF-Attribute-mapping.properties file in Ephesoft.  You can define that mapping like this: 

PartsManuals=D:hvac:hvacDocuments
PartsManuals.ModelNumber=hvac:modelNum

 (The syntax for the DLF-Attribute-mapping.properties file is the same for both CMIS 1.0 and 1.1.)

In the example above, the first line states that documents of the PartsManuals type in Ephesoft should be imported into Alfresco as the custom document type hvacDocuments.  The second line says that the ModelNumber index field in Ephesoft should be inserted into the modelNum property of the hvacDocuments document type.

Even if you aren’t importing values into Alfresco properties, the first line is necessary to tell Alfresco what custom document type these imported documents should enter Alfresco as.  If you don’t specify a custom document type, documents will be imported into Alfresco using the standard Alfresco document type.

With the combined aspects and properties mappings described above, you can successfully map a variety of Ephesoft index fields into Alfresco fields via CMIS.