Monday, October 7, 2013

Integration with other third-party service

The below list of questions will help you to get some high level overview of how to integrate
your application with other third party services and also will help you what are all the question's
we may need to ask to third party provider
  • Do you have any kind of web interface where we can test web methods by passing sample data?
  • How many ways we can integrate your product in to our application? ( Web-methods, REST API's, JavaScript api's, ODATA etc )
  • Does all API's support all functionality’s?
  • Limitations of your product?
  • Do you have any web interface, where we can do basic/limited operations like creating test user's, checking reports etc...
  • Who will provide secret token? Can we generate secret key by following client side web interface?
  • Any limitation on web service API’s calls count? Will you charge if the request count exceeds?
  • Do we need to send username and password along with web service request or username, password and secret token is enough?
  • Will you charge any amount? if we raise a request to create new user or modify something etc... ?
  • What kind of output does your application returns?
        • JSON
        • XML
        • Encrypted IMAGE
        • IFrame contains html
  • If the output is html, does it support all browsers?
  • What kind of authentication mechanism, do we need to follow while using web-service?
  • If authentication mechanism is basic then do we need to make SSL requests?
  • Does your application supports SSL?
  • Does your web-service supports generating entity classes?
  • How can we identify whether the request is succeed or not?
  • Is there any time-out applied for web-service calls?
  • If we are not able to access your web-service url, what are all the things do we need to check, do you have any trouble-shooting document?
  • Do we need to do any kind of encryption while passing parameters to server?

Wednesday, October 2, 2013

CMS Best Practices

Don't include JQuery libs at component level

I have seen so many people who include JQuery libs at component level, the disadvantage of including at component level is for each and every component the system will make request to server to download JQuery libs and it may lead to page performance

Sometimes we get lot of undefined JavaScript errors because of loading multiple versions of JQuery libs


Maintaining central location, I suggest create client libs and include at Basetemplate level, if new version comes just update client libs

In some scenarios the system will force you to include at component level, in such cases use JQuery.noConflict () option to avoid conflicts

Consider that the AEM also provides JQuery libs, some functionality which is depending on particular version of JQuery then download into your clientlibs; otherwise try to utilize OOTB JQuery Libs

Don’t deploy CSS or JS files in to production

Is it right approach deploying CSS, JavaScript files as part of deployment package in “Content Management System”?

Why,  because I have seen some people who came from traditional web development and no knowledge on CMS trying to deploy css and js files through package and finally mess up entire environment like overriding content of css and js files of content authors

How can we handle this situation, in any CMS you can find two types of content one is static content and another one is dynamic content

Dynamic content:

The content which you think it changes frequently by content author or admin’s need to be handled by content deployment or replication or page activation

Ex: Style sheets, images, text etc…

Normally, the content authors or site admin’s performs this action

Static content:

The content which you think it will not change in future need to be deployed as package such as style sheets, images, JavaScript files etc…
This is the developer job and the developer includes this content into package and deploys into a respective environment


Don’t include css and js files in your deployment package, if you feel the content author is going to modify it, keep it in central location which can be accessible by content authors as well as developers

Normally in SharePoint you can do this by placing style sheets in style library and in CQ5 you can do this by putting in etc/designs folder

Don’t deploy configuration file in to the production environment

The general meaning of configuration file is to change settings of system at any time, but if you deploy your settings through deployment package that may override existing entries which has made by author and the system may go down

I strongly recommend don’t deploy your configuration settings through package which you feel it changes frequently

Always create I18n folder at site level not at component level

Don’t create I18n folder at component level, if you create your I18n folder at component level you may lose certain capabilities,

Suppose in future if you want to create new locale it is very difficult to check entire solution to identify I18n folders, which needs to convert into new locale and which may lead to maintenance issue and moreover there is a chance for duplicate entries

These duplicate entries may override existing ones and you need to spend lot of time to debug the issue

Always use locale copy while creating new website

Don’t create web site by simply creating pages in hierarchy manner, it is very difficult to implement MSM

