Note that a Developer license for AEM can be obtained through the Adobe Exchange Program.
AEM is a cutting-edge web experience management solution and offers many potential areas of integrations. Common integration patterns include:
Experience Manager as a Cloud Service documentation provides valuable insights into developing in AEM. Below are some specific technical topics and references that you may find useful while implementing an AEM connector:
In addition to the static documentation above, Adobe and the AEM community offer resources to help bring a connector to market:
In order to support rolling deployments, AEM as a Cloud Service packages, of which connectors are examples, have a strict separation between “immutable” and “mutable” content. Packages should be cleanly separated between those that include:
Connectors should adhere to these packaging guidelines, which are described in this article. Existing connectors should be refactored to conform, as well.
In addition, only Adobe should write code into
/libs, with customers and partners writing into
Existing connectors may also need to be refactored to move any configuration that might once have been placed
/etc into other top level folders such as
/conf. This restructuring was done as part of AEM 6.5 and is described in the AEM 6.5 documentation.
It’s recommended that the majority of connector code is placed under
/apps/connectors/<vendor> to promote a clean repository structure for customers who have several connectors.
One aspect of the connector implementation is code backing the configuration of the connector. This code causes a card with the connector’s name to appear under Tools > Operations > Cloud Services. When clicked, a configuration browser pops up where the customer selects the parent folder to contain the connector configuration. The connector’s code should result in a form with all the properties that must be configured, ultimately storing the values in a configuration folder under
/conf. This folder can later be selected under the Sites properties tab or the Assets properties tab.
Context-Aware Configurations allows to layer configuration across different folders, including
/conf and subfolders under
/conf. It supports inheritance so a customer can configure global configuration while making specific changes for each microsite. Because it is possible to leverage this feature for Cloud Services Configurations, connector code should reference configuration using Context-Aware Configuration API instead of referencing a specific configuration node.
If modified configurations are used in the Connector, architect the Connector to handle including/merging any future updates to Connector-provided default configurations with any customer configurations. Remember that changing customized (as in changed by the customer) content or configuration without customer warning and consent may break (or create unexpected behavior) with their Connector.
Since AEM as a Cloud Service is a Cloud-native solution, there are some guidelines which may impact a connector’s code strategies. See AEM as a Cloud Service Development Guidelines for more details.
New connectors should be created (or existing connectors modified) using local environment development techniques. The Partner Team will provide ISV partners with a sandbox environment where they can deploy their AEM Connector to a vanilla application to ensure that it works.