A data layer in general consists of a JavaScript client side event driven data store that can be used on webpages, to collect data about what the visitors experience on the web page & to communicate this data to digital analytics and reporting servers(e.g. Adobe analytics or Adobe target)
What does it do?
The Adobe client data layer is a java script store for data and events happening on a page within the scope of a request. It reduce the effort to instrument websites by providing a standardized method to expose and access any kind of data for any script.
It provides API to,
1) Register data that is to be merged into the data layer state 2) Trigger events that relate to the data stored in the data layer 3) Get the current data layer state of all merged data 4) Register listeners that are called for specific events or data changes
Steps to set up a data layer
1) Loading the data layer script 2) Declare the adobeDatalayer array
Once above steps has been configred, we can work on various push menthods( Push the Data object/ Push Event Object/Push functions) Events (registering & unregistering)
The AEM Core Components are availed with Adobe Client Data Layer(Disabled by default - we need to enable it if we have plans to use it).
To push the data from website to Analytics, we need Adobe Client Data Layer extension & Adobe Analytics, Core Extensions to be configured.
Some of the use cases 1) Retrieving Analytics data & using it for Personalization 2) Trigger an update event on page when the stock market value changes
Project Firefly is a run time framework for building 3rd party cloud native applications that extend the functionality of Adobe experience Platform(AEP) and Adobe experience cloud.
It provides everything we need to develop an application, even this is extendable - which grows with the needs.
What it contains?
Adobe I/O runtime - which is a server-less foundation for running 3rd party custom code on Adobe infra. It provides scaling in /out etc.
CLI & SDK - Enables local development, CI/CD. Streamlined way for developers to interact with core Adobe services and automated process.
Spectrum(Adobes design language) UI Framework - A React based UI framework for creating experiences that feels native comfort
Custom events - Publish and consume custom events with support for webhooks and journaling
Cloud services - a range of services for running managing and optimizing custom digital experiences.(Cloud storage, blob storage,CDN etc)
Set of Developer tools - Has UX modeling tools, IDE plugins(code completion) and other tools to aid in testing, debugging and deploying custom experiences.
Whom it will be helpful?
System integration developers - who are typically specialized on integrating and extending Adobe enterprise solutions(AEM, Campaign, Marketo, Magento etc)
Enterprise developers - who works with enterprise customers to create business sue case demos etc.
What is the difference between I/O Runtime & project Firefly
Project Firefly is a complete app framework to build custom cloud native Adobe Apps, where in Adobe I/O runtime is a server-less platform for running custom code.
Project Firefly is built on top of Adobe I/O Runtime.
What are all the features of Project Firefly?
Storage services - We get all relevant storage services to work with a 3rd party app
Debugging - Provides various debugging options
Logging - Provides evident logging mechanisms
Action templates - Project starter templates
UI templates - React spectrum templates to help developers
Security - Firefly is highly secured
Some of the typical use cases of Firefly 1) Asset migration in AEM(External DAM to AEM) which are in Gigabytes(bulk uploads) - the task can be offloaded to a headless firefly app that uses content fragment API, so that normal AEM tasks run without issues.
2) Offloading analytics data to Firefly - Firefly can pull the data from Adobe analytics and save it into DB or make it available for Target
3) Data ingestion monitoring - There are cases where we need to import Huge data into AEP and there could be errors in the process. We can use Firefly to monitor the Adobe i/O events and trigger the other system when something goes wrong to take corrective actions
4) Campaign stand dashboard for monitoring- unlike campaign classic, campaign standard doesnt provide a dashboard to monitor workflows. Using Firefly, we can create SPA that display the status of all workflows in Campaign standard - which helps marketers
Cloud Readiness Analyzer report is built using the output of the Adobe Experience Manager (AEM) Pattern Detector)
This gives high-level understanding of general upgrade readiness.
Helps accelerate the processes of assessing readiness to move from an existing Adobe Experience Manager (AEM) deployment to AEM as a Cloud Service.
This tool generates a report that identifies areas of potential refactoring, which is the first step in the transition journey to AEM as a Cloud Service.
CRA is supported on AEM instances with version 6.1 and above (CRA is supported on AEM instances with version 6.1 and above)
CRA can run on any environment, but it is preferred to have it run on a Stage (Author) environment or clone of the production Author environment
CRA can be downloaded as zip and uploaded to AEM instance via Package Manager
Notes: CRA utilizes a system service user account named repository-reader-service(default available in AEM 6.2 and later, For AEM 6.1 we will have to manually create it) to execute the Pattern Detector. Version 6.3 and later we can access CRA via tools -> Operations -> Cloud Readiness Analyzer. AEM 6.2 prvides a link that generates and downloads the CSV report. and 6.1 the tool is not functional and only the HTTP interface may be used
Analyzer report - includes the following categories:
Application functionality that must be refactored
Repository items that must be moved to a supported location
Legacy user interface dialogs and components that must be modernized
Deployment and configuration issues
AEM 6.x features that have been replaced by new functionality or that are currently not supported on AEM as a Cloud Service
The report generation time required is highly dependent on the size and nature of the AEM repository content, the AEM version, and other factors
-----------
Content Transfer Tool CTT
This tool helps to move existing content over from a source AEM instance (on-premise or AMS) to the target AEM Cloud Service instance. We can use this tool to transfer principals (users or groups) automatically
2 Steps involved
Extraction- extract the source content from AEM and keeping a temporary place called 'migration set'(cloud storage area provided by Adobe - inactive for more than 30 days it gets deleted )
Ingestion - ingesting content from the migration set into the target Cloud Service instance
**Content Transfer Tool creates a local copy of the repository that is later uploaded to the migration set. So ensure enough space is available in local/source AEM
Minimum req for CTT is AEM 6.3 + and JAVA 8. On lower env upgrade your content repository to AEM 6.5 first
author AEM will be unavailable during the whole ingestion process.
The recommended upper limit for the repository size is 20 Gb
CTT can be downloaded as zip and uploaded to AEM instance via Package Manager
Access it from navigate to tools -> Operations -> Content Transfer
1) Which are all the environments available as part of AEM as a cloud service?
Four types of environments available with AEM as a Cloud Service:
Production environment - for the business practitioners
Stage environment : performance and quality tests before changes to the application are pushed to the production
Development environment - developers to implement AEM applications
Demonstration environment : Training , demos, pocs etc - is simplified to a single author node, all others having min 2 author nodes
2) Which are all the types of programs available as part of AEM as a cloud service?
Two types of programs are initially available for AEM as a Cloud Service:
AEM Cloud Sites Service
AEM Cloud Assets Service
3) What we get as part of AEM as a cloud license?
When we get the license we will have
Code repository (Git) 1
Baseline image (Sites or Assets) 1
Stage and production environment set (1:1) 0 or 1
Non-production environments (development or demonstration) 0 to N
Pipeline for each environment 0 or 1
**Note:* The author tier will contain all Sites and Assets functionality for all programs, but the Assets programs will not have a publish tier by default
4) What are all the changes in Author, Publish & Replication in AEM as a Cloud Service
Author and publish features:
Both author and publish tiers always accessed via a load balancer. But publish tier, a Continuous Delivery Network (CDN) is always available.
The method of author to publish replication has upgraded now. AEM as a Cloud Service Sling Content Distribution which allows one to distribute Sling resources between different Sling instances.{The API works at path level and the distribution agents basically enable distribution of specific paths between instances.}This uses a pipeline service run on Adobe I/O, which is external to AEM.
Replication changes - The replication agents used in previous versions of AEM are no longer used or provided, which might impact the following areas of existing AEM projects:
Custom workflows that push content to replication agents of preview servers for example.
Customization to replication agents to transform content
Using Reverse Replication to bring content from publish back to author
5) Do we have all types of runmodes as in previous version of AEM?
The answer is NO.
Run modes that are defined typically include the service (author and publish) and the environment (dev, stage, prod).
Pattern <service>.<environment_type>
Fr eg: author.dev or publish.prod
The supported runmode configurations in AEM as a cloud service are:
config ( The default, applies to all AEM Services )
config.author ( Applies to all AEM Author service )
config.author.dev ( Applies to AEM Dev Author service )
config.author.stage ( Applies to AEM Staging Author service )
config.author.prod ( Applies to AEM Production Author service )
config.publish ( Applies to AEM Publish service )
config.publish.dev ( Applies to AEM Dev Publish service )
config.publish.stage ( Applies to AEM Staging Publish service )
config.publish.prod ( Applies to AEM Production Publish service )
config.dev (*Applies to AEM Dev services)
config.stage (*Applies to AEM Staging services)
config.prod (*Applies to AEM Production services)
** OSGI configuration that has the most matching runmodes is used.
6) How do we do local development when AEM is in cloud?
For local development: The following artifacts are made available to the developers:
The AEM as a Cloud Service QuickStart: a .jar based, standalone installer of the latest AEM code base, with the same functional and API surface.
The AEM as a Cloud Service Dispatcher SDK: an image-based process for testing and validating Dispatcher configurations locally
[* The quickstart is a simple author environment where the majority of the extensions can be developed and tested - does not allow for all AEM Sites and AEM Assets functionalities]
7. What are all some of the important terminologies which we should be aware of?
New important terminologies w.r.t. cloud
AEM as a Cloud Service - The cloud-native way of leveraging the AEM applications
AEM Image - A deployable artifact that contains the AEM product code together with the customer code.
Golden Master - The AEM publish tier.
Orchestration Engine - AEM as a Cloud Service uses an orchestration engine to ensure that all author and publish services are scaling as and when needed.
Asset microservices - Cloud-based digital asset processing services that cater to various asset processing use cases, such as rendition generation, PDF processions, subasset handling, text extraction etc.
8) What are all the types of users and roles available in AEM as a cloud?
Users & Roles
Cloud Manager currently defines four roles for users which govern the availability of specific features:
Business Owner - defining KPIs, approving production deployments
Developer - Develops and tests custom application code , do git operations
* There is a role 'Content Author' who does not interact with Cloud Manager. May use Cloud Manager Program Switcher (having navigated from Experience Cloud) to access AEM
9) How do we upgrade from existing AEM version to Cloud Service
> Planning Access cloud service readiness - determine areas that will require refactoring to be compatible with AEM as a Cloud Service.(Source code Vs deprecated features, New path structure w.r.t AEM as cloud). Then estimate the plan. Review resource planning - identify resources, create a team, and map out roles and responsibilities Establish KPIs - Define KPIs to help your team focus on what matters the most.
> Execution - onboad -familiarize & deploy the code to cloud service - Integrate - the Git and deploy the code, content transfer, code refactor( Use tools where ever possible For eg: Asset Workflow Migration Tool, Dispatcher Converter, Modernization Tools. ) - Configure - user roles and other things on Admin console of cloud manager
> Post Go-Love clean-up of temporary files, review best practices for continuous development manage logs
10) What are all the options available to troubleshoot anything in AEM as a cloud service?
The following tools are available to troubleshoot AEM as a Cloud Service environments:
Developer Console
CRX/DE Lite
Managing Logs
11) What does the SDK For Local Development contains in AEM as a Cloud Service?
SDK is comprised of the following artifacts
Quickstart Jar - The AEM runtime
Java API Jar - all allowed Java APIs that can be used to develop against AEM as as Cloud Service(Previously known as Uber Jar)
Javadoc Jar - The javadocs for the above JAR
Dispatcher Tools - set of tools used to develop against Dispatcher locally
12) How does the Maintenance tasks became more users friendly now?
With AEM as a Cloud Service, the need for customers to configure the operational properties of maintenance tasks is minimal. Customers can focus their resources on application-level concerns, leaving the infrastructure operations to Adobe.
Below given customer owned the configuration
Ad-hoc Task Purge
Workflow Purge
Project Purge
13) Can you explain mutable vs immutable in AEM as a Cloud Service?
Mutable Vs immutable
/apps and /libs are considered immutable areas of AEM as they cannot be changed (create, update, delete) after AEM starts (i.e. at runtime). Any attempt to change an immutable area at runtime will fail.
Everything else in the repository, /content , /conf , /var , /home , /etc , /oak:index , /system , /tmp , etc. are all mutable areas, meaning they can be changed at runtime.
Oak indexes are mutable at run time
* /oak:index configurations are part of the Code Package and not part of the Content Package
What is Content-Disposition? According to developer guide from Mozilla : "In a regular HTTP response, the Content-Disposition response header is a header indicating if the content is expected to be displayed inline in the browser, that is, as a Web page or as part of a Web page, or as an attachment, that is downloaded and saved locally.
Content disposition filter is a security feature against XSS attacks on SVG files.
Different values for the Content-Disposition headers
inline (This is the default value - indicating it can be displayed inside the Web page, or as the Web page)
attachment (which indicates it should be downloaded).
In AEM how the content disposition supports? Usually people might have complained in AEM websites, the pdf or an image which is supposed to be downloaded are getting open in new tab(usually on dispatcher URL).
In AEM there is a configuration in OSGI console - 'org.apache.sling.security.impl.ContentDispositionFilter'
In AEM we can configure Content Disposition Filter in multiple ways
Content Disposition Paths This option helps us to configure a list of paths where the content disposition filter will be applied followed by a list of mime-types to exclude on that path.
Some examples given below:
/content/*:image/png This will apply the filter to every node in /content except png/content
/*:image/png,image/svg+xml - This will apply the filter to every node in /content except svg images
/content/*:audio/mpeg - For the audio of type mpeg
/content/*:application/pdf - For pdf files to download instead of opening in other tab
Ensure the path must be an absolute path and can contain a wildcard ('*') at the end, to match every resource path with the given path prefix.
Excluded Resource Paths We can exclude a set of paths to be excluded, each resource path must be given as absolute and fully qualified path. In ths case prefix matching/wildcards are not supported. Enable For All Resource Paths
This feature flag controls enablement of the filter for all paths, except for the excluded paths defined by Excluded Resource Paths. If we set this to true, we are ignoring all content disposition paths (resource paths which has a property named 'jcr:data' or 'jcr:content jcr:data').
How to display pdf in new tab when clicking on link without download?
1.The server is sending the PDF without the correct Content-Type header (application/pdf) so the browser doesn't know how render it inline.
2.The server is sending a Content-Disposition header to
recommend that the browser download it instead of rendering it inline.
3.The browser doesn't have any support for rendering PDFs inline.
The first two of these can
only be solved by changing the response headers from the server.
The last can only be solved by
changing the browser or installing a plugin that supports PDFs.
Path: /dispatcher-cloud/src/conf.d/rewrites/
File: rewrite.rules
##content-dispositionruleforPDF
<LocationMatch"\.(?i:pdf)$">
ForceTypeapplication/pdf
HeadersetContent-Dispositioninline
</LocationMatch>
The Content Disposition details can be found in url
The new 'AEM Assets as a cloud service' which is part of AEM as a cloud (platform as a service solution) provides Digital Asset Management capabilities(storage, managing metadata online, versioning, upload and download) with below extended features.
Based on asset microservices(asset ingestion and processing).
Smart capabilities, such as AI/ML
Highly scalable
Always current
Always available
Auto scaled, deployed and monitored
In older AEM all the asset operations happened at AEM Author instance - which consumes considerable CPU, memory, and I/O resource.Asset processing and storage requirements demand resources which in turn create performance issues impact authoring and browsing experience of end users.
A High-level Architecture of Assets as a Cloud Service can be seen below
The generic steps followed in sequence are,
Clients send an upload request - then start uploading binary directly to cloud
Once the direct upload is completed, the client notifies AEM
Now the AEM sends a processing request to Assets Microservice
The
asset microservice now start processing the asset (based on the
rendition request from AEM) - asset microservice runs relevant
microservices for this. They access the binary from cloud and processed
assets are also placed in binary cloud.
Now assets microservice notifies AEM that renditions are available.
Assets as a Cloud Service Vs AEM Asset upload on premise
Assets as a Cloud Service uses direct binary access principle for upload and download - Previously Assets were uploaded directly to AEM author instance for processing.
Assets as a Cloud Service uses 'asset microservices' for asset processing, which is external to AEM - But in older AEM versions, all process happened within AEM.
In Assets as a Cloud Service DAM Asset Update Not available [ asset microservices provide a scalable, readily available service that covers most of the default asset processing (renditions, metadata extraction, text extraction for indexing)]. But in older AEM we had DAM Asset Update workflow as default.
Assets as a Cloud Service comes with post-processing workflows which can be used or customizations(where additional processing of assets is required that cannot be achieved using the processing profiles) -In older AEM we had default + customized workflow steps (Even though it looks as an advantage it had used AEM for all processing).
In Assets as a Cloud Service the standard Asset upload interface is the Touch-enabled UI - In older version Classic UI was available.
In Assets as a Cloud Service only the new upload APIs are supported -The older AEM Assets HTTP API(AEM 6.5), AssetManager Java API, is deprecated now Advantages of new cloud
The uploaded binaries do not go through AEM, which is now simply coordinating the upload process with the binary cloud storage configured for the deployment. finally clients get direct access to them to carry out their work. This minimizes the load on networks and duplication of binaries stored.
Binary cloud storage is fronted by a Content Delivery Network (CDN, Edge Network), which brings the upload endpoint closer to the client, helping to improve upload performance and user experience, especially for distributed teams uploading assets
More scalable and performant handling of asset uploads.
Ways of uploading Assets to Assets as a Cloud Service Upload using web interface, Adobe Asset Link, AEM desktop app or custom applications which uses the new HTTP API.
Post-processing workflows There are cases where we need additional processing to be done, which are not done by asset microservices(For eg. Generating a rendition which requires an integration with other application), additional post-processing workflows can be added to the configuration.
Post-processing workflows, once configured, are automatically executed by AEM after the microservices processing finishes. There is no need to add workflow launchers manually to trigger them.
Some examples for Post Processing workflow use cases are:
Custom workflow steps to process assets.
Additional processing done by external services.
Integrations to add metadata or properties to assets from external systems
How to create Post - Processing Workflows: Steps involved
Create one or more workflow models. - they are of regular AEM workflow models
Add specific workflow steps to these models.
Add 'DAM Update Asset Workflow Completed' Process step at the end(To inform AEM once the processing is done)
Create a configuration for the Custom Workflow Runner Service(configuration of an OSGi service) - This ensures the execution of a post-processing workflow model either by a path (folder location) or by a regular expression.
Supported File Formats
Adobe formats - AI, COLLAGE, DN, IDEAS, INDD, INDT, PDF, PROTO, PSB, PSD, XD Imaging file formats - BMP, EPS, GIF, JPEG, PNG, SVG, TIFF Image formats in Dynamic Media - PNG, GIF, TIFF, JPEG, BMP, PSD , EPS, PICT 3D formats - DN, gLB, gLTF, OBJ, STL, USDz Camera
Raw file formats - 3FR, ARW, CR2, CR3, CRW, DCR, DNG, ERF, FFF, GPR,
IIQ, KDC, MEF, MFW, MOS, MRW, NEF, NRW, ORF, PEF, RAF, RAW, RW2, RWL,
SRF, SRW, X3F Document formats - PDF,DOCX,DOC,PPTX,PPT, XLSX,XLS,ODF,OFG,ODM,ODP,ODS,ODT,EPUB,HTML,PS,RTF,TXT,XML Document formats in Dynamic Media - AI, PDF, INDD Video formats - 3G2,3GP,AVI,DIVX,F4V,FLV,M2T,M2TS,M2V,M4V,MKV,MOV,MP4,MPEG,MPG,MTS,OGV,QT,R3D,SWF,WEBM,WMV Video
formats in Dynamic Media for transcoding - MP4,MOV, QT,FLV,
F4V,WMV,MPG, VOB, M2V, MP2,M4V,AVI,WebM,OGV, OGG,MXF,MTS,MKV,R3D,
RM,RAM, RM,FLAC,MJ2, Audio formats - AIF, ASF, M4A, MP3, WAV, and WMA
