Author Archive

November 25, 2013

How to fix AEM-SiteCatalyst connection problem

Cloud Serivces in CQ 5.5 / AEM 5.6 allows easy integration with other Adobe Marketing Cloud products. These enablements usually involve inputting credentials for an account that has API access privilege. Adobe SiteCatalyst is among one of these Cloud Services.



Lately I’ve seen customers not able to enable the integration even they have ensured that they put in the right credentials. They got frustrated and had to open support tickets with Adobe to address the problem. It turns out that majority of these connection issues can be fixed if you understand which SiteCatalyst data center you should be using, and how to change the configuration from within CQ/AEM.

Here I will walk you through the steps one by one:

  1. See if you can connect to SiteCatalyst using your provided credential (with Web API Access):
  2. If you’re not able to log in, then try using the same credential to log into or
  3. Once you’re logged in, you should be landed on:
    • etc.
  4. See the pattern above? the subdomain (sc, sc2, sc3, sc4, www, www2, www3, www4, etc.) tells you exactly which Site Catalyst data center you’re connected to. You should use the same data center in CQ/AEM for the integration. However, CQ/AEM is defaulted to the San Jose data center (sc, or www) out of the box. If you’re using another data center, you need to configure CQ to point to the appropriate one.
  5. To do that, go to System Console in CQ/AEM at http://<domain>:<port>/system/console.
  6. Log in and go to the configuration page.
  7. And locate the Configuration “Day CQ Analytics SiteCatalyst HTTP Client”.
  8. The Data Center URLs is defaulted to Change it to the data center you should be connecting to. For example:
  9. Click Save.
  10. Now, go back to the Cloud Services Configuration and connect again with the same credential (CQ pointing to the correct SiteCatalyst data center now), you should be able to connect successfully.
4:41 PM Permalink
November 24, 2013

AEM HealthCheck exercise

Recently I stepped into a few engagements to assess and evaluate how CQ/AEM was implemented for customers, be the implementation done by in-house developers, or via a solution partner. Since the “health check” area is a little vague, I want to use this post to list some of the exercises usually covered by such engagements. Note that some of the following might not necessarily be covered in all engagements, it varies depending based on customers needs and time given.

  • Study the solution via written documentation or direct interviews with customers and system integrators.
  • Review user interface, identify opportunities to optimize the performance for various experiences (web, mobile, kiosk, etc.)
  • Review CQ authoring process and work with customer to streamline and optimize the authoring experience.
  • Provide general performance optimization strategies including but not limited to: caching, use of CDNs, delivering the right fidelity assets at the right time, etc.
  • Provide general architectural guidance (Gap analysis between reference architecture and customer’s implementation) and environment audit.
  • Provide development and deployment best practices, including but not limited to:
    • Review templates and components for reusability.
    • Review information architecture.
    • Review OSGi configurations.
    • Review build and package management tools, source control being used, etc.
  • Code review and scoring using code analysis tools.
  • Validate the application of security checklist and go-live checklist.

At the end of the exercise, Adobe Consulting Services will compile and consolidate all the information collected, and will provide a document on all the findings from the engagement as well as suggestions and next steps.

Healthcheck is usually carried out onsite, and it typically lasts from a few days to a few weeks.

3:03 PM Permalink
August 20, 2013

How to change AEM’s redirection HTTP status code?

Redirection of request URLs in AEM can be configured at the Sling level, typically in the mapping configuration under /etc/map node. Depending on the requirements, there are times when customers would like to change the default HTTP status code for redirection. And here you will find two ways of changing the status code:

The sling:status way

Documented in already, you may use sling:status property to set a specific status code for a particular redirection. To extend the example given on the page linked above:

      +-- http
           |    +-- sling:redirect = ""
           |    +-- sling:status = "301"

Via OSGi configuration

Another way, which really sets the default for all redirection, is to configure the status code at the OSGi bundle level. In the OSGi console, browse the the Configuration page and locate:

“Apache Sling Resource Resolver Factory”

and change the redirect status field to whatever status code is appropriate (highlighted in diagram below).

Sling redirection status code


4:50 PM Permalink

How to send an AEM dispatcher flush request via cURL

In the “Invalidating Cached Pages from AEM” document on, there is a brief section covering how to invalidate dispatcher cache manually. It only talks about sending HTTP requests to the dispatcher and it briefly touches on the format. So, where’s the quick (and dirty, if you will) command? Anything for me to copy and paste and get the job done?

Here you go:

curl -H "CQ-Action: Activate" \ 
     -H "CQ-Handle: /content/bar" \ 
     -H "Content-Length: 0" \
     -H "Content-Type: application/octet-stream" \ 

Of course you will have to replace the content path and the host/port.

If you ever need a “hook” to get a custom set of files to be invalidated from the dispatcher, for whatever reason, put the above into a script in any *nix environments (where cURL is supported) should do the job for you. Oh, did I forget to mention that you can actually trigger a command from an AEM workflow? You get the idea :P


4:09 PM Permalink
May 17, 2013

Firewall rules for typical CQ Author-Publish-Dispatcher setup

I came across a few projects in the past that required CQ implementations spanning multiple data centers thus needing tons of firewall rules. Like many enterprise environments, the process of filing firewall requests (to open a few holes), to scheduling outage windows and all the way to getting the rules in place, can easily take up a week or two, if not days. Not to mention that the same process probably have to be repeated multiple times (DEV, QA, Staging, Production…). This is especially hard if your organization is using CQ for the very first time, as there are rules usually missed.

So I wanted to use this post to capture the port that should be opened in a typical CQ set up. In the following tables, I’m assuming:

  • CQ Author running on default port 4502
  • CQ Publish running on default port 4503
  • Dispatcher/Webserver running on port 80/443.

Replication from CQ Author to CQ Publish

| Source Server | Source Port | Destination Server | Destination Port |
| CQ Author     | 4502        | CQ Publish         | 4503             |

Cache Flushing from CQ Publish to Dispatcher

| Source Server | Source Port | Destination Server | Destination Port |
| CQ Publish    | 4503        | Dispatcher         | 80 / 443         |

Clustering CQ (2 instances)

| Source Server   | Source Port | Destination Server | Destination Port |
| CQ (Auth1/Pub1) | 8088        | CQ (Auth2/Pub2)    | 8088             |

Range of ports listed at

Reverse Replication from CQ Publish to CQ Author

| Source Server | Source Port | Destination Server | Destination Port |
| CQ Publish    | 4503        | CQ Author          | 4502             |

Dispatcher retrieving published content

| Source Server | Source Port | Destination Server | Destination Port |
| CQ Dispatcher | 80 / 443    | CQ Publish         | 4503             |

If there is a dispatcher sitting in front of Clustered Author

| Source Server     | Source Port | Destination Server | Destination Port |
| CQ Author         | 4502        | Author Dispatcher  | 80 / 443         |
| Author Dispatcher | 80 / 443    | CQ Author          | 4502             |
| CQ Author1        | 8088        | CQ Author2         | 8088             |

And finally, there are also services being integrated. An example would be port 389 for LDAP / Active Directory. Don’t forget those!

9:35 PM Permalink