In Part I of this article we described the dilemma for global platforms related to efficiency vs. flexibility and we outlined an “Agency-Cut” approach vs. “Supplier-Cut”.
Today we will focus on the technical aspects of the “Supplier-Cut” approach.
Things get more complex if an external partner can contribute his own project-specific components, templates or OSGi services. Obviously, this development must conform to the overall platform coding guidelines. To avoid conflicts with other external partners or even the platform owner - who is in charge of the centralized catalogue - you should consider a more sophisticated approach. Consider the following:
Development Process – Code separation
When working on multiple projects with multiple suppliers sharing the same configurations, it is more efficient to avoid duplicating code since this duplication increases the likelihood of defects, the cost of changes, and overall system rigidity. To prevent duplication, provide reusable libraries that can be used across multiple projects – here depicted as “Base V.x.” Also use the out-of-the-box foundation components from the AEM 6.X layer. These will be kindly updated by Adobe in upcoming releases.
"Example Website” demoing available capabilities of BASE V.x and providing sample code to agencies, and project specific artefacts
Base development provided by a central platform team:
General services and standardized components in a well-documented catalogue
Adobe Experience Manager 6.x
Standard software package with several APIs and Foundations Components from Adobe – see e.g. https://helpx.adobe.com/experience-manager/6-4/sites/authoring/using/default-components-foundation.html
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 …
As an example, a content tree in a multi-brand environment could be organised as depicted here:
Finally, we would like to remind you to not forget Adobe’s recommendations which are outlined here:
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.
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.
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.
Testing / Deployment
After all the recommendations above we are now ready to merge and build a new release and then apply a typical software testing/staging phase as depicted here:
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.
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…