Showing posts with label Integration. Show all posts
Showing posts with label Integration. Show all posts

Wednesday, 30 August 2017

Integrate AEM with React JS library

Introduction

React is a Javascript library developed solely for the purpose of UI designing. It was developed in Facebook to facilitate the implementation of reusable, interactive and stateful UI components. Facebook use this library in production. 
It carefully notes down the differences in in-memory cache and use these differences to update the DOM in browser, which is what gives him the boost. This is the Virtual DOM feature.


Saturday, 19 August 2017

Install NodeJs

What is NodeJS

  • Node.js is an open source server framework
  • Node.js is free
  • Node.js runs on various platforms (Windows, Linux, Unix, Mac OS X, etc.)
  • Node.js uses JavaScript on the server

Click here to check Why Node.js

What is npm?

npm makes it easy for JavaScript developers to share and reuse code, and it makes it easy to update the code that you're sharing.
Click here to learn more on npm.

Install npm

Click here to download and install the npm on your machine.

Test if nodeJs is installed correctly, run below command.
npm -v
or 
npm --version
npm version

Start npm run start, if you get below error 
npm ERR! path C:\Users\Kishore\package.json
npm ERR! code ENOENT
npm ERR! errno -4058
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open 'C:\Users\Kishore\package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Kishore\AppData\Roaming\npm-cache\_logs\2017-08-19T14_53_13_265Z-debug.log


You can avoid above error by following below

  • running the npm command from bin folder
  • set environment variables (~\bin)


Saturday, 22 April 2017

Integrate AEM with Docusign - Part 1

Integrate AEM with Docusign to get Docusign account information

What is Docusign?

DocuSign® is The Global Standard for Digital Transaction Management. Accessible anytime, anywhere on any device, global enterprises, business departments, individual professionals, and consumers in all industries solve their paper problems by replacing manual, paper-based methods with DocuSign. The result is accelerated transactions that increase speed to results, reduce costs, improve visibility and control, and delight customers. DocuSign helps you keep business digital with the easiest, fastest, most secure way to send, sign, manage and store documents in the cloud.

Why Docusign?



Friday, 24 March 2017

Integrate Adobe AEM with Salesforce

Integrate Adobe AEM with Salesforce


Adobe AEM provide its extendable capabilities to integrate  with other products. Below demonstration describe how to connect Adobe AEM with Salesforce which is the market’s leading cloud based CRM System. AEM provide OOTB components for the integration purpose. It helps the organization to target the customers through web channels as per their status in CRM.

Steps to Connect to Salesforce:
AEM uses OAuth mechanism to connect to Salesforce. So , first we need to create an connected app inside salesforce to get customer secret and access token.

Go to login.salesforce.com. Click on Setup on the top right corner. Search for Apps and create a custom app. Fill in required details as shown in below images. Callback Url here accept only https urls, so our AEM must be SSL configured. Check here how to configure SSL in AEM. Callback url is the url of cloud service that we will create in AEM.

Create new custom app

Thursday, 9 March 2017

AEM and Akamai Integration

WHAT IS AKAMAI?

Akamai is a CDN (Content Delivery Network) that has servers all over the world, delivering the content of a website and caching that part of the content that doesn’t need to be constantly updated.
Beyond AEM, as CDN, among Akamai’s pros we can find some remarkable points:
  • Faster delivering content:  Is not the same that an user access to the website servers than could access to Akamai. In Akamai the content is available in closer servers and cached.
  • Better balancing of the content: apply an Internet-centric approach to global load balancing and real-time fail-over. Designed to ensure high availability and responsiveness to user requests.
  • Safety: put another wall between the user and your website.
  • Improve user experience: Due to previous points the user has a better experience when requests content.

Friday, 3 March 2017

Display dynamic popup using GTM

There are different ways to display a dynamic modal popup, one of the best way is displaying the modal popup using google tag manager, as there will not be any code required. All changes to be done in GTM console. 


Dynamic modal using GTM
Dynamic modal using GTM

Friday, 17 February 2017

