Extension development overview
NOTEOne of the primary goals of tags in Adobe Experience Platform is to create an open ecosystem where engineers outside of Adobe can expose additional functionalities on their websites and mobile applications. This is accomplished through tag extensions. Once an extension has been installed on a tag property, that extension’s functionality then becomes available for use by all users of the property.
This document outlines the primary components of an extension, and provides links to further documentation to help guide you on the extension development process.
Extension structure
An extension consists of a directory of files. Specifically, an extension consists of a manifest file, library modules, and views.
Manifest file
A manifest file (extension.json) must exist at the root of the directory. This file describes the makeup of the extension and where certain files are located within the directory. The manifest functions similarly to a package.json file in an npm project.
Library modules
Library modules are the files that describe the different components that an extension provides (in other words, the logic to be emitted within the tag runtime library). The content of each library module file must follow the CommonJS module standard.
For example, if you are building an action type called “send beacon”, you must have a file that contains the logic that sends the beacon. If using JavaScript, the file could be called sendBeacon.js. The content of this file will be emitted within the tag runtime library.
You can put library module files in anywhere you like within the extension directory, provided that you describe their locations in extension.json.
Views
A view is an HTML file capable of being loaded into an iframe element within the tags application, specifically through the Experience Platform UI and Data Collection UI. The view must include a script provided by the extension and conform to a small API in order to communicate with the application.
The most important view file for any extension is its configuration. See the section on extension configurations for more information.
There are no restrictions as to what libraries are used within your views. In other words, you may use jQuery, Underscore, React, Angular, Bootstrap, or others. However, it is still recommended to make your extension have a similar look and feel to the UI.
It is recommended that you put all view-related files (HTML, CSS, JavaScript) within a single subdirectory that is isolated from the library module files. In extension.json, you can describe where this view subdirectory is located. Experience Platform will then serve this subdirectory (and only this subdirectory) from its web servers.
Library components
Each extension defines a set of functionalities. These functionalities are implemented by being included in a library that is deployed to your website or app. Libraries are a collection of individual components, including conditions, actions, data elements, and more. Each library component is a piece of reusable code (provided by an extension) that is emitted inside the tag runtime.
Depending on whether you are developing a web extension or an edge extension, the available types of components and their use cases differ. Refer to the subsections below for an overview of which components are available for each extension type.
Components for web extensions
In web extensions, rules are triggered through events, which may then execute specific actions if a given set of conditions are met. See the overview on module flow in web extensions for more information.
In addition to the core modules provided by Adobe, you can define the following library components in your web extensions:
NOTEComponents for edge extensions
In edge extensions, rules are triggered through condition checks, which then execute specific actions if those checks pass. See the overview on the edge extension flow for more information.
You can define the following library components in your edge extensions:
NOTE