Tuesday 30 January 2018

Steps to migrate third party CMS website to AEM

AEM(Adobe Experience Manager) is getting more and more popular, due to its enterprise capability for managing content. There are cases where we need to migrate third party CMS site to AEM.
Some examples could be Drupal to AEM, Salesforce to AEM e.t.c.

Let us understand the common process of migration. I will take you through the steps to migrate any third party CMS websites to AEM.

The estimation part of AEM project migration is given in this link.

Below listed are the major steps in a migration project.
  • Analysing the current system with integration elements involved
  • Define content strategy
  • Define asset Strategy
  • Design the new system with integration
  • Migrate the content to new system
  • Test the new system

While migrating a site, we should have an understanding of the current site CMS; then map it with related elements in AEM.

For eg. A site made in Wordpress will have the content stored in a location and images, videos, pdfs in some repository. Understanding the layers in both CMS plays a big role in delivering a successful migration.

Setting up the environment
To ensure a smooth migration, we need an AEM DEV environment ready where we can quickly move the data from current system. The minimal DEV environment configuration could be just an author instance with 2 to 4 publish instances and a dispatcher.

Strategy to Migrate Content 
Below steps to be carried out for a smooth content migration
  •     Content Evaluation
  •     Cleaning up/ Sanitizing the content    
  •     Content Mapping - Organizing the content hierarchy
  •     Design
               - Based on the analysis of existing system, we need to design a solution which has proper
               digital asset structure, metadata, tagging, client library, target AEM templates and
  •     Content Migration - There are many ways to do this.
              - Manual Migration(When the content in the old system is not structured)
              - Automation Migration(When the content in the old system is structured)
              - Hybrid Migration(When there is structured and unstructured content in the old system)
  •     Content Verification
Assets Strategy
Assets plays an important role in any CMS. We need to carry out,
  •     Asset migration and categorization
  •     Extract and update metadata from old system to AEM
Getting into action
Based on the design we need to have templates, components created.

We need to identify the tools/ methods available to export data from current system to AEM once the templates and components are ready. AEM follows hybrid way of content migration in almost all scenarios.

REST API for migration
Some of the CMS system provides a REST API layer where the content is exposed. We can invoke them in AEM and get those data exported into AEM directly.

To achieve this, our migration scripts should have,    
   -  Map the templates from current system to AEM
   -  Map the components from current system to AEM

 Once the content and assets are migrated, we can start manual testing on the pages by creating new pages as per design.

How do we estimate an AEM Migration project?
  •     List templates
  •     Estimate the templates
  •     List components
  •     Estimate the components
  •     Analyze the current CMS content ( XML/JSON Data)
  •     Estimate the scripts for each components (XML/JSON Data to AEM Component)
  •     Estimate asset migration and categorization(Extract and update metadata for digital assets on AEM)
  •     Estimate Analytics part
  •     Estimate Integration (Login, Authorization, Search)
  •     Estimate Workflow creation

 Need help?
If any one facing trouble in identifying the strategy, let us know through the comments section.


Subscribe Our YouTube Channel Here.

Read More:
AEM Integration with DOJO
Analytics Integration with AEM
WCM Use class
AngularJS with AEM
New features in AEM 6.3
HTL Tips


Friday 12 January 2018

Rule Engine Integration with AEM

We have been integrating various applications with Adobe experience Manager. Some examples are search, social integration etc.

There are cases where we need to integrate Java based rule engines (For e.g Drools, IBM ODM, JRule etc.). Let us see how we can integrate them.

What is rule engine?
Rule engines are used to provide business based decisions while processing a data. For e.g., when a loan is to be processed based on a lenders salary, and many parameters, we can have a rule engine integrated with AEM.

How can we achieve this?
To achieve this we may need multiple layers as shown.

Business rule layer
As seen in diagram, The rule developer (skill set is prior working knowledge on rule engines) develops the rules, test them and deploy the rules. These rules are created on a rule engine.

The rule developed resides in a rule repository (back-end of the rule engine).

The Business professional (Skill set is business understanding of rules) who creates the rules, will have a UI access of rule engine and based on the rule developers rules, he creates new rules to satisfy a business condition.