AEM DTM Integration

The purpose of this blog is to go over AEM DTM Integration process step by step, using the recommended configuration options. There is documentation available for integration by Adobe here. Although, for someone who is integrating AEM DTM for the first time or with limited knowledge of one or the other, it is quite overwhelming to be exposed to the technicalities of all the available options at once. This post will also elaborate and expand on embedding DTM code on various experiences built within a single AEM instance. I hope this blog helps in simplifying the process for you.
Assuming you have an author instance of AEM running, there are the three majors steps you need to perform to add the DTM code on your site via the cloud-hosted services integration:
  1. Create web property in DTM
  2. Configure AEM DTM Integration
  3. Embed DTM code in a specific AEM site

Friday, 30 December 2016

Installing Hybris 6

Hybris Installation
Follow below instruction to insall Hybris environment.
  1. Download JDk 8 from here
  • Accept licence terms and conitions.
  • Download as per your windows bit (32 or 64)
  • Once downloaded, install jdk by double clicking it. Follow the default instructions by clicking next.
  • Once installed, you should can verify installation in command prompt.
  • setant
  • Download the Hybris  from here.

Saturday, 19 November 2016

Implement Translator connector in AEM

The purpose of a Translation Connector in any Content Management System (CMS) is to automate content transmission between CMS and Translation Service Providers making it quicker and cost-effective. Such integration is required when there is a need to maintain multiple languages in CMS. Similarly, for projects in Adobe Experience Manager (AEM) that involves website localization and multilingual SEO management, translation connectors implementation becomes a mandate.
Translation Connectors are simply used to provide an interface between AEM and Translation Management System (TMS), where TMS is nothing but programs which support complex translation tasks.

Using Dynamic Tag Manager in AEM

You can integrate Adobe Experience Manager (AEM) with Adobe Marketing Cloud Activation Core Services (formerly named Dynamic Tag Management). Activation is an Adobe Marketing Cloud Core Service that allows a digital marketer to manage Adobe and third-party tags used for tracking or other analytics purposes. It is done through client-side scripting that injects tag related code throughout the pages of the site. 
You define rules in the Activation web client, as shown in this illustration. 

Thursday, 27 October 2016

Translating Content for Multilingual Sites

Automate the translation of page content, assets, and user-generated content to create and maintain multilingual websites. To automate translation workflows, you integrate translation service providers with AEM and create projects for translating content into multiple languages. AEM supports human and machine translation workflows.



AEM and Hybris Integration

Developing with Hybris

The eCommerce framework can be used with any eCommerce solution. Certain specifics and examples dealt with here will refer to the hybris solution.

The integration framework includes an integration layer with an API. This allows you to:
  • plug in an eCommerce system and pull product data into AEM
  • build AEM components for commerce capabilities independent of the specific eCommerce engine

AEM & eCommerce Integration

One of the core elements of any eCommerce implementation is the management of product data. When integrating with AEM you have the choice of either importing the product data into the JCR or having it exist solely in the eCommerce system. There are pros and cons to both approaches. Importing the data into AEM allows you to make use of the AEM Commerce components, use the AEM Commerce API, and do some fun things like product page generation, and data-driven tag creation. Having the product data in the JCR also allows AEM to access the information without having to make a call to the commerce platform every time. The con of having this data in AEM is that it may present challenges in keeping the data in sync. While things like product name, description, and image may not change often some more dynamic properties such as stock level, pricing, and active status may demand a more real time approach. This challenge can possibly be offset through the use of incremental imports and node listeners but ultimately the decision will come down to your specific implementation and the needed frequency for updates.
I have encountered two ways to import product data into the JCR. The first method of importing products is accomplished by uploading good ol’ fashioned CSV files with your product data in AEM Tools at http://localhost:4502/miscadmin. Navigate to /etc/commerce/products, click “New File..”, then browse and select the CSV.

Thursday, 29 September 2016

Integrate Google reCAPTCHA with AEM

