The below update covers release notes from January to April 2018 for the SDL Integration for AEM version 6.3. It is for information to those customers wanting to know what changes have been made this year as we develop the integration, and whether they shoudl upgrade to the latest versions.

Prerequisites

Starting with version 6.3.0-1.1.8 the WorldServer API for the WorldServer environment should be updated with CU5 or above.

Version 6.3.0-1.4.6

Translation API

The Post request in the Translation API was not setting up correctly the encoding to UTF-8 when posting content to either WorldServer environment or TMS environment. Therefore if the description field or the reject translation comment contained any special characters they were not being posted correctly to either WorldServer environment or TMS environment.

This aspect has been fixed by setting up the encoding of the StringEntity to UTF-8.

Version 6.3.0-1.4.5

Caching

Introduced the concept of the refresh token when making requests to the TMS environment through Mantra API.

The refresh token will have an initial life cycle of 1199 seconds(approximately 20 minutes) and it will be stored in the cache from where it will be taken and used in all the subsequent calls that will be made to the TMS environment.

The initial life cycle of the cache is 2160 hours (90 days).

Upon every installation of the connector the cache will be cleared out and reinitialized.

The duration of the cache is configurable and can be changed if the user will access CRX  editor under /apps/sdlmantra/config/configurations/cache.If the user wants to change the duration of the cache he needs to change the value in updatedExpirationTime. Upon successfully changing this value the entire cache will be cleared out and reinitialized with the new value.

The caching and the refresh token are needed because in this way the connector won't do an authentication request  before every operation through Mantra API hence improving the performance of the application.

For the WorldServer environment the cache is in place but because its API does not support a refresh token concept we always generate a session id before every operation through WorldServer API.

The path for the cache configuration can be found under /apps/sdlws/config/configurations/cache.

Configuration Paths

Couple of settings have been moved under configurations node as follow:

Mantra

/apps/sdlmantra/config/configurations

• cache

WorldServer

/apps/sdlws/config/configurations

• cache
• basicAuthentication
• routingLanguages

Version 6.3.0-1.4.4

Extended File Extensions Support

Changed the approach in detecting the file extensions:

• the connector will try to detect the file extensions based on the mime type of the object
• if the file extension is not found the connector will try to detect the file extension from the source path of the translation object
• if the file extension is is still not found the connector will try to detect the file extension with Apache Tika
• if no extension is found for the file the connector will throw exception.

Version 6.3.0-1.4.3

Logging

Review the logging in AEM 6.3 connector and Translation API. Made sure that all the sensible information that should be protected are removed from the logging instructions.

More details can be found on the following Jira ticket:  LC-353 - Embedded connectors - Personally identifiable information CLOSED

Version 6.3.0-1.4.2

Preview Custom Attribute

Fixed the serialization of project request in Translation API version 1.0.8 in case that the custom attribute for uploading preview packages was not set up at all in the WorldServer environment.

Version 6.3.0-1.4.1

Translation API 1.0.8

Updated Translation API used by AEM 6.3 connector to version 1.0.8.

Please note: starting with this version of the connector if a user has multiple locales configuration for the same ISO code in the WorldServer environment he needs to use the routing language mechanism to configure the target language for the translation project.

This is needed because the new API is smart enough to detect all the languages for the duplicate ISO code from the WorldServer environment and it will create a project group with multiple projects inside it. This is problematic for AEM platform because in AEM platform there is only one target language per translation projects and not n target languages per translation project.

As a precaution measure if the user has the same ISO code configured in WorldServer environment for multiple languages and if he won't make use of the routing language mechanism in the connector the connector will throw an exception, breaking the creation of the translation project.

Resource Resolver Service

When reading information from the JCR the connector was using both resource resolver and session to read information from the JCR.

Changed the implementation to make use only of a Resource Resolver in order to read the information from the JCR repository.This should avoid any race conditions when instantiating the resource resolver for reading information from the JCR.

The dependencies for the Apache Sling API have been updated to the version recommend by Adobe for AEM 6.3 connector.Currently the version for the Apache Sling API is greater then 2.5.0 and is taken from uber-jar artifact provided by Adobe.

