Venia Code with AEM SDK and Magento

 

In last blog we have setup AEM SDK with CIF add-on in AEM author instance. Now its time to deploy Venia ecommerce project.

Prerequisites:

1. AEM as a Cloud Service SDK

2. Java 11

3. Node.js

4. npm

5. Magento Instance URL 

Follow below steps to deploy existing project on AEM author:

1. Clone aem-cif-guides-venia project

git clone https://github.com/adobe/aem-cif-guides-venia.git

2. Comment dispatcher profile from root pom.xml ( not required as of now)

3. Go to Project directory and run below command to deploy code on AEM author:

4. Once the project is installed in AEM , traverse to http://localhost:4502/commerce.html or go to

http://localhost:4502/aem/start.html > Commerce>

5. Below is the error that shows up when you open the console.

This is because our AEM instance can’t access the Cross origin graphQL proxy endpoint of Magento.

6. To setup proxy, run below command:

npx local-cors-proxy --proxyUrl http://localhost/magento2 --port 3000 --proxyPartial ""

If you have already run this command as part of previous blog then skip this step.

7. Now go to http://localhost:4502/aem/start.html 

Tools > Cloud services > CIF Configuration

Click Properties

Add below configuration:

• GraphQL point: default( by default selected)
• Store view: default
• GraphQL query path : http://localhost:3000/graphql
• language: English
• Root category Id: 2

Click Save & Close.

8. Go to http://localhost:4502/aem/start.html > commerce>

or directly http://localhost:4502/commerce.html/browse

you can see Viena Code is coming in commerce 

Click on viena, all products gets loaded

And graphQL query is

Happy Coding!!!

AEM Commerce As Cloud Service with CIF Add-On

 

In this post we will discuss how to setup the AEM commerce as a cloud service with CIF add-on.

 

Setup of AEM commerce as a cloud service :

 A local development environment is recommended to work with CIF projects and how to setup one is explained below:

 

Prerequisites:

Some of the prerequisites for the setup are :

1. AEM as a Cloud Service SDK

2. Java 11

3. Node.js

4. npm

5. Magento Instance URL

 

First of all , the latest CIF add-on should be downloaded from the Software Distribution portal. It is a zip file which contains the respective far file as add-ons for author and publish instance.

Now follow the steps below :

 

1. Make sure you have the latest AEM as a cloud service SDK.

2. Unpack the jar by running java -jar <jar_name> -unpack in the command line to create a quickstart folder.

3. Once the quickstart folder has been created , go inside it and create a folder named install.

4. Unzip the CIF add-on package file and copy the correct .far file in the install folder of the relative instance you are planning to run i.e. author .far file for author-4502 instance and publish .far for publish-4503 .

5. Create a local environment variable named COMMERCE_ENDPOINT holding the Magento GraphQL endpoint.

I have installed my Magento instance on my local machine and it is running on:

http://localhost/magento2/admin

In Windows : set COMMERCE_ENDPOINT=<magento_endpoint_url>/graphql

In MAC : export COMMERCE_ENDPOINT=<magento_endpoint_url>/graphql

Using echo, you can check your COMMERCE_ENDPOINT value

6. Now run the jar by running java -jar <jar_name> in the command line.

7. You will also need to setup the proxy server for Magento endpoint so that the endpoint is available locally for CIF add-on and the CIF core components and to get the products binded in the Commerce console. 

Run the following command to do that :

In Windows:

npx local-cors-proxy --proxyUrl http://localhost/magento2 --port 3000 --proxyPartial ""

Note: While setting up the proxy server , pass your Magento endpoint without /graphQL.

Your proxy server will be started stating Proxy Active and you can check the same by replacing proxied part with the http://localhost:3000/

Login to the AEM SDK and verify the CIF add-on related bundles at http://localhost:4502/system/console/osgi-installer

You will also be able to see the additional Commerce tab in http://localhost:4502/aem/start.html

Setup of the local AEM Commerce as a Cloud Service is completed now.

To deploy Viena project Follow Venia project with AEM

Happy Coding!!!

Terraform - IAC

 

Lot of tools available if you search for infrastructure as code: 

• Chef
• Puppet
• Ansible
• SaltStack
• CloudFormation
• Terraform

But Cloudformation and Terraform are provisioning tools. Here we will discuss about Terraform.

Terraform is the infrastructure as code offering from HashiCorp. It is a tool for

• building, 
• changing, 
• managing infrastructure

 in a safe, repeatable way. 

Infrastructure as Code

It is the process of managing infrastructure in a file(s) rather than manually configuring resources in a user interface. A resource in this instance is any piece of infrastructure in a given environment, such as a virtual machine, security group, network interface, etc.

Terraform

• Terraform allows operators to use HCL to author files containing definitions of their desired resources.
• Almost any provider (AWS, GCP, GitHub, Docker, etc)

Workflows

A simple workflow for deployment will follow closely to the steps below.