You can use Google reCAPTCHA to your AEM site to protect your website from automated script attacks while letting real users pass through with ease. The reCAPTCHA library is a free service that protects your website from spam and abuse. By using reCAPTCHA, you can improve the security of your AEM site. For more information, see reCAPTCHA.
The following illustration shows reCAPTHCA included within an AEM site. 
An AEM web page using recaptcha

Saturday, 24 September 2016

Integrating SOLR with Adobe Experience Manager

You can integrate SOLR with Adobe Experience Manager to improve searching. Solr is the popular, blazing-fast, open source enterprise search platform built on Apache Lucene. Solr is highly reliable, scalable and fault tolerant, providing distributed indexing, replication and load-balanced querying, automated fail-over and recovery, centralized configuration and more. Solr powers the search and navigation features of many of the world's largest internet sites. For more information, see http://lucene.apache.org/solr/.
The following illustration shows the SOLR client.

The SOLR web client


Tuesday, 30 August 2016

Integrate AEM with Adobe Search and Promote


Search and promote(S&P) offers the following features:

  • Search features like auto-complete and "Did you mean?" help the users to get relevant search results.
  • Real-time metrics, merchandising rules, and customer intent.
  • Refinements based on facets and filtering options.
  • Built-in linguistics help in spell-checking and searching for non-English languages.
  • Real-time analytics allow search results to be dynamically ranked according to business objectives.
  • Easily scalable and reliable because S&P is provided as SaaS using cloud infrastructure.
  • Incremental indexing helps in ensuring that visitors are always shown with the up-to-date search results.

Friday, 20 November 2015

Integrate AEM with YouTube

You can use youtube API to add video in your webpages. Below is the sample code snippet for embedding youtube videos into your webpages.

Note:  In order to make sure your javascript works, add "enablejsapi=1" parameter to the src atttribute. Please check below HTML code.

HTML Code

<h1>In page youtube video player API</h1>
<br/>
<h2><span id="YTvideoLoadTime"></span> </h2>

<h3>Check console logs for player events</h3>
<iframe id='player' width="560" height="315" 
src="https://www.youtube.com/embed/axCKOu3YjmM?list=PLkBe8kbE_7-xmNihqYr19TlYGH7jUhQkY&enablejsapi=1" frameborder="5" allowfullscreen></iframe>



Javascript:

//YOUTUBE API
var player;
var timerStart, timetaken;

jQuery(document).ready(function ($) {
    console.log("ready!");
    loadPlayer();
});

function getArtistId() {
    return 'axCKOu3YjmM';
}

function loadPlayer() {
   console.log("Youtube IFRAME api");
    timerStart = Date.now();
    if (typeof (YT) == 'undefined' || typeof (YT.Player) == 'undefined') {
        var tag = document.createElement('script');        
        tag.src = "https://www.youtube.com/iframe_api";
        var firstScriptTag = document.getElementsByTagName('script')[0];
        firstScriptTag.parentNode.insertBefore(tag, firstScriptTag);

        window.onYouTubePlayerAPIReady = function () {
           // console.log("YT undefined calling onYouTubePlayer ");
            onYouTubePlayer();
        };

    } else {
       // console.log("calling onYouTubePlayer ");
        onYouTubePlayer();

    }
}


function onYouTubePlayer() {
    player = new YT.Player('player', {
        // height: '490',
        //width: '880',
       // videoId: getArtistId(),
       // playlist: 'PLkBe8kbE_7-xmNihqYr19TlYGH7jUhQkY',
        playerVars: {
            controls: 1,
            showinfo: 0,
            rel: 0,
            showsearch: 0,
            iv_load_policy: 3
        },
        events: {
            'onStateChange': onPlayerStateChange,
                'onError': catchError,
                'onReady': onPlayerReady
        }
    });
}

var done = false;

function onPlayerStateChange(event) {
    console.log("onPlayerStateChange: " + event.data);
    if (event.data == YT.PlayerState.PLAYING ) {
        console.log("playing");
        done = true;
    } else if (event.data == YT.PlayerState.ENDED) {
        console.log("ended");
        location.reload();
    }
    else if (event.data == YT.PlayerState.PAUSED) {
        console.log("paused");
    }
}