The update was needed because Apache Sling API version 2.5.0 was outdated for AEM 6.3 platform.

Reject Translation Comment

When rejecting a translation in AEM platform the user had the possibility to enter also a reject translation comment.

The comment was not being sent correctly to either WorldServer environment or TMS environment and it was not visible even though the user entered it correctly.

This aspect has been fixed and the reject translation comment should be visible in WorldServer/TMS environment.Please see an example of multiple reject translation comments in WorldServer environment:

Mantra API Reject Translation

Implemented endpoint to reject translation in AEM connector through Mantra API.

Version 6.3.0-1.3.4

Apache Sling Service User Mapper Service

Eliminated the Apache Sling Service User Mapper Service configurations that the connector was writing during its installation.

These configurations are not needed anymore because the connector will make use only of the written configurations in Apache Sling User Mapper Service Amendment.

When installing the connector the following will happen:

• A bootstrap-service user will be created that will get reading/writing rights under content.
• In Apache Sling User Mapper Service Amendment a writeAccessResourceResolver service will be defined that will make use of the bootstrap-service user.The writeAccessResourceResolver will be used to instantiate the resource resolver in connector.Therefore, according to the nature of the connector an AEM user should find one of these entries in Apache Sling User Mapper Service Amendment: com.adobe.granite.translation.connector.sdlws:writeAccessResourceResolver=bootstrap-service,com.adobe.granite.translation.connector.sdlmantra:writeAccessResourceResolver=bootstrap-service.If the connector for Mantra is installed together with the connector for WorldServer connector on the same platform then both of these entries should be found together in Apache Sling Service User Mapper Service Amendment.

Version 6.3.0-1.3.3

File Extension

Introduced Apache Tika libraries to detect the file extensions based on the translation project mime type.

In order for this version of the connector to function properly the user should make sure that the appropriate configuration for the file extensions filters is configured in either TMS or WorldServer environment.

Apache Tika will detect the extension based on the mime type of the object and it should be able to detect more than 400+ file extensions.

Version 6.3.0-1.3.1

Routing language

Routing language path did not correspond anymore after refactoring the content package.Fixed the routing language path and moved all the configurations for TMS language mapping, WorldServer language mapping,routing language mechanism and basic authentication mechanism in JCR properties class

Version 6.3.0-1.3.0

Connectors Packages Configuration

The AEM 6.3 common connector solution builds have been split into two different artifacts,one artifact for WorldServer environment and another one for Mantra environment:

• com.adobe.granite.translation.connector.sdlws.pkg-6.3.0-1.3.0.zip
• com.adobe.granite.translation.connector.sdlmantra.pkg-6.3.0-1.3.0.zip

For customers who are using a patched version of the connector and for which the configurations in the user mapper services are not done automatically the following settings will be necessary:

• Access http://localhost:4502/useradmin

• Search after translation-config-service and make sure that translation-config-service user has reading/writing rights to everything under content:
  
  

Version 6.3.0-1.2.1

Language Mapping

The AEM 6.x connectors contained an xml language mapping that was being read and written in the JCR when installing the connector.

Initially the language mapping configurations where designed specifically for TMS environment.Therefore when using the AEM 6.x common connector solution these configurations were causing inconsistencies in the implementation breaking the target language detection on the WorldServer environment.

Couple of changes were necessary for fixing this issue:

• the language mapping configuration was split between TMS environment and WorldServer environment
• the Jenkins build was separated into two different builds: one build for WorldServer environment and another build for TMS environment
• when building the artifact for TMS environment a Maven profile is being used to pack inside the connector only the language mapping settings specific to the TMS environment.
• when building the artifact for WorldServer environment a Maven profile will be used to pack inside the connector only the language mapping settings specific to the WorldServer environment.

If after installing the connector the target language is still not being detected correctly the user should do the following:

• access  /apps/sdl/config/languageMapping
• search after the language code from AEM
• change the languageMapping property to the ISO code from either TMS environment or WorldServer environment.Please note:on the WorldServer environment the values returned by the WorldServer API are different than the values of the ISO code that the user is able to see on the Locales section.For example for EN-US locale the WorldServer API is returning EN_US as ISO code.For WorldServer environment in the languageMapping property the user needs to use the values returned by the APIs and he needs to make sure that these are correct.

