Wanted to deploy Content Fragment extension to Production Workspace

[Mahesh_Gunaje]

Hello Team,

I have an Content Fragment Extension project. Earlier, I have deployed this to Development, Stage and Production workspace. AEM admin has approved the Production workspace. Now the Production workspace status is "Published".

Now, I have modified the project logic. When I try to deploy the project(using the command: aio app deploy) to "Production" workspace, getting below mentioend issue.

This application is published and the current workspace is Production, deployment will be skipped. You must first retract this application in Adobe Exchange to deploy updates.

Can anyone aware of this process? Where AEM admin can do this step? My team is not aware of this process and where to retract the application. If possible, can someone pass me the snapshot to retract the application process?

Thanks in advance.

cc @arunpatidar  @partyush  @AmitVishwakarma  @sarav_prakash 

[arunpatidar · Accepted solution]

Hi @Mahesh_Gunaje 

Please check https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/developing/extensi... 

[Mahesh_Gunaje]

Thanks a lot @arunpatidar  for your quick response. 

I have 1 more query here.

1: I have Adobe IO runtime project, that is deployed to "Production" workspace. This got approved. Status is "Published". Note: This is micro service project, written in NodeJS.

Then, developer has modified the logic. He was able to deploy the code to "Production" workspace using the command: aio app deploy. He didnot faced the issue during re-deploy to "Production" workspace, even though the status is "Published".

Where as in my case, Project is : Content Fragment Extension project" app.config.yaml file has below details.  ( Obviosly this is separate Adobe IO project with Development, Stage, Production workspace. )

extensions:
aem/cf-editor/1:
$include: src/project-folder/ext.config.yaml

But, in my case, I am getting the error that I have mentioned earlier.

So, wanted to know the difference between these 2 projects. Difference between these 2 Adobe IO Runtime project.

Thanks

[partyush]

Hi @Mahesh_Gunaje 

The key difference lies in the type of project and its deployment lifecycle:

Content Fragment Extension Project:

• Configuration: Your app.config.yaml includes:

  extensions:
    aem/cf-editor/1:
      $include: src/project-folder/ext.config.yaml

  1. • Nature: This is an AEM Content Fragment Extension, a specialized type of Adobe IO Runtime project designed to extend AEM functionality (e.g., custom editors for Content Fragments).
     • Lifecycle: Extensions are integrated into AEM and often published via Adobe Exchange. Once published, they require retraction before updates can be deployed to maintain stability and ensure compatibility with AEM’s ecosystem. This involves an approval process and a marketplace-like management system.
     • Behavior: When "Published," updates are blocked until the extension is retracted from Adobe Exchange, as seen in your error message.
  2. NodeJS Microservice Project:
     • Configuration: This is a standard Adobe IO Runtime project, not an extension (no extensions section in its app.config.yaml).
     • Nature: This is a general-purpose microservice running on Adobe IO Runtime, independent of AEM-specific extension mechanics.
     • Lifecycle: Regular runtime projects don’t typically go through Adobe Exchange or an approval/publication process for deployment. You can directly update the Production workspace without retraction, as long as you have the necessary permissions.
     • Behavior: The developer can redeploy updates using aio app deploy without restrictions, even when the status is "Published," because it’s not tied to the extension lifecycle.

  Why the Difference?

  • Extensions vs. Runtime Projects: Extensions (like your Content Fragment project) are tightly coupled with AEM and Adobe Exchange, enforcing a stricter update process to ensure they work seamlessly within AEM’s UI and ecosystem. Regular runtime projects (like the microservice) are standalone and have a simpler deployment model.
  • Publication Process: Extensions are published to Adobe Exchange, requiring retraction for updates, while regular runtime projects don’t involve this step.

  For the Content Fragment Extension Project

  1. Log into Adobe Exchange with your developer account.
  2. Navigate to the developer section (e.g., "My Exchange" or "Developer Console").
  3. Locate your Content Fragment Extension.
  4. Retract or unpublish it using the available option.
  5. Run aio app deploy to update the Production workspace.
  6. Resubmit for approval if needed to republish it.

  Understanding the Difference

  • Your Content Fragment Extension requires retraction because it’s an AEM extension managed through Adobe Exchange.
  • The NodeJS microservice project skips this step because it’s a standard runtime project with no extension-specific constraints.

  Thanks 

  Partyush

[Mahesh_Gunaje]

Hi @arunpatidar 

AEM admin has revoked the extension project. Now,  I am able to deploy the project to Production Workspace. After that, I am able to see the project in Extension Manager portal. Enabled the app/extension for dev, stage environment. Able to test the feature properly. Note: Still the status of project is: Retract. So, my query is: Now, for what purpose, I need to raise Approval request for Production workspace? Is it necessary to test the extension on AEM prod site?

cc @sarav_prakash  @AmitVishwakarma  @partyush 

Thanks

[arunpatidar]

Hi @Mahesh_Gunaje 

Once the extension request is approved, the extension immediately becomes active in the AEM as a Cloud Service Author services.

[partyush]

Hi @Mahesh_Gunaje 

• Raising an Approval request is the required step to transition the extension from "Retract" to "Published" status. Only after approval will the extension become live and accessible on the AEM production site.
• Deploying the project to the Production Workspace makes it available for management (e.g., enabling it for dev and stage), but it doesn’t automatically publish it to production. The approval process ensures that the extension is reviewed and meets the necessary standards before going live
• The Approval request acts as a checkpoint to verify that the updated extension is stable, compatible with the production environment, and won’t cause issues in the live system. It’s a safeguard, not just a formality.

Note : You must raise an Approval request for the Production Workspace to publish the extension and make it live on the AEM production site. Without this, the extension will remain in "Retract" status and unavailable to end users

So, you need to raise the Approval request to make the extension available and functional on the AEM production site.