function onPlayerReady(event) {
    //console.log("onPlayerReady");
    timetaken = Date.now() - timerStart;
    $('#YTvideoLoadTime').html("Youtube Video player has loaded in : " + timetaken / 1000 + " seconds");

}

function catchError(event) {
    if (event.data == 100) console.log("ERROR");
}

function stopVideo() {
    console.log("stopVideo");
    player.stopVideo();
}



Monday, 16 November 2015

Connect to External Data Source (Teradata / MySQL / Oracle) in CQ / AEM

1) My SQL

Step 1: Create OSGI version of mysql Jar file


  • Click next and then select add external. Select jar file you downloaded above and select next
  •  Give Project Name -> Select Location -> Make sure that Analyze Library Content is checked -> In Target Platform select an OSGI framework -> from drop down select standard -> Check unzip jar file and update reference -> click finish

Brightcove AEM Integration



Brightcove Video Connect for AEM is a configurable integration enabling users to add/edit/manage videos, playlists and players directly within AEM's authoring interface.
The integration streamlines video publishing workflows for organizations who have been using Video Cloud and AEM concurrently. This is particularly evident in instances where there is a division of labor between the person or team responsible for uploading content to Video Cloud, setting business rules and creating players, and the person or team responsible for editing and publishing webpages via AEM. Both parties can now manage video content smoothly amongst themselves in the common AEM setting.
Brightcove Video Connect for AEM is free and open source. 
Brightcove Video Connect for AEM was developed by Coresecure, Brightcove’s official AEM development partner.
References:
http://www.coresecure.com/brightcove-aem-integration/
https://www.brightcove.com/en/partners/cq5
https://www.brightcove.com/en/partners/adobe-experience-manager

Wednesday, 11 November 2015

Dispatcher Configuration in Adobe AEM

Dispatcher is one of the best things that I have seen in Adobe CQ / AEM since we are playing around with Day/Adobe CQ/AEM .
This is a small module in Apache which is tremendously powerful when Caching comes into picture .
This module helps the CQ publish servers take some rest whenever the same page /url (which is cacheable) is hit multiple times .

Dispatcher and its anatomy

We will discuss about some terminologies and tricks in the dispatcher configuration file in production apache server which usually sits in front of the publish instances .
I will try to explain parts of the dispatcher.any file and then collate all the configurations .
The whole dispatcher.any file consists of some properties and their values (can be multivalued).
All the properties start with a forward slash “/” .
Values are enclosed with two braces “{}” .
The “name” property defines a human readable name to the dispatcher.
/name "any name you can provide" “farms” holds a bunch of properties and values .
Often in complex applications , its tough to put all the dispatcher configurations in a single farm . In that case , you might want to divide the logic/functionality for different sets of urls/websites into multiple farms and include them in the parent farm.
the /farms property can contain one farm (in case , you want to handle all websites/urls in the same manner) or multiple farms (when you want to define different sets of handlers/farm for different sets of websites/urls associated with your website ) . Don’t worry . This may sound a bit confusing at this moment .
Inside the /farms property you can define a farm or you can include a farm defined somewhere else or you can do both.
/farms
{

    /fadfish
    {
    ### This is the first farm which has been defined in the dispatcher.any itself .
    }

    $include ("fadfish2.any") # This is the second farm which has been defined in the fadfish2.any file .
}
Remember , the farms are evaluated from bottom to top .
The farm again contains some properties which you will find the most useful.
Most of the times “/clientheaders” is the first property in a farm configuration. Each HTTP request carries a set of Request Headers . They are pretty much needed for your application to decide some most crucial attributes of the request that is coming to your website.
To know more about HTTP Request Headers , I would insist on reading the HTTP RFC 2616 .
Your dispatcher can skim specific headers coming from Client before they reach to your CQ publish instance . Great !! ain’t it ? You can either allow all the request headers coming from client by specifying a “*” in the “/clientheaders” section or you can allow some custom CQ specific headers by providing a list of all the headers (custom + regular) in the “/clientheaders” section .
/clientheaders
     {
      "referer"
      "user-agent"
      "authorization"
      "cq-action"
      "cq-handle"
      "handle"
       ....
       ....
       ....
       ....
     }
