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.
Starting with version 6.3.0-1.1.8 the WorldServer API for the WorldServer environment should be updated with CU5 or above.
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.
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.
Couple of settings have been moved under configurations node as follow:
Changed the approach in detecting the file extensions:
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
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.
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.
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.
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:
Implemented endpoint to reject translation in AEM connector through Mantra API.
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:
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.
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
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:
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:
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:
If after installing the connector the target language is still not being detected correctly the user should do the following:
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.
It has been made sure that the filename truncation is not anymore present in the connector implementation starting with this version.
Considering the following testing scenario:
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.
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.
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 has been updated to:
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 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.
After approving a task in AEM the task was not being automatically completed in World Server.
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:
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