Web service layer.
Here the Java is deployed on any server. The Java code will perform activities of invoking the Rule engine and process rules;  this rules will be handed over to AEM through an https layer in xml or json format.

Any questions, let us know through the comment section?

Read More

Thursday 4 January 2018

A program managers thoughts on site migration to AEM

Let us see how a project manager should think before he starts with a site migration to AEM. What things he needs to consider? The history of AEM has seen thousands of migration to AEM. But how many were successful? How many of them were cost effective? Let us do an analysis.

Planning before he starts.
There are multiple planning sessions to be done before actual migration starts.

Cost/ Budget Planning

The PM should think of the total cost estimated for the complete implementation. This includes initial setup, UI development/ UI changes, developing new feature additions, QA tools, platforms, integration costs, licensing costs etc.

Technical Planning

PM should get a clarity on the total number of sites, UX changes, data conversions, system integration, any analytical and personalization items.

Team Planning

Right mix of technology team is necessary for any development. For an AEM, the considerations should be the back-end, front-end capabilities of a developer including various integration through web-service layer, analytics, search etc.

Implementation Planning

Define the correct time frame with a proper sprint planning. Include the team in discussions is necessary for this.

Integration planning

Third party integration can be complex task when the developers are not aware of it. Always try to add a developer who knows the various integration like search, analytics, web-service etc.

QA Planning
Define a QA Strategy and ensure the test cases are prepared well before the actual development.

Deployment Planning

Ensure the DEV and QA work together to make the deployment process success. Define a deployment strategy considering latest tools and technologies available.

Set a well defined communication channel for the deployment process which makes the deployment smooth and success. Ensure the roll back and disaster recovery are considered in planning.

Post deployment planning

Regular Monitoring of performance and any backups are to be planned as part of this.

He or she should also consider the partnerships for AEM implementation, Adobe cloud solutions and infrastructure in course of time. Let me know your migration experiences through comments section.

Videos on AEM & Persistence
AEM Persistence TarMk & MongoMK Series 1
AEM Persistence TarMk & MongoMK Series 2  AEM with TarMK
AEM Persistence TarMk & MongoMK Series 3  AEM with MongoMK
AEM Persistence TarMk & MongoMK Series 4  TarMK Vs MongoMK

Read More
Rule Engine integration with AEM

Tuesday 12 December 2017

AEM With MongoMK - Options

We can have 2 types of MongoMK configurations for AEM Oak Clusters.

1) Failover for High Availability in a Single Datacenter

Here a primary MongoDB will be used for Read/Write. So the multiple Oak instances accessing a MongoDB replica set within a single data center.
This setup helps for high availability and redundancy in the event of a hardware or network failure

Major advantages are,

  • Scalability
  • High availability
  • redundancy
  • automated failover of data layer

One of the disadvantage of this setup is, there are some performance issues when compared with TarMK.

2) Failover Across Multiple Datacenters

Here multiple Data Centers are involved. Primary MongoDB will be replicated to secondary systems. So multiple Oak instances accessing a MongoDB replica set across multiple data centers. In this configuration, MongoDB replication provides the same high availability and redundancy as comapared to previous configuration but it also includes the ability to handle a data center outage.

Major advantages are,
  • Scalability
  • High availability
  • Redundancy
  • Automated failover of data layer

Final notes:
Always remember this. Adobe highly recommends TarMK as the default persistence technology for both the AEM Author and Publish instances, except in the use cases outlined here.

Foot notes:
What is MongoDB Arbiter. Why we need an Arbiter?

In software the CAP theorem says, "If there are equal number of servers on either side of the partition, the database cannot maintain CAP (Consistency, Availability, and Partition tolerance). An Arbiter is specifically designed to create an -imbalance- or majority on one side so that a primary can be elected in this case."