Request Scope 

Request project scope was not working properly on the common connector solution because it did not wait for all the translation files to reach either Authorization step in WorldServer or For Approval status  in TMS. Therefore there was the risk that the project scope was always empty when the translation reached Scope Completed status  in AEM. This aspect has been fixed and now the request scope should function properly.

Filename Truncation Removed

It has been made sure that the filename truncation is not anymore present in the connector implementation starting with this version.

Version 6.3.0-1.1.12

Reject Translation

Considering the following testing scenario:

• A translation job with at least two files
• The translation job was in a Ready For Review state
• The user was first accepting a translation for a file and then rejecting the translation for another file on a WorldServer environment

The general translation job status should had remained in  Translation in Progress and the status of the translation file that was already accepted should had remained in Approved.This was the result that was expected under normal circumstances but status of the translation file that was already approved was being changed back into Translation In Progress.This was fixed and the Reject/Accept translation should work as expected.

Translation API Update

The Translation API had to be updated in order to eliminate the WorldServer target language id detection based on the language code.Doing this caused issues and for languages with the same language code the wrong id was being detected.

This issue was fixed and now the target language id is being detected correctly.

Version 6.3.0-1.1.10

Basic Authentication

By default the option to use the basic authentication mechanism in AEM 6.3 connector is set to be disabled.

In order to activate the Basic Authentication mechanism a user needs to access CRX explorer or CRXDE Lite editor.

Under /apps/sdl/config a user will find a new node called basicAuthentication.

In order to activate Basic Authentication please change the property isBasicAuthenticationEnabled from the stated node to true.

Upon successfully changing this property to true in Cloud Service Configuration page two new fields will appear.These fields will have to be filled with the basic authentication username and basic authentication password in order to be able to authenticate a user and use the connector.

Cloud Service Configuration Page Updates

Cloud service configuration page has been updated to:

• display only the fields specific to Mantra API configuration when TMS option is selected.
• display only the fields specific to WorldServer API configuration when WorldServer option is selected.
• display Basic Authentication Username and Basic Authentication Password only when Basic Authentication mechanism has been enabled.

Version 6.3.0-1.1.9

Basic Authentication

The connector has been updated in order to support basic authentication through a reverse proxy that sits behind a firewall and intercepts all the requests to either WorldServer environment or TMS environment.

In case that the Basic Authentication mechanism is enabled in AEM 6.3 Connector :

• Translation API will take the basic authentication username and basic authentication password and will construct an authentication string encoded in Base64
• Translation API will add this authentication string as a header parameter  in all the requests performed to either WorldServer or TMS environment
• In case  that the basic authentication credentials are missing from cloud service configuration page the requests that are performed through Translation API will not add as a header parameter the basic authentication encoded string  

Version 6.3.0-1.1.8

Translation API implementation Update

Translation API implementation has been altered in order to avoid the breaking of the project creating for the WorldServer environment in case that the WorldServer API from our  customer environments is not updated.

Still this won't guarantee that the detection of the target language id will be successful in case that the customers will restrict the target locales in a project type.

Therefore it is recommended that starting with the previous the WorldServer API is being updated.

Version 6.3.0-1.1.5 

Automatically Complete Task in World Server 

After approving a task in AEM the task was not being automatically completed in World Server.

File and Project Naming Conventions

There was a request for the filename length to be smaller or equal with fifty characters. In case that the filename length was greater than fifty characters the name of the file is being truncated.

For Project Naming Convention the following requirements are currently implemented and released:

• project name length is smaller or equal than fifty characters
• the implementation will remove the square brackets from the folder name that is added automatically by the platform in project name
• the project name will be separated from the folder name by using an underscore
• the project name will not be anymore retrieved from the Cover URL property. Instead it will be retrieved from the jcr:title property

Routing language mechanism

In case that the translation target language in which the content should be translated is different than the translation target language from WorldServer the user has the possibility to route the content for translation in a different language.

More details about this functionality can be found at the following link  AEM Routing Language Mechanism