The /virtualhosts property defines a list of all hostname/URI combinations that Dispatcher accepts for this farm.
/virtualhosts
    {

      # "*" will cause all the requests handled by this dispatcher.
      "*"
    }
You may have two farms to handle separate kinds of requests . Suppose , first farm will handle all the requests that is coming for /products directory and the other farm will handle the rest of the requests coming to your website .
The /renders property defines which URL the dispatcher sends requests to. In 99% of the use cases , this is the IP of the Publish CQ instance. You can have multiples renders for a farm , which will distribute the load to all those ip/CQ/AEM instances , mentioned in the renders property .
In the following example, rend01 and rend02 are two renders which distribute all the traffics coming to this dispatcher to localhost:4503 and localhost:4505 equally.
/timeout is the time in milliseconds the dispatcher should wait the AEM instance to respond.
/renders
  {
  /rend01
    {
    # Hostname or IP of the render

    /hostname "localhost"

    # Port of the render
    /port "4503"

    # Connect timeout in milliseconds, 0 to wait indefinitely
     /timeout "10000"
    }

    /rend02
    {
    # Hostname or IP of the render

    /hostname "localhost"

    # Port of the render
    /port "4505"

    # Connect timeout in milliseconds, 0 to wait indefinitely
     /timeout "10000"
    }

    }
Access Control over content
The /filter property helps define access control over content. It defines the HTTP requests that the dispatcher accepts . Other requests are sent back to the Apache Webserver with a 404 status code.
If you don’t define a /filter property , all the HTTP requests are accepted by the dispatcher.
Each item in the /filter section includes a glob(used to match the http request line) and a type (allow/deny).
As per good security measure, it is always advisable to block all the request, and then specially allow only those type of requests which you want to serve.
/filter
  {
    # Deny everything first and then allow specific entries
    /0001 { /type "deny"  /glob "*" }
    /0002 { /type "allow" /glob "* /content/* *" }
  }
/propagateSyndPost is the property , which decides whether your syndication requests should handled by the dispatcher or it should go to the renders(AEM instances) .
If, the /propagateSyndPost is set to 1 , the syndication requests are send to dispatcher . Make it 0 , unless you are sure what you are doing.
/propagateSyndPost "0" One of the most important part of the dispatcher is the cache section .
/cache property and its values define the way your dispatcher caches documents/pages . It has multiple sub properties and values .
I will cover few important properties which are a must to know .
/cache
    {

        /docroot ## Defines the place , where your cached files should be . The value should be relative to the docroot of the webserver.
        /statfileslevel  ## Sets the level upto which files named ".stat" will be created in the document root of the webserver.
        /serveStaleOnError
        /allowAuthorized  ## setting the value to 1 enables the dispatcher to cache authenicated documents to get cached in the dispatcher.
        /rules  ## It provides the documents which should be cached .
        /invalidate
        /invalidateHandler
        /allowedClients
        /ignoreUrlParams

    }
/serveStaleOnError is another important property which is often ignored. Whenever some content is activated it gets deleted from the dispatcher cache. But if the /serveStaleOnError property is set to 1 , the cached HTML does not get deleted immediately upon activation. Only the .stat file is touched. Next time if a request comes for the same page , it first goes to the AEM instance to take the latest content. If it gets a response , it replaces the old cached content and cache the new html. If , it gets a a 500/503/5XX response from the server, it simply serves the old cached content with a HTTP status code of 111.
Again I would suggest , use it if you have a good reason behind it. Else, no need to specify the property at all.
/rules property is another useful thing which must know when you are playing with dispatcher . You may get confused while defining /filters and /rules .
/filters come into picture when you want to decide whether the request should be dealt with your dispatcher or not . /rules come into action when you want to decide whether the request should be served from cache or it should delegate the request to AEM instance . Hence , /rules totally deals with caching . .
By default , dispatcher does not cache any request 1) whose HTTP method is not GET , 2) URI contains a question mark , 3) File extension is missing .
Generally , we cache everything else apart from whatever mentioned above . To define /rules also , we use a /glob pattern .
/rules
    {
    /0000
      {
       /glob "*"  /type "allow"
      }
    }
