Workflow in AEM (Part -1)

 What is Workflow?

• It allows you to automate your tasks, which can be individual tasks or a series of tasks performed sequentially, mainly on content, such as pages and assets.
• When you create a Workflow, the first thing you need is a Workflow Model. The Workflow Model is the heart of the workflow, as it contains a series of steps. Each step can perform a specific task, providing complete functionality. You can reuse these steps in any workflow.
• There are 'n' number of steps available out of the box in AEM. However, you can also create your own steps.

When you create a Workflow Model, it is stored in two places in the repository.

• Model Design [/conf/global/setting/workflow/model]
• Runtime Model [/var/workflow/models]

When we talk about steps, for example, step 1, step 2, up to step 'n', there are four types.

• Container Step: When we want to trigger another model or workflow, for example, when we want to execute or trigger a child workflow, we use a Container Step. 
• Participant Step: When we require human interaction within a workflow, such as assigning tasks to someone, we use a participant step.
• Decision Step: When you need to perform a task based on a condition, typically when branching is required in your workflow, you use a decision step.
• There are two types of decision steps:

1. AND
2. OR

• Process Step: Custom workflow processes are implemented using the process step.

After creating a workflow model, it can be invoked in three main ways.

1. Launcher
2. API/Code
3. Manually

• Launcher:- When we want to automate the triggering of a workflow, we create a Launcher.
• API/code:-When we want to trigger this workflow using code, we can do so in any backend module, such as a servlet or Sling model. This can be achieved using API/Code.
• Manually:- In AEM, we have a console where we can trigger this workflow manually.

How do you write a Workflow Model?

• Models: All the Out of the Box models will be present under models, and you can create your own model.
• Instances: All the running instances of that workflow will be present under 'instances.
• Launchers: All the Out Of the Box launchers will be present under 'launchers', and you can create your own launcher as well.
• Archive:- All the successful workflow instances will be present under Archive.
• Failures:- In case your workflow fails due to any reason, the instances of failed workflows will be present under 'Failures'.

Step1:

Step 2:

Step 3:

Step 4:

Step 5:

Step 6:

Step 7:

Manually Trigger Workflow

Step 8:

How to trigger a workflow through the Launcher

Step 1:

After create Workflow

Step 2:

Step 3:

Step 4:

How to trigger a workflow through the API/Code

• For triggering a workflow via API in the backend, first, you need a WorkflowSession.
• Once you have the WorkflowSession, you then need a WorkflowModel. You need the WorkflowModel when you are using the WorkflowSession to pass the exact path in your Runtime model, which you can then trigger.
• After that, you need WorkflowData, which you use with the WorkflowSession, essentially using the payload of your workflow.
• Once you have both the WorkflowModel and WorkflowData, you can start the workflow by using the WorkflowSession and passing both the WorkflowModel and WorkflowData.

We are using a servlet as a backend module to trigger the workflow using API/code.

Step1:

Step 2:

Step 3:

In error.logs

Step 4:

Quotes

Success is the sum of small efforts - repeated day in and day out.

Thanks for Reading

Matri Sharma

OSGI Factory Configuration

• OSGI Factory Configuration

When you want to create more than One instance of any OSGI Configuration in that case you will create OSGI Factory Configuration.

for eg:-

• How to make a OSGI Configuration as a OSGI Factory Configuration?

@Designate(ocd=Configuration name.class, factory=true)

• we add factory=true parameter 

How to write OSGI Factory Configuration? 

• Step 1: We can keep our configuration in a separate file

for example: com.adobe.aem.assets.asics.core.config

Step 2: write OSGI service Interface

Step 3: write OSGI service class

What is the meaning of 

• Inside the @Reference annotation, we can define which service to inject using the OSGi filter configuration.
• In OSGi, the cardinality of a reference is defined by the cardinality attribute of the @Reference annotation. It determines how many service instances can be bound to a component and how the component behaves when services become available or are withdrawn.

• Without Multiple (Default Single Cardinality):

  If the cardinality is not specified or set to single, the component will bind to the first available service instance. Once bound, the component will not listen for additional service instances.

  With Multiple Cardinality:

  If the cardinality is set to Multiple, the component will listen for and bind to each service instance that becomes available. The binding method will execute every time a new service instance is created.

• POLICY DYNAMIC:

• If the policy is set to Static, OSGi will not dynamically manage the binding and unbinding of services. In this case, it will not automatically consider the unbind method.
• If the policy is set to Dynamic, it means that the component can dynamically bind and unbind services. When your method is volatile and the policy is dynamic, OSGi will automatically find and use the unbind method, based on its name, to handle the unbinding of services.

How Bind and Unbind Work

• Whenever a service is bound, the bind method is called. At bind time, if the configuration is created or available, it binds with the service. The first time, it creates a list, and each subsequent time, it adds the configuration to that list. Every time this method executes, it keeps adding to this list.

• Every time a configuration is removed, the unbind method is triggered and removes that configuration from the list. Suppose you add a configuration; the bind method will execute and add the configuration to the list. If you remove that configuration, the unbind method will execute and remove the configuration from the list.

Step 4: Write Sling Model Interface

Step 5: call in sightly

Step 6: To Adding Configuration in Factory Configuration

How to view configuration on page

Thanks for Reading

Matri Sharma

Quotes 

"It takes courage to grow up and become who you really are." — 

OSGi Service with filter and target in AEM

1. What happened when service interface has multiple implementation?

• We can understand this concept for certain use cases

• when we dealing with multiple implementations of an interface, 
• such as a OsgiFilterDemo. For instance, 
• let's consider having two classes: OsgiFilterDemoAImpland OsgiFilterDemoBImpl. 
• Both of these classes implement methods like (getFirstName) and (getSecondName).
• When invoking the service without explicitly specifying which implementation to use 
• The default behavior typically refers to the original service. 
• In this case, if no specific implementation is mentioned, OsgiFilterDemoAImpl will be called  because it has a lower service identifier compared to OsgiFilterDemoBImpl.

• Create Dummy Component

If you want to render data in an HTML file using Sightly,

In this case, if no specific implementation is mentioned, OsgiFilterDemoAImpl will be called
because it has a lower service identifier compared to OsgiFilterDemoBImpl.

• Suppose I want a particular implementation class, OsgiFilterDemoBImpl, to be invoked. In that case, I can define ranking using the @ServiceRanking annotation. The service with the higher ranking will be called.
• If you want to invoke OsgiFilterDemoAImpl instead, consider giving it a higher service ranking. 

 

• Suppose we want a specific class to be called each time, with the higher-ranking class always being invoked. However, there are times when we want either the OsgiFilterDemoAImpl or OsgiFilterDemoBImpl implementation class to be called without explicitly specifying the service ranking. In such cases, we can define a filter when calling the service, allowing us to decide whether to call OsgiFilterDemoAImpl or OsgiFilterDemoBImpl.

In other ways to implement class via Filter.

If you want to call both services in a Sling model simultaneously, you can do so.

The way you can call it in the Sling Model, but if you want to call it in a different backend module (Servlet, Scheduler, Workflow Listener, etc.), you can add a call to the OSGi service. Except for the Sling model, we can use the @Reference annotation to make the call from any other backend module. To call the classes OsgiFilterDemoAImpl or OsgiFilterDemoBImpl, you can utilize @Reference with the target parameter. By passing the target, you can define which implementation you want to call.