• Scope - Confirm what resources need to be created for a given project.
• Author - Create the configuration file in HCL based on the scoped parameters
• Initialize - Run terraform init in the project directory with the configuration files. This will download the correct provider plug-ins for the project.
• Plan & Apply - Run terraform plan to verify creation process and then terraform apply to create real resources as well as state file that compares future changes in your configuration files to what actually exists in your deployment environment.

Advantages

• Platform Agnostic
• State Management
• Operator Confidence

Install Terraform

Follow Install terraform to install.

Install Terraform

 coming soon

ADOBE Sites Developer Preparation Questions

 

´Adobe Experience Sites Developer Exam Guide Exam- AD0-E103

´Get Official Exam guide for AEM developer sites here:

https://spark.adobe.com/page/pszIHVOp7KKuR/

´Exam Questions

•  Get 200+ Questions for preparation of AEM Sites developer certification.

•  Questions available in word/pdf format.

•  Questions with answers are available.

•  Helpful for AEM learning at both developer and lead developer level.

´Contact to Purchase

 Email Id: codingwithtea@gmail.com

 Refer Blogs: https://codingwithtea.blogspot.com/

ACID - DBMS

 

Atomicity Consistency Isolation Durability (ACID)

ACID refers to a database system’s four transaction properties: atomicity, consistency, isolation and durability.

Transactions: A transaction is a single logical unit of work which accesses and possibly modifies the contents of a database. Transactions access data using read and write operations.

In order to maintain consistency in a database, before and after the transaction, certain properties are followed. These are called ACID properties. It is a sequence of operations that satisfies these properties.

Let's go ACID properties in detail:

Atomicity: Nothing or All

Atomicity is a property that ensures that a database follows the all or nothing rule. In other words, the database considers all transaction operations as one whole unit or atom. There is no midway i.e. transactions do not occur partially.

It involves the following two operations.

Abort: If a transaction aborts, changes made to database are not visible.
Commit: If a transaction commits, changes made are visible.

Thus, when a database processes a transaction, it is either fully completed or not executed at all. If a single portion of the transaction fails, the whole transaction will fail.

For example, user X wants to withdraw $50 from his account and then transfer it to the account of user Y. Each transaction (withdrawing $50 from account X and transferring $50 to account Y) is counted as separate. If the first transaction (withdrawing $50) fails because (say) the server crashes during the transaction, user X cannot transfer the money to user Y.

Consider the following transaction T consisting of T1 and T2: Transfer of 50 from account X to account Y.

Initial Balance: X=100 , Y=200

T1 Transaction:

Read(X)

X= X-50

Write(X)

T2 Transaction:

Read(Y)

Y=Y+50

Write(Y)

If the transaction fails after completion of T1 but before completion of T2.( say, after write(X) but before write(Y)), then amount has been deducted from X but not added to Y. This results in an inconsistent database state. X has left $50 in his account as $50 has been deducted but Y has $200(same as before). Transaction got failed. What if Y doesn't get $50 and X's reaction would be😱

Hence, Atomicity is particularly important to mitigate damage in case of database server crashes. If a non-volatile database crashes in the middle of a transaction, all changes done will be discarded or rolled back to avoid sending partial results to the production database.

Hence we can say Atomicity is required. Transaction (T1+T2) takes place at once.

Consistency:

Consistency is key to maintain data integrity. Consistency is a property ensuring that only valid data following all rules and constraints is written in the database. When a transaction results in invalid data, the database reverts to its previous state, which abides by all customary rules and constraints.

For example, if user X wants to withdraw $1,000 from his account, but only has a balance of $500, consistency will prevent him from withdrawing money and the transaction will be aborted.

Current Balance: $500

Wants to withdraw: $1000

How?😳

"User X hasn't sufficient balance!"

Isolation:

Isolation ensures that multiple transactions can occur concurrently without leading to the inconsistency of database state. It is a property that guarantees the individuality of each transaction, and prevents them from being affected from other transactions.

For example, user X withdraws $100 and user Y withdraws $150 from user Z’s account, which has a balance of $1,000. Since both A and B draw from Z’s account, one of the users is required to wait until the other user transaction is completed, avoiding inconsistent data.

User Z Balance: $1000

User X wants to withdraw: $100

User Y wants to withdraw: $150

One user has to wait till other's transaction is being completed. For e.g. Y has to wait till X's transaction is in progress.  

Durability

Durability is a property that enforces completed transactions, guaranteeing that once each one of them has been committed, it will remain in the system even in case of subsequent failures.

If a transaction is successful, all changes generated by it are stored permanently.

Let's say in above example, user Y may withdraw $100 only after user X’s transaction is completed and is updated in the database. If the system fails before X’s transaction is logged in the database, X cannot withdraw any money, and Z’s account returns to its previous consistent state.

So, once the transaction has completed execution, the updates and modifications to the database are stored in and written to disk and they persist even if a system failure occurs.

Clean Code Principles Ideas

"Why should I care about writing clean code?” you may still be asking yourself.

There are many reasons to get into the clean code mindset. Some of the most important reasons are:

Better Use of Your Time