allow will define what to cache in webserver . deny will define what to be taken from the AEM instances and not cache in dispatcher.
/invalidate property defines what are the cached contents that will be invalidated whenever there is a content activation.
/invalidate
    {
        /0000
          {
          /glob "*"
          /type "deny"
          }
        /0001
          {
          # Consider all HTML files stale after an activation.
          /glob "*.html"
          /type "allow"
          }
        /0002
          {
          /glob "*/content/fadfish/products*"
          /type "deny"
          }

    }
The /allowedClients section restricts the client IP addresses that are allowed to issue activation requests. This is one of the most important security measure that you should take when configuring a dispatcher .
Ideally , you should only allow your Author AEM instance flush dispatcher cache for a page . Else , any intruder can send a POST request to your dispatcher and flush your cache.
/allowedClients
    {

        /0000
          {
          /glob "*"
          /type "deny"
          }
        /0001
          {
          /glob "AEM_Author_IP"
          /type "allow"
          }
    }
The /ignoreUrlParams is going to be the most handy thing when you have some query parameters in your request and you want them to come to your AEM instance .
By default , if any request comes to the dispatcher with a query param , it just delegates the request to the AEM instance (the renders section) . So, you bear a high risk if somebody intentionally create a script which will add dynamic query parameter to a request and send it to your dispatcher which can cause a huge load on your AEM instances and eventually break it down . This is where /ignoreUrlParams comes into action .
Note : To make use of this property your dispatcher module version should be equal to more than 4.1.2 .
/ignoreUrlParams
      {
        /0001 { /glob "*" /type "allow"  }
        /0002 { /glob "idPrefix" /type "deny"  }

      }
