Prerequisite knowledge

  • Understanding of AEM Mobile
  • Knowledge of creating and publishing content through the On-Demand Portal
  • Experience with On-Demand Services APIs

Required products

  • AEM Mobile
  • Access to the On-Demand Services API
  • Shared Content

Introduction to Shared Content

The On-Demand Services APIs (previously called "Content Producer Service APIs") allow a third party developer to integrate with the On-Demand Services. This service allows you to do the following:

  • Manage articles
  • Manage collections
  • Manage products
  • Manage push notifications

When you want to publish multiple HTML-based articles, you can use the Shared Content API to bundle content that is shared among these articles. This article explains how to use Shared Content.

In AEM Mobile, you can publish individual articles. Each article is identified by its article_name. When you set up shared content, you allow multiple HTML-based articles to use the same CSS and Javascript files.

Without using Shared Content, each HTML article needs to include its CSS and JS files.

In this example, the ‘css/style.css’ and ’js/main.js’ files are duplicated in every article, which causes overhead. Using Shared Content, these files can be added in one sharedContent entity and referenced by each article.

When using Shared Content, shared files are stored in a single entity and referenced from multiple articles.

Understanding Dynamic Shared Content

With the AEM Mobile 2017.2 release (2017 February 6), dynamic shared content lets you update shared content without having to update the articles that refer to the shared content. Before this release, using the sharedContent entity required you to update both the shared content and the articles that linked to that content. App users were then required to tap the "Update" prompt to obtain the updates. With this release, you can use the new dynamicSharedContent entity to upload shared content. When you update the dynamic shared content and publish it, the changes are then made automatically to all referring articles. You no longer need to update the referring articles, and users no longer need to tap the Update prompt.

Both the sharedContent and dynamicSharedContent workflows are supported. This section refers to using dynamic shared content. If you want to use the previous shared content workflow instead, substitute sharedContent for dynamicSharedContent where appropriate.


Using Shared Content

  1. Create an article entity for each article.

  2. Upload the article contents (zipped with the manifest.xml) to the ingestion service. For details, see Creating HTML articles for AEM Mobile.

  3. Create the shared content entity. Request body should contain standard entity metadata attributes. Note that in the following examples, the field `sc_one` is the dynamicSharedContent entity name.

    PUT /publication/<projectID>/dynamicSharedContent/sc_one
  4. Obtain the contentUrl from the resulting created entity (part of the response).

        "_links": {
            "contentUrl": "/publication/<projectId>/dynamicSharedContent/sc_one/contents;contentVersion=<cVersion1>/"
  5. Upload the shared resources to this contentUrl.


    PUT /publication/<projectId>/dynamicSharedContent/sc_one/contents;contentVersion=<cVersion1>/css/style.css
    PUT /publication/<projectId>/dynamicSharedContent/sc_one/contents;contentVersion=<cVersion1>/js/main.js
  6. Seal (commit) the dynamicSharedContent entity’s contents.

    PUT /publication/<projectId>/dynamicSharedContent/sc_one;version=<entVersion>/contents
  7. Obtain the updated contentUrl from the sealed entity (part of the response).

        "_links": {
            "contentUrl": "/publication/<projectId>/dynamicSharedContent/sc_one/contents;contentVersion=<cVersion2>/"
  8. In the article, upload a symbolic link asset that refers to the shared contentUrl.  Note that in the following examples, the field `article_one` is for the article entity name, and the field `shared` is the name of folder that will contain the shared contents. First, get the latest dynamicSharedContent entity version by doing a GET call. Next, update the link to the shared resource.

    PUT /publication/<projectId>/article/article_one/contents;contentVersion=<cVersion3>/dynamicShared
    Content-Type:  application/vnd.adobe.symboliclink+json
    {"href": "/publication/<projectId>/dynamicSharedContent/sc_one/contents;contentVersion=<cVersion2>/"}
  9. Set up additional references to another share content entity in the same article.

    PUT /publication/<projectId>/article/article_one/contents;contentVersion=<cVersion3>/fonts
    Content-Type:  application/vnd.adobe.symboliclink+json
    {"href": "/publication/<projectId>/dynamicSharedContent/sc_two/contents;contentVersion=<cVersion2>/"}

    Note that the Content-Type header identifies this resource as a symbolic link, the name of the resource (“article_one” in the example) identifies the source of the symbolic link, and the contents of the uploaded asset identifies the target.

  10. Seal (commit) the referring entity's contents.


    PUT /publication/<projectId>/article/article_one;version=<entVersion>/contents

    Content assets within article_one can now refer to content in the dynamicSharedContent entity simply by using the “shared” (for sc_one) and “fonts” (for sc_two) prefix. The dynamicSharedContent are located relatively to the HTML article, one directory above it.

    The HTML content of article_one would reference the javascript and css in the following way:

    <script src="../shared/js/logic.js"></script>
    <link rel="stylesheet" type="text/css" href="../shared/css/style.css">

    Fonts can be made available in the following way:

    @font-face {
      font-family: "myFirstFont";
      src: "url(../fonts/Exotic_Regular.woff");
  11. Publish the dynamicSharedContent entity for non-Preflight apps or trigger the preflight for Preflight-enabled apps in order to propagate the changes for the dynamicSharedContent entity to all of the referencing articles.

    PUT /job
        "workflowType": "publish",
        "entity": {

Migrating existing shared content to dynamic shared content

The new shared content capabilities do not affect existing shared content workflows. If you want to take advantage of dynamic shared content, you must change your existing shared content to enable the new dynamic workflow.

  1. Create a new dynamicSharedContent entity.

  2. Add all the assets from the previous sharedContent entity to the new dynamicSharedContent entity and seal the entity's contents.

  3. Update the symbolic link (symlink) files in each article to point to the new dynamicSharedContent entity in the sealed version.

  4. Preview (preflight) the project content. The dynamic content should be available in articles.

  5. The new shared content capabilities do not affect existing shared content workflows. If you want to take advantage of dynamic shared content, you must change your existing shared content to enable the new dynamic workflow.

    When you're ready to publish, publish the dynamic shared content. Then publish the articles that reference the shared content.

    To update shared content, add or change assets in the dynamic shared content and seal the entity. Preview articles that refer to the shared content, and then publish the dynamic shared content. The changes will be reflected in the referring articles.


At this time, it is not possible to unpublish dynamic shared content. Until this option is supported, a workaround is to remove all the file contents from the dynamic shared content and republish. You can also remove the symlink to this dynamic shared content from the referring articles or dynamic banners.

Considerations for Shared Content

When you are using shared content in your articles, the viewer must download the complete shared content entity before it can render the article. Consider creating multiple shared content entities instead of using one big entity that contains all shared content.

The path under which the content is available depends on the creation of the symbolic link, as shown in steps 8 and 9. In step 8, sc_one is referenced under the path ‘shared’. In step 9, sc_two is referenced under path ‘fonts’. You can compare the ways shared content works with using symbolic links under an Unix operating system.

Shared content can only be managed through the On-Demand Services API. Currently, there is no user interface in the On-Demand Services Portal to manage shared content.

The On-Demand Services API include examples for sharedContent, see /sharedContent folder.