AD0-E134 Practice Questions

The WorkflowProcess interface is the interface to be used for automatic workflow steps

implemented in Java. Classes implementing this interface define Java based processes that can be

attached to a WorkflowNode and executed by the workflow engine. The method execute takes a

WorkItem, a WorkflowSession and a MetaDataMap as parameters and performs the logic of the

custom process step. Reference: https://developer.adobe.com/experience-manager/referencematerials/6-5/javadoc/com/adobe/granite/workflow/exec/WorkflowProcess.html

https://experienceleague.adobe.com/docs/experience-manager-learn/forms/adaptiveforms/custom-process-step-aem-workflow.html?lang=en

When an AEM environment is cloned and the domain and IPs are changed, it is crucial to reconfigure

the Transport URI of both the flush and replication agents to ensure content activation works

correctly.

Here’s the step-by-step process to reconfigure these settings:

Access the AEM Tools Console: Log into your AEM instance and navigate to Tools > Deployment >

Replication.

Update Replication Agents:

Go to the "Agents on author" section.

Select each replication agent (usually named "default" or based on your custom setup).

Edit the agent configuration.

Update the Transport URI to reflect the new domain and IP address.

Save the configuration.

Update Flush Agents:

Navigate to the dispatcher flush agents.

Select each flush agent.

Edit the agent configuration.

Update the Transport URI with the new domain and IP address.

Save the configuration.

Test the Configuration: After updating the URIs, test the content activation process to ensure that the

replication and flushing mechanisms are working correctly with the new settings.

These steps ensure that the communication paths for content replication and cache flushing are

correctly established, thereby maintaining the integrity and functionality of content activation.

Reference:

AEM Replication Documentation

Dispatcher Configuration Documentation

The includeCommerce property is a boolean flag that indicates whether to include Commerce Core

Components in the project or not. If set to y, the command will generate a commerce module that

contains specific Commerce Core Components and their dependencies. These components can be

used to integrate AEM with Adobe Commerce platform or other commerce solutions. Reference:

https://experienceleague.adobe.com/docs/experience-manager-corecomponents/using/developing/archetype/using.html?lang=en#properties

https://experienceleague.adobe.com/docs/experience-manager-corecomponents/using/components/commerce.html?lang=en

A mock framework is a tool that allows creating mock objects that simulate the behavior of real

objects in a controlled way. A mock framework can be used in a unit test to inject the

EmployeeService dependency into the CalculationService and verify its interactions. This way, the

unit test can focus on testing the logic of the CalculationService without relying on the actual

implementation of the EmployeeService. Reference:

https://sling.apache.org/documentation/development/sling-testing-tools.html

https://wcm.io/testing/aem-mock/usage.html

To ensure that text pasted inside the Text component in AEM is stripped of all styling and formatting,

you need to override the RTE (Rich Text Editor) plugin implementation and change the default paste

behavior. The correct option to achieve this is defaultPasteMode=plaintext.

Steps to configure the RTE plugin for plain text pasting:

Locate the RTE Configuration: Find the existing configuration for the RTE or create a new one in the

/apps directory of your AEM project.

Modify the Plugin Configuration: Add or update the configuration to include the defaultPasteMode

parameter. The configuration might look something like this:

{

"jcr:primaryType": "nt:unstructured",

"features": "[text]",

"defaultPasteMode": "plaintext"

}

Apply the Configuration: Ensure that this configuration is applied to the Text component. This

typically involves updating the component dialog or design dialog to reference the updated RTE

configuration.

Test the Configuration: In the AEM author instance, open the page with the Text component and

paste text using CTRL+V. The pasted text should now be stripped of all styling and formatting,

adhering to the plaintext mode.

By setting defaultPasteMode to plaintext, you ensure that the RTE only accepts plain text input,

removing any formatting that might come from external sources.

Reference:

AEM Rich Text Editor (RTE) Documentation

Configuring the Rich Text Editor in AEM

To push a code fix into the current release candidate, the best practice is to cherry-pick the fix

commit into the release candidate branch. Cherry-picking allows you to apply specific changes from

one branch to another, ensuring that only the necessary fixes are included without introducing

unrelated changes.

Here’s how to cherry-pick a commit:

Identify the Commit: Locate the commit hash of the fix you need to apply. This can be found in your

version control system (e.g., Git).

Checkout the Release Candidate Branch:

git checkout release-candidate-branch

Cherry-pick the Commit:

git cherry-pick

Resolve Conflicts (if any): If there are conflicts, resolve them manually and then continue the cherry-

pick process:

git add

git cherry-pick --continue

 Test the Changes: Ensure that the changes are tested thoroughly in the release candidate

environment to confirm the fix works as expected.

 Push the Changes:

git push origin release-candidate-branch

Cherry-picking ensures that only the required changes are applied to the release candidate,

maintaining the stability and integrity of the codebase.

Reference:

Git Cherry-pick Documentation

Embedding client libraries is a technique that allows combining code from multiple client libraries

into a single file. This reduces the number of network requests and improves performance.

Embedding client libraries can be done by using the embed property of the cq:ClientLibraryFolder

node and specifying the categories of the client libraries to be embedded. Reference:

https://experienceleague.adobe.com/docs/experience-manager-cloudservice/content/implementing/developing/full-stack/clientlibs.html?lang=en#embed

https://experienceleague.adobe.com/docs/experience-manager65/developing/introduction/clientlibs.html?lang=en#embedded-files

The Apache Jackrabbit Oak External Login Module and Apache Jackrabbit Oak Default Sync Handler

are the two OSGi configurations that are required for LDAP integration in AEM. The External Login

Module defines how AEM connects to the LDAP server and authenticates users against it. The Default

Sync Handler defines how AEM synchronizes users and groups from the LDAP server to the

repository. Reference: https://experienceleague.adobe.com/docs/experience-manager65/administering/security/ldap-config.html?lang=en#ldap-integration

When building out a project using the most recent AEM Archetype, the ui.frontend module is

optional. The ui.frontend module is typically used for integrating front-end build processes, such as

those involving npm, Webpack, or other front-end tooling. If your project does not require such

front-end tooling, you can omit this module.

Here is a breakdown of the archetype modules:

it.launcher: This module is used for integration tests and is required if you need to run automated

tests as part of your build process.

ui.frontend: This module includes front-end tooling and build processes. It is optional and can be

omitted if your project does not involve complex front-end development.

ui.tests: This module includes unit and integration tests for the UI part of your AEM project. It is often

required for testing purposes.

ui.content: This module includes the content structures and initial content for your AEM project. It is

generally required to set up the content for your project.

Reference:

AEM Project Archetype

AEM Development Best Practices

The Apache Sling Logging Logger Configuration and Apache Sling Logging Writer Configuration are

the OSGi configurations that the developer should use to create a Logger and Writer pair for the

company’s application logging. The Logger Configuration defines the log level and the log file name

for a given logger name or category. The Writer Configuration defines the file size, number of files,

and file location for a given log file name. Reference:

https://experienceleague.adobe.com/docs/experience-manager65/deploying/configuring/configure-logging.html?lang=en#configuring-log-files