So, in the /ignoreUrlParams section , first we allow everything to be taken from cache and not to go to the AEM instance . Then , we specifically choose what are the requests that should go to the AEM instance . So, in the above example , we are specifying , that , the dispatcher should serve everything from cache . Then we declare , if the request URI contains idPrefix in it , then the request should be delegated to the AEM instance and not served from the cache.
allow here means that the cache request should be served from the cache. deny means that the request should go to AEM instance and not served from cache.
Following is a sample dispatcher.any file . Feel free to modify the file according to your project need .
# name of the dispatcher
/name "fadfish-server"
# Each farm configures a set of load balanced renders (i.e. remote servers)
/farms
  {
  # First farm entry
  /website
    {
    # Request headers that should be forwarded to the remote server.
    /clientheaders
      {
      "referer"
      "user-agent"
      "authorization"
      "from"
      "content-type"
      "content-length"
      "accept-charset"
      "accept-encoding"
      "accept-language"
      "accept"
      "host"
      "if-match"
      "if-none-match"
      "if-range"
      "if-unmodified-since"
      "max-forwards"
      "proxy-authorization"
      "proxy-connection"
      "range"
      "cookie"
      "cq-action"
      "cq-handle"
      "handle"
      "action"
      "cqstats"
      "depth"
      "translate"
      "expires"
      "date"
      "dav"
      "ms-author-via"
      "if"
      "lock-token"
      "x-expected-entity-length"
      "destination"

      }

    /virtualhosts
      {

      "*"
      }

    # The load will be balanced among these render instances
    /renders
      {
      /rend01
        {
        # Hostname or IP of the render

        /hostname "localhost"

        # Port of the render
        /port "4503"

        # Connect timeout in milliseconds, 0 to wait indefinitely
         /timeout "10000"
        }
     }

    # The filter section defines the requests that should be handled by the dispatcher.
    # The globs will be compared against the request line, e.g. "GET /index.html HTTP/1.1".
    /filter
      {
      # Deny everything first and then allow specific entries
      /0001 { /type "allow"  /glob "*" }
      /0002 { /type "allow" /glob "* /content/* *" }  # disable this rule to allow mapped content only
      /0025 { /type "deny"  /glob "* /common* *" } # if you enable /libs close access to proxy
      /0029 { /type "allow" /glob "* /content* *" }
      /0030 { /type "allow" /glob "* /content/dam/* *"   }
      # Enable specific mime types in non-public content directories
      /0041 { /type "allow" /glob "* *.css *"   }  # enable css
      /0042 { /type "allow" /glob "* *.gif *"   }  # enable gifs
      /0043 { /type "allow" /glob "* *.ico *"   }  # enable icos
      /0045 { /type "allow" /glob "* *.png *"   }  # enable png
      /0046 { /type "allow" /glob "* *.swf *"   }  # enable flash
      /0047 { /type "deny" /glob "* *.pdf *"   }  # enable PDF
      /0048 { /type "allow" /glob "* /content/*.pdf *"   }  # enable PDF
      /0049 { /type "deny" /glob "* *.txt *"   }
      /0050 { /type "deny" /glob "* /common/script/* *" }
      /0059 { /type "deny" /glob "* /styles/* *"   }
# Enable features
      /0061 { /type "allow" /glob "POST /content/[.]*.form.html" }  # allow POSTs to form selectors under content
      /0062 { /type "allow" /glob "* /libs/cq/personalization/*"  }  # enable personalization
      /0081 { /type "allow"  /glob "GET *.infinity.json*" }
      /0082 { /type "allow"  /glob "GET *.tidy.json*"     }
      /0083 { /type "allow"  /glob "GET *.sysview.xml*"   }
      /0084 { /type "allow"  /glob "GET *.docview.json*"  }
      /0085 { /type "allow"  /glob "GET *.docview.xml*"  }
      /0086 { /type "allow"  /glob "GET *.*[0-9].json*" }

      # Deny query
        /0090 { /type "deny"  /glob "* *.query.json*" }
    /0091 { /type "deny" /glob "* /crx[./]*" }
    /0092 { /type "deny" /glob "* /admin[./]*" }
    /0093 { /type "deny" /glob "* /var[./]*" }
    /0094 { /type "deny" /glob "* /tmp[./]*" }
    /0095 { /type "deny" /glob "* /bin/login[./]*" }
    /0096 { /type "deny" /glob "* /system[./]*" }
    /0097 { /type "deny" /glob "* /etc/packages*" }
    /0098 { /type "deny" /glob "* /libs/cq/core*" }
    /0099 { /type "deny" /glob "* /etc/replication*" }
      }
/propagateSyndPost "0"
    # The cache section regulates what responses will be cached and where.
    /cache
      {
       /docroot  "/mnt/fadfish/apache/www"

      /statfileslevel "5"

      /allowAuthorized "1"

      /rules
        {
        /0000
          {
          /glob "*"
          /type "allow"
          }
        }
      /invalidate
        {
        /0000
          {
          /glob "*"
          /type "deny"
          }
        /0001
          {
          /glob "*.html"
          /type "allow"
          }
    /0002
          {
          /glob "*/content/fadfish*"
          /type "deny"
          }

        }

      /allowedClients
        {

        /0000
          {
          /glob "*"
          /type "deny"
          }
        /0001
          {
          /glob "127.0.0.1"
          /type "allow"
          }
        }

    /ignoreUrlParams
      {
    /0001 { /glob "*" /type "allow"  }
    /0002 { /glob "blog_entries_start" /type "deny"  }
    /0003 { /glob "idPrefix" /type "deny"  }
    /0004 { /glob "query" /type "deny"  }

      }
    }

    /statistics
      {
      /categories
        {
        /html
          {
          /glob "*.html"
          }
        /others
          {
          /glob "*"
          }
        }
      }
    }
  }
Cheers !!