Deliver assets to api & external web application |AEMS AEM 6.5

[digarg31]

I wanted to check on recommendations / best approaches on the below use case -

Use case: - Assets are consumed by online external web applications. When a new asset is uploaded or an existing asset is updated, these need to be tested by staging web application first before prod applications can use them . Once approved on the staging web application, assets should be available to the production application. 

Possible soln - 

a) Upload assets on staging env - > point staging app to stage publish to consume assets & Prod app to prod publish.

Issue - On every approval, user has to package assets and move to prod author and publish.

Pros : No customization

Cons : Manual thing. Will take time and prone to manual error & delays.

b) Customise workflow , on approval on stage add custom replication agent to replicate to prod author & publish.

Cons: Two env to be managed(Stage & prod) - no of authors 8 for now. Stage env is not true replica of Prod so testing may not be accurate .

Pros: External applications point to the same path to digital assets although the domain will be different.

Another approach could be - to maintain two folders on prod publish itself - like stage-ready & prod ready . Point staging extrenal web app to stage ready and once approved copy asset to prod-ready   folder manually or via workflow

Cons - Too many folders on 1 env and duplicate assets when seraching.

Staging application & prod application would be pointing to slightly different paths .

Pros :- all external applications (stage & prod) refer to same env so testing is thorough with CDN etc in place.

[lukasz-m · Accepted solution]

Hi @digarg31

Personally I would try following approach:

1. Create/extend asset metadata schema with 2 additional fields: stg-rdy and prod-rdy. Alternatively to minimize implementation effort you can create dedicated tag namespace with 2 tags stg-rdy and prod-rdy in that case you do not need any changes on assets schema level.
2. Create an approval workflow that depending on stage of approval will simply set stg-rdy or prod-rdy flag. Again if you decide to use tags instead, the workflow will just set a proper tag.
   
3. Last part will be a sling servlet that will base on resource type - dam:Asset, and 2 selectors stg or prod. So if you will request for the asset with stg selector e.g. /content/dam/my-folder/my-picture.stg.jpg - the servlet will handle that request and will check if asset has been approved for stage (base on metadata or tag set by workflow) and return asset or error in case requested asset has not been approved yet either for stg or prod. This mechanism will work exactly the same for prod, the only difference is that you will check different tag or metadata.

Cons:

• some development is needed, however this approach is full aligned with AEM development approach - you are not doing something that is unusual in terms of extending AEM

Pros:

• One environment - you can use one environment - prod - for entire process. Having this process encapsulated into one environment you can very easy test some bug fixes or improvements on lower environments before promoting this to prod.
• One source of true - each asset stores clear information if it is ready for stg and/or prod. There is no asset or information duplication. Also changing location of asset e.g. moving to different folder, will not affect information if asset has been already approved for stg and/or prod.
• Thanks to metadata, or tags usage, authors can easily search for specific asset, or group of assets.
• Implementation utilizes AEM and/or sling features (metadata schema, workflows, sling servlet)
• Using selectors to access asset it can easily be cached on dispatcher - this will reduce traffic that will directly hit AEM publish.
• Stg and prod will point to the same env, domain and path, only selector will change.