As per MongoDB site(https://docs.mongodb.com/v3.4/tutorial/add-replica-set-arbiter/) "Arbiters are mongod instances that are part of a replica set but do not hold data. Arbiters participate in elections in order to break ties. If a replica set has an even number of members, add an arbiter. Arbiters have minimal resource requirements and do not require dedicated hardware. You can deploy an arbiter on an application server or a monitoring host."

If you get an even number of nodes on both sides, MongoDB will not elect a primary and your set will not accept writes.

Videos on AEM & Persistence
AEM Persistence TarMk & MongoMK Series 1
AEM Persistence TarMk & MongoMK Series 2  AEM with TarMK
AEM Persistence TarMk & MongoMK Series 3  AEM with MongoMK
AEM Persistence TarMk & MongoMK Series 4  TarMK Vs MongoMK

Read More
Rule Engine integration with AEM


Subscribe Our YouTube Channel Here.

AEM With TarMK - Options

We can have 3 types of TarMK configurations for AEM Oak Clusters.

1) Single TarMK Instance

A single TarMK instance runs on a single server. For Author instances, this is the default deployment method.

Major advantages are,
  • Simple
  • Easy to maintain
  • Better performance

The disadvantages:
  • Scalability is within the limits of server capacity
  • No failover capacity

2) TarMK Cold Standby

Here single TarMK instance acts as the primary instance & the repository from the primary is replicated to a standby, which acts as failover system.

Major advantages are,
  • Simplicity
  • Maintainability
  • Performance
  • Failover

The disadvantages:
  • Scalability is within the limits of server capacity
  • There is a manual task involved in detecting failure and failover to start working

3) TarMK Farm

Multiple Oak instances are involved and each Oak instance is running with one TarMK. All TarMK repositories are not in sync
TarMK Farm is the default deployment for publish environments.

Major advantages are,
  • Performance
  • Scalability for read access
  • Failover

Final notes:
Always remember this. Adobe highly recommends TarMK as the default persistence technology for both the AEM Author and Publish instances, except in the use cases outlined here.
Videos on AEM & Persistence
AEM Persistence TarMk & MongoMK Series 1
AEM Persistence TarMk & MongoMK Series 2  AEM with TarMK
AEM Persistence TarMk & MongoMK Series 3  AEM with MongoMK
AEM Persistence TarMk & MongoMK Series 4  TarMK Vs MongoMK

Read More
Rule Engine integration with AEM

Monday 11 December 2017

AEM Microkernels - MongoMK vs TarMK

Latest AEM comes with Oak storage. Oak(Apache Jackrabbit Product) is a new JCR implementation with a completely new internal architecture.
There are two options for the AEM persistence layer back-end used by Oak : TarMK and MongoMK. Let us see the scenarios where each one is feasible and what are all the main differences.

TarMK Vs MongoMK

Adobe recommendation says we must consider MongoMK when we come across below metrics

  • Number of named users connected in a day: in the thousands or more.
  • Number of concurrent users: in the hundreds or more.
  • Volume of asset ingestion per day: in hundreds of thousands or more.
  • Volume of page edits per day: in hundreds of thousands or more (including automated updates via Multi Site Manager or news feed ingestion for example).
  • Volume of searches per day: in tens of thousands or more.

Prerequisites for considering MongoMK as persistence layer.

Once we identified MongoMK as persistence layer below factors are mandatory.
1. Ensure involving MongoDB architects/ Adobe MongoDB Specialists for designing the solution.
2. AEM Developers should work hand in hand with MongoDB developers to implement a successful solution.
3. For a better turn around time, always ensure to have Mongo DB Maintenance License.
4. Ensure the proposed design is validated by an Adobe Certified Experience Manager Architect to avoid any future issues.

Advantages of MongoMK in Authroing Instances

Horizontal Scalability Support – MongoMK supports multiple AEM instances share the same MongoDB instance.
Efficient Data Replication – MongoMK effectively delegates replication functionality to the MongoDB, which has mature model to maintain replica sets. Major advantage here is MongoDB replicas and AEM instances are independent each other.
Distributed Authoring Team Support – Content authoring across different geographical regions are supported by Mongo MK. At first data gets saved int the primary MongoDB and then gets replicated to the secondary DB replica sets.
Automated Failover Recovery – MongoDB supports automated failover. The efficient configuration can helps in automated system recovery from data center failure.