The page nName needs to be in the format of or _, for example en, en_US, en_us, en_GB, en_gb.
•    The supported language code is lower-case, two-letter code as defined by ISO-639-1
•    The supported country code is lower-case or upper-case, two-letter code as defined by ISO 3166

Don’t iterate nodes, try to use Query Builder, if you are performing any search operation

Use Case:

The user shall be able to receive news based on subscribed opt-in's

The Taxonomy for news is

    Therapy area news                                         
    Oncology news       
While registering into site the end user select’s any of news taxonomy keyword either Therapy area or oncology, based on the selection the system will send respective news related email’s to the user

Here, don’t iterate each and every user node to find out opt-in, try to use query build to avoid performance impact

The sibling nodes should not exceed more than 2k

Keep in mind that the sibling nodes should not exceed more than 2k , under normal circumstances it is fine like simple creating and reading node’s but, if you are  performing any kind of search operation on these nodes this may impact on performance

Don't enable dispatcher level cache in lower environment only enable in production environment

Don’t enable dispatcher level cache in lower environment, if you are planning to do load testing, test it on lower environments either pre-prod or the environment which is similar to your production box

Always make sure the cache should be enabling in production box, initially this may impact on performance but while going forward the performance will increase

Before enabling cache in production box think about your application digital asset size, if the volume of size heavy, then it is better to enable cache ASAP

All environments should be in sink to avoid surprises

Always make sure that the environments should be in sink to avoid last minute surprises, I strongly recommend don’t directly work on production environment if you face some problems in production environment, first fix it in pre-prod environment , then test it in prod author and finally fix  it on publish environment

I recommend first deploy package in author and publish environment then replicate content from author to publish environment, before replication content check all configurations are fine or not

I have seen some people who directly work’s on publish environment and making entire system down, but this is not right approach

Don't do over architecture keep it simple

While developing components don’t do over architecture keep it as simple as possible, sometimes the over architecture may impact on performance, for simple components try to reduce layers

Don't store PII information in cookies

The Personal Identification Information is very important for any client, so don’t store PII information in cookies like user password, social security number etc,..

Try to leverage to use OOTB functionalities

Once you receive requirements from your client first check whether it is feasible with OOTB functionality or not, if it feasible then tries to use OOTB, if it is not feasible then only start developing custom components

Identify Data Model before start developing custom components

Choosing database is not an big difficult just compare relational database features with JavaContentRepository features

Ex :

For some of the requirements demands versioning capability, in such cases the relational database does not support versioning functionality, so we need to think about JCR

Avoid loading unnecessary dependencies in POM files

Try to avoid loading un-necessary jar files through POM entries, identify all required common jar files and create separate module and import that in to other modules

This we can achieve only through user education

Don’t refer untrusted resources

I have seen some components which is directly referring like below code

The best practice is download the .js file to your solution and refer it

Use CDN 

To achieve greater performance, if possible try to implement CDN, but this totally depends on client

Don’t hard code CDN server url while making image, video, file etc… it is very difficult to identify each and every link

Create separate Filter which parse each and every url, if it is a digital asset then redirect to CDN server to download that Digital Asset

Create custom error pages

For any website the custom error pages are mandatory like 500 server error, 404 not found etc… if we directly display as it is then this will directly effect on overall website credit

So always design custom error message pages and apply it


Cross site scripting enable attacker to inject maliculious code in to your system, so don’t forget to encode user inputs before submitting form

Use XSSFilter in CQ5 to validate User entered information

 Know the difference between Sessions

If you see Any CMS there are two sessions one is Admin session and another one is User Session

For read only operations use User sessions and if you are doing some edit and update operations then go with admin sessions

If the requirement is just reading items or nodes and display it on a page then just go with user session

Try to avoid using admin sessions , if  you are obtaining inputs from end user try to store into /content/usergenerated folder in content repository

For just reading nodes and properties use user session slingRequest.getResourceResolver().adaptTo(Session.class)