Every few years, our contract with Adobe allows for a complete refresh of everything -- the servers, the networks, the platform, and everything else. In May 2017, Adobe released AEM6.3 and the LSA Web Services developers have been preparing for the upgrade throughout the summer and fall of this year. U-M LSA's version 4.0 of the customization package coincided with the AEM6.3 upgrade. It contained 160 committed code changes. In addition to this development effort, the upgrade required developing, testing and validating a repository migration strategy from AEM 6.1 to 6.3.
LSA Web Services System Engineer Matthew Cruz worked with the Adobe Managed Services engineer to create the servers, networks and configurations according to the latest standards. This effort resulted in a 65 page procedural setup document and checklist of 63 tasks required to complete the job, which described all the work required during the content freeze period from 5PM 11/29 until 12/4.
Notable Features and Enhancements
Everything should be faster including Gateway Search. When migrating data to the new servers, the content repositories were completely restructured and optimized at a very low level. The result is a much faster system. The results should be apparent when using the search bar on LSA Gateway or department Portals or any of the other query based components.
More support for the Touch UI editing interface. AEM has two interfaces Classic UI and Touch UI. The older Classic UI is still the default editor for most users, but v4.0 includes new Touch UI dialogs for all components and page templates. Interested users may try the Touch UI editing interface by changing a portion of the author URL from .../cf#/... (Classic) to .../editor.html/... Keep in mind that Touch UI training will soon be offered by Web Services, but until then we encourage users to continue with the Classic UI page editing interface.
U-M LSA Developer Ananta Saple implemented a solution for the LSA Gateway and department Portals so users are able to display Google Calendars on their restricted access portal pages. The Gateway and Portals also have enhanced support for showing or hiding LSA Container components (aka sections) based on the users access permissions. This means Gateway and Portal visitors will no longer see artifacts of excluded content due to access restrictions.
There is a new component in the Sidekick called SVG. Scalable Vector Graphics is an XML-based image format. This component not only allows SVG images stored in the DAM to be used and displayed on pages, but advanced authors are able to inject links and CSS style effects such as hover. This component should be used when authors want to embed hyperlinks into specific regions within SVG diagrams, or when hover or possibly other interactive effects should occur within a portion of an image. One nice thing about the SVG format is the crisp look as compared to scaled raster formats, which are sometimes 'grainy.'
Some users have reported grainy images throughout their sites. While we continue to study options to remedy this in future releases, we did include a new option to select an 'Orginal' from the DAM using the Image component Touch UI dialog. This process will likely be covered in a forthcoming TouchUI authors training course.
Testing and validation played vital role in successfully implementing this upgrade. The QA effort led by Jessica Kowalewski involved regression testing features and fixes implemented over the previous 10 releases. The QA team verified changes since v2.0 (6/2016) were still operational in v4.0. The team diligently reviewed change logs creating tickets whenever something was not working properly, and tracked identified QA problems to resolution. Jessica and Ananta Saple created new programmatic quality tests which verified rendering using the perceptual differential tool DPXDT.
The integrity of the college's data is of chief concern whenever irreversible data operations are executed. The team executed multiple methods of ensuring the integrity of data. Each validation test was executed in two parts; before the migration and after migration. Comparing the results indicated no data was lost after undergoing the migration and upgrade processes. The validation consisted of three methods with differing levels of granulaity.
Method 1. System disk usage was the least granular, but indicated our restructuring had succeeded.
Method 2. Pre and post-migration reports internal to AEM showed volume utilization and node and property counts for each major part of the repository.
|Disk Volume||Increased 0.056% after migration|
|Nodes||Increased 0.47 % after migration|
|Properties||Increased 5.69% after migration|
Method 3. The finest grain method used to validate data integrity involved generating hashes for page and system nodes. Comparing the pre-migration hashes to post-migration hashes indicated where differences if any existed. For example of the 57,464 college and department pages evaluated, 6 differences were identified.