AEM Version: 6.2
Target Audience: AEM Developers


In AEM 6.2 Workflows, we can trigger a workflow when a DAM Asset is created, modified, or deleted within a given path. In this article, we will explore triggering workflows from our code based on events in the JCR.

Suppose you have a workflow that creates custom renditions of assets in addition to the default AEM renditions, when the asset is under “/content/dam/ProjectName/images/”. You would have set up two launchers for triggering this workflow: one with event type as “Node Create” and one with “Node Modified”. We can also achieve the same functionality through our code, without touching the GUI.


When assets are moved into a certain folder structure in DAM, trigger a workflow that creates a 100px X 100px thumbnail of our image.


Fig 1: Before Moving the asset, no custom thumbnail. Fig 2: Desired result after moving the asset, the new thumbnail.


The intuitive thought is that when an asset is moved, a new node is created in the new location and the old one is deleted. However, experience shows that AEM does not create a new node in the destination folder on Node Move. We know this because the ‘jcr:Created’ property does not change. AEM does not even change the last modified date.

Creation Timestamp Before Moving the Asset Creation Timestamp is the same after moving

Fig 3: Creation Timestamp Before Moving the Asset. Fig 4: Creation Timestamp is the same after moving

Modification Timestamp Before Moving the Asset. Modification Timestamp is the same after moving

Fig 5: Modification Timestamp Before Moving the Asset. Fig 6: Modification Timestamp is the same after moving.

What if we copy the asset?

On copying the asset, a new version of the same is created. This triggers the Node Creation launcher.

No versions before copying the asset Version created after copy-pasting the asset

Fig. 7: No versions before copying the asset. Fig. 8: Version created after copy-pasting the asset.


Event Listeners

AEM supports observation, which enables us to receive notifications of persistent changes to the workspace. A persisted change to the workspace is represented by a set of one or more events. Each event reports a single simple change to the structure of the persistent workspace in terms of an item added, changed, moved or removed. There are thus 7 possible events at the JCR level, viz:

  1. Node Added
  2. Node Moved
  3. Node Modified
  4. Node Removed
  5. Property Added
  6. Property Removed
  7. Property Changed

We connect with the observation mechanism by registering an event listener with the workspace. An event listener is a class implementing the EventListener interface, that responds to the stream of events to which it has been subscribed. An event listener is added to a workspace with:

(A detailed explanation of each parameter is given with the code example in the package as well as the at the end of this article) As defined by the EventListener interface, listener must provide an implementation of the onEvent method:

When an event occurs that falls within the scope of the listener, the repository calls the onEvent method invoking our logic which processes/responds to the event. In our case, we will register an event listener to listen for “Node Moved” events under “/content/dam/images” so that when an asset is moved to that folder, our workflow can be triggered.


When the component is activated, the activate(…) method is called. It contains a call to ObservationManager.addEventListener(…) for registering the event listener. The deactivate(…) method contains logic for deregistering the event listener, and is triggered when the bundle is being stopped.

When the relevant event occurs, the onEvent(…) method is called, which contains logic for processing the event. In our case, we trigger a workflow.

The following is the relevant code from

Download this code (including the workflow):

Build it using

N.B: Creating a workflow is not part of this tutorial, and therefore a ready workflow has been provided in the code package. However, if you want to learn to create workflows, here is an excellent resource: ->



Adobe Consulting Services. (2018, March 20). acs-aem-samples/ at master · Adobe-Consulting-Services/acs-aem-samples. Retrieved from Github:

Day Software AG. (2018, March 20). JCR 2.0: 12 Observation (Content Repository for Java Technology API v2.0). Retrieved from Adobe Docs:

How to Change Data Type (Typecast) in AEM, Use @TypeHint

Problem Statement:

How to convert a variable from one data type to another data type in AEM.

For a use case where a number field is used in dialog and further data will be utilized in Sightly (HTL) for numeric comparison operations. Problem can come up as data will be stored in String format and comparison can only be made on same data type elements.


@TypeHint: It is used to forcefully define the data type of a property. It can be used as following:


I have a number field in my dialog with name ‘sponsoredPosition’, by default it’s value is stored in String format and I wanted it to be stored in Long format instead of String.


In the component add a node, parallel to the ‘sponsoredPosition’ node (The one of which data type needs to be changed) of the type nt:unstructured.

  1. In the new node add following properties:
  2. ignoreData{Boolean} = true
  3. value{String} = Long
  4. Name{String} [email protected]
  5. sling:resourceType{String} =   granite/ui/components/foundation/form/hidden.


(a) ignoreData, as the name suggests tells value of this field should not be stored.

(b) In value field you must define the data type in which you want your data to be stored.

(c) In Name field add ‘@TypeHint’ suffix to the property name of original node whose value was stored in string(by default) .

(d) Resource type hidden is used for hiding it in dialog.



This blog is intended to provide technical AEM users a solution to an asked question and tactical training on the topic: How to Typecast in AEM.


Adding @TypeHint solved the issue, now value is being stored in Long format instead of String.

Interested in more training and support for your organisation using AEM CMS? Request a consultation to discuss Argil DX managed services.

Sling Models with Sightly Part – IV (Key Annotations – II)

In this post, I will explain some important questions related to OSGi Services and Sling Models. These questions had been asked by some of my blog readers on the basis of my last blog.

So the Problem Statement is-

According to them, They have one interface with multiple service implementations and want to choose any one of these service implementations according to their need. So their questions were-

1. How to choose the desired service implementation from these service implementations in another services or servlets?
2. How to choose the desired service implementation from these service implementations in Sling Model Class?

I have created a demo implementation according to their requirement and for doing that I have created an interface named as TestService with a dummy method named as test(). Here is the code-

Now, I have created two dummy service implementations of this interface. Here is the code for the first implementation named as TestServiceFirstImpl.

Here is the code for my second implementation named as TestServiceSecondImpl.

Answer for the first question-
It is a two-step process. These steps are explained below-

Step 1
Add a new property that have a unique value for each and every service implementation. This property could be anything you want to add. For example, I am using service.label property for these services and on the basis of this property I will choose from these implementations.

Here are my new definitions for TestServiceFirstImpl class.

Code For TestServiceSecondImpl class.

Step:- 2

Use @Reference annotation in another servlet or in OSGi Service with an extra attribute named as “target”. Just redefine this line as shown below-

Try to run your code, you will get the desired output.

Q2. How to choose these services in Sling Model class?

In Sling Model class you can call an external service using two annotations. These are-
1. @OSGiService
2. @Inject with @Source annotation

If you are using @OSGiService annotation then you have an attribute “filter”, here add your condition and you will get the desired implementation as shown below-

If you are using @Inject with @Source annotation then you need to add one more annotation @Filter. Here is the new code-

Now here my complete working code that will show you the use of both of these two approaches.

Q3. How am I testing these annotations in Sling Model class?

I have created a dummy component and that component calls these Sling Model classes. Sightly code snippet is-

For complete working code, I am sharing the Git repository link.

Happy Coding..!!

Ankur Chauhan
Tech Lead