The first beneficiary of clean code is the programmer themselves. If you are working on a project for months, it’s easy to forget things you did in the code, especially when your client comes back with changes. Clean lines of code make it easier to make changes.

Easier Onboarding for New Team Members

Using clean code principles helps to get a new programmer onboard. There is no need for documentation to understand the code; the new programmer can directly jump into it. This also saves time for both trainings the new programmer as well as the time it takes for the new programmer to adjust to the project.

Easier Debugging

Whether you write dirty or clean code, bugs are inevitable. But clean code will help you to debug faster, regardless of how much experience or expertise you have.

More Efficient Maintenance

As any project grows, it will need new features or changes to existing features.

You feel Good!

I am going to select some of the ideas to write a clean code. So let's start...

Universal Principles: 

Follow standard rules: experiments always end in disaster.

• Avoid duplication in the code (DRY principle or Don’t Repeat Yourself ).
• We must apply The Boy Scouts rule to our profession: Leave the campground cleaner than you found it.
• Follow SOLID principles to write clean classes and well-organized APIs.
• Follow Code principles article for the detailed explanation.

Names Rules:

• Use searchable names.
• Make it easy to remember them.
• Use names according to the context.
• Choose descriptive and clear names.
• Use names that can be pronounced well.
• Use names that are consistent with each other. 
• Use the same language in the names of variables, functions: English, French, etc. 
• Avoid encodings and don’t append prefixes or type information.

Classes:

• Classes should be small.
• Use correctly package levels: public, protected, etc.
• Classes should have only one responsibility and only one reason to change (SRP).
• Keep utility methods and variables private. Exceptions are always there. for eg: for testing

Objects and Data Structures:

• Hide internal structure.

• If you can, call only your methods of your class, of objects you have created, and avoid call methods reachable through these objects (Law of Demeter).

• Improve the decoupling of objects.

• Variables should be private and manipulated by getters and setters, but remember, there is no necessity to add getters/setters to each variable to expose them as public.

• The base class should know nothing about their derivatives.

• Objects expose behavior and hide data. Conversely, data structures expose data and lacks of (significant) behavior.

Functions rules:

• They should be short and only do one thing. If your function is doing more than "one thing", it is a perfect moment to extract to another function.
• Keep the number of arguments as low as possible.
• Avoid side effects. Declare the arguments as final if you can.
• Functions should either answer something or do something, but not both.
• Prefer Exceptions to return error codes and extract error handling try catch into their function.
• Don’t return a null value. What is null? It does not provide any information. If you really want to then handle all exceptions which occur due to null values like Null Pointer Exception.

Design rules:

• You should declare local variables as close as you can to their usage.
• You should declare instance variables at the top of the class.
• Constants should be declared at the top of the class or in a Constants class by example.
• Follow the Law of Demeter: A class should know only its direct dependencies.
• Use dependency injection.
• Place methods in a top-down direction.
• If you use third-party libraries, wrap them, so if they change, only your wrapper implementation needs to change.
• It is a good idea to separate concepts vertically.

Exception handling:

• Throwing errors makes code cleaner than checking for status values throughout the code.
• Provide enough meaning to determine the cause and location of an error.
• Wrap third-party libraries APIs to remap their exceptions as required.

Concurrency:

• Concurrency, although it may improve the performance of the program, is difficult, so use it wisely and only when required.
• Keep concurrency control separate from other code.
• Know basic concepts and programming models like mutual exclusion, starvation, or deadlocks.
• Create locked sections small.

Tests:

• Fast: Unit tests should be fast and being executed in a short time.
• Independent: Tests should not depend on each other.
• Repeatable: Tests should be reproducible in any environment.
• One assert per test.
• TDD: Build your software using tests that guide your development.
• Cover all test cases. You can use jacoco to check if you have covered each test case of the class.
• Make a standard: to set coverage of Junits. for eg: 80% coverage you can set for running unit test cases. 

Clean tests should follow F.I.R.S.T principles:

• Fast: ⏩ Tests should be fast. They should run quickly. When tests run slow, you won’t want to run them frequently
• Independent: 🆓 Tests should not depend on each other. One test should not set up the conditions for the next test. You should be able to run each test independently and run the tests in any order you like.
• Repeatable: 🔁 Tests should be repeatable in any environment. They should run in the production environment, the QA environment, and even on your laptop while riding home on the train without a network.
• Self-Validating: ✅ The tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell whether the tests pass.
• Timely: ⏲The tests need to be written in a timely fashion.

Comments:

• Comments are difficult to maintain and don’t tell the truth about the code, so try to avoid it. 
• Use only as a clarification of code.
• The code is the best documentation.
• Don’t be redundant.
• Avoid unnecessary comments.

Formatting:

• Avoid too-long files.
• Good files have a heading, the critical stuff first, and details later.
• Avoid lines get too long (80 or 120 is perfect). You will get used to being more concise, and your code will be more readable.
• Be consistent with the rules of your team and better define rules before the start of the project. (in sprint 1 😉)

Follow these rules and make sure your code will be robust and will adapt to changes more quickly.