Challenges in Adobe AEM Multitenancy Configurations

Following this approach, we now have a centralized platform owner responsible for the Adobe AEM configuration, the code within BASE V.x and the code for the Example Website. External partners can create brand specific sites using BASE artefacts by either inheriting or copying the artefacts from BASE.

To avoid conflicts we need to separate the code/configuration for each “Brand” into the following folders (might differ depending on the features required):

This structure, which includes the necessary access for external partners, is provided by the platform owner.

But now we face a second challenge: each external partner works in its own repository and must be able to deploy releases independently to the various environments.

Consequently, something must be in place to keep the various repositories synchronized when working on a) evolutions, b) maintenance fixes, and c) so-called “overlays” (i.e. general changes in the AEM functionality achieved by overriding native features of AEM). The latter are evil for the platform owner because overlays may affect the whole platform. Additionally, overlays are not in the migration path for the Adobe product team and thus often create severe migration problems when new updates of AEM become available.

A valid approach to adding new artefacts to Base while keeping repositories in sync is depicted here:

This mechanism can be extended to multiple suppliers:

• The Base and Example repository is forked to the external partner repository.
• Commits to the Base and Example repository branches are automatically replicated to the external partner project repository.
• Commits to the partner repository must be merged manually to the central repository with a Pull Request (PR).
• Packaging and deployment are always performed from the central branches.
• The suppliers can manage more branches in order to isolate new features. When a feature is ready the branch is merged to the central “develop” branch.

Multisite Manager (MSM)

Obviously, it is a good idea to use the powerful Adobe MSM module to manage all the inherited content across the entire platform. Different configurations are possible for companies with content that spans multiple brands and geographical regions. First, it should be clarified whether the inheritance is driven rather by the page structure or simply by the master content pages that can be directly inherited. Therefore, a closer look at the Swiss product pages – with three active languages – might be helpful. Typically, you will find in your MSM settings a content master in English and Live Copies serving as language masters for German, French, Italian, etc. You now have two options: either you inherit directly from the language masters and localize then on the lowest level. This is only efficient if the structure of the Italian site (for which the Italian language master is provided) is similar to the Swiss/Italian site (inheritance of content). However, if the structure of the Swiss language sites follows, for example, the French structure, then it would probably be more efficient to create the German and Italian Live Copy from the Swiss/French version. Finally, you have all flavours in between these models which comes along when using translation engines with translation memories.But this is worth another article …

Finally, we would like to remind you to not forget Adobe’s recommendations which are outlined here:

https://docs.adobe.com/docs/en/aem/6-3/administer/sites/msm.html

Rights Management

For those who might have thought that with code separation everything is settled, here is another topic:

Rollout of new brands often requires the creation of new groups (and users). You could allow, as the central platform owner, each external partner to access and configure their permissions via the AEM admin interfaces – but what a potential security leak!
Next option: The external partner writes a long release letter specifying the group permissions he needs, and the platform owner configures them manually – again, another source of errors.

A far better way to industrialize rights management is to use an access control (AC) tool that creates new groups during deployment. Example: https://github.com/Netcentric/accesscontroltool

The advantage is obvious: The access control configuration is contained within the application package and so versions are managed and traceable.

Search Indexing

Every brand probably wants to restrict searches to its own content. OAK allows one to create dedicated indexes at the folder level and thus supports a multitenant environment.

OSGI Bundles Exports / System configurations

The deeper we dive into the technical stack, the more we face conflicts with multiple suppliers during the deployment process. Amongst other topics I would like to highlight the fact that any OSGi configuration changes to the global system, including base OSGi deployments, should be controlled and executed centrally. Obviously, the same restriction applies to system-wide configurations.

Application deployment

If external suppliers frequently need to work on applications hosted on the platform, a check during the central build process could assure that supplier X for project x only uses configurational files for “com.suppplier_x.*”

Vanity URLs/ Dispatcher Configuration

Very likely each brand will have its own URLs and so we have to establish a centralized URL management scheme that considers the Vanity URLs and Dispatcher configuration (and probably CDN management and …, but we stay focused on AEM here).

First, we think it is essential that each project utilises a specific prefix so that the configurations remain clear for the platform provider. Secondly, we would like to propose an alternative to the global /etc/maps scheme from Adobe. We recommend using mod_rewrite rules in the Apache Dispatcher instances. Using this setup allows for a central point of configuration in combination with outbound-only Resource Resolver rules. Consequently, the rewrite rules can be controlled by each project independently. During build these configurations are deployed as part of the Dispatcher configuration and finally the Apache process is restarted.

Obviously it makes sense that each brand, with its own project team and external suppliers, manages functional testing during development. However, it is the responsibility of the platform owner to assure that the overall stability and performance of the platform is not negatively affected by this development. During the development process, a testing-responsibility matrix is useful to help clarify who is in charge of each test procedure (white box, black box, etc.), and which quality goals must be met in order to proceed to the next quality gate.
Industrialization of testing procedures may help to manage the number of deployments coming up over the year. Regression testing tools such as Selenium for example pages and brand-specific development, along with Checkstyle, Junit, JMeter and Sonar for code quality, can help the platform owner maintain high quality across the multitenant platform.

Conclusion

There are many points to consider when operating multitenant AEM environments. This article has definitely not covered all of them, but probably the most important ones.

But if you appreciated these two articles I may write a third one…