Advantages of TarMK in Publish Instances
Automated Failover Recovery - Efficient configuration of TarMK provides Automated recovery during system failures.
24/7 availability: Code changes are released on one data center, validate the release and then release it to the other data center. TarMK supports such rolling release efficiently.
Efficent upgrades: AEM Upgrades and patch fixes needs rolling release, thus TarMK provides better support.

Huge Data considerations: Which one to use?
If most of the Data in (TB) are binaries, TarMK is a good fit, and a data store on the file system. If the data (in multiple TB) is structured content / nodes, MongoMK is the better choice because we can shard the data.

Sharding can be found at MongoDB Documentation : Overview / Adobe Experience Manager 6.0 / Deploying and Maintaining / or The MongoDB Manual.

Final Notes:
TarMK is optimized for single node performance whereas MongoMK is designed for scalability and clustered deployments. Another factor is the volume of the data. Also keep in mind MongoMK setup/configuration/maintenance requires additional knowledge about MongoDB.

In my next blog I will be talking about MongoMK Recommended Deployments(AEM on MongoDB )
Videos on AEM & Persistence
AEM Persistence TarMk & MongoMK Series 1
AEM Persistence TarMk & MongoMK Series 2  AEM with TarMK
AEM Persistence TarMk & MongoMK Series 3  AEM with MongoMK
AEM Persistence TarMk & MongoMK Series 4  TarMK Vs MongoMK

Read More
Rule Engine integration with AEM


Subscribe Our YouTube Channel Here.

Friday 1 December 2017

Hybrid Content Management(HCM) & AEM

Hybrid Content Management system integrates cloud storage, content management services and/or features with on-premises content management software for store, share and manage enterprise content. Some of the decision factors which involved for selection of Hybrid Content Management are cost, mobility and new features.

Importance of Hybrid Content Management
Some of the recent data analyst group study revealed that within few years, majority of enterprises will manage the content using a hybrid storage model. This showcases the importance of new Hybrid AEM designs.

Cloud file sharing is one of the factor that can drive hybrid CMS demand with AEM. Enterprise file sync and share services (EFSS) examples are Box, Dropbox, Citrix ShareFile, Office 365, G Suite.

Majority of companies are moving to a cost effective cloud based system, but factors of security are still a concern and some of the federal data laws asks for an on-premise storage(compliance, performance related, and security restrictions). Hybrid approach of synchronizing such existing on-premises storage with new EFSS services is ideal in this case, this shows the importance of Hybrid Content Management system.

Some of the laws which asks for a secure data system:
Health Insurance Portability and Accountability Act (HIPAA), the Sarbanes-Oxley Act (SOX), the U.S. Securities and Exchange Commission (SEC) and other compliances.

Hybrid cloud services(HCS)
Hybrid cloud services, a bridge between on-premise storage infrastructure and the cloud of choice, allowing customers to scale cloud storage as needed, use a blend of private and public clouds, and maintain control of their data with simple management tools. New AEM designs asks for this type of service integrations.

Example for HCS system: NetApp's Data ONTAP - storage operating system, can be used to connect Amazon S3 or EVS storage.

When we migrate the applications or data to a new system , common set of problem arises such as disruption of business operations, data loss and transitioning users to new processes.

When platforms are synchronized, content is automatically populated in the new system. Through Synchronization, users can still securely collaborate with external parties and across multiple devices. Synchronization helps to sync EFSS services to their existing platforms while preserving past investments and keeping their IT infrastructure intact.

Think before you act

There are some factors to be considered before we sync up AEM with hybrid systems. Our design should be based on the out come of below considerations.

1) Ensure  bi-directional sync : When you plug AEM into a hybrid system, ensure a bi-directional sync, this confirms both platforms are up-to-date.

2) Define an inter-operability :
Consider synchronization of user permissions, document versioning and metadata across systems so that the connection is seamless, secure and transparent to end-users.

3) Think Investments done & reduce cost :
Organization might have done huge investments on the existing system already. So consider this while defining the hybrid approach. Based on usage, sync only their most used active content, while keeping old data and archived information within premise & decommission aging servers.

4) Study the system
Do an impact study on the existing system and their rules like metadata, permission, user accounts management etc. Based on the study define the new hybrid approach.


Let us know through the comment section