Author Archive

April 19, 2018

Brett Birschbach #AEMRockstar 2018

It’s a wrap! Adobe Summit NA 2018 is done, and we are excited to announce the winner of this year’s #AEMRockstar competition:


Brett Birschbach from HS2 Solutions


This year brought more outstanding submissions than ever, resulting in a fantastic field of semi-finalists. Congratulations to Brett and our other finalists, Bryan Williams, Joost van Dun, and Conrad Woeltge, who competed in front of an audience of 300 AEM enthusiasts! 

Brett (a previous CM guest blogger) has written a great post about his winning Rockstar Tip & Trick. He is the lead Adobe Marketing Cloud Solutions Architect for HS2 Solutions, a digital transformation company based in Chicago. He is a hands-on problem solver with experience leading large multinational, multi-site platform projects. Read on below: 


AEM Remote Assets –

Sync What You Need, When You Need It


Have you ever wanted to use AEM Assets on one server from AEM Sites on another? I bet you have, even if you don’t realize it. Until now, options to do so would have been custom and/or manual, so you may have simply blinded yourself to the idea. Here are some common uses cases that you’ve probably run into:


Use Case: Enterprise AEM Assets Instance

Ok, I admit this is probably not the most “common” use case, but for large enterprises in the digital age, it’s a critical use case. An enterprise DAM is a key part of an enterprise technology stack, often calling for a dedicated AEM server with DAM as its sole purpose. But then how do you use those assets for your AEM sites?


Use Case: Migrating Assets from Production to Non-Production Environments

Does your organization have Dev/QA/Stage AEM environments? Of course, it does. Are those environments consistently up to date with the latest set of assets from production? For almost everyone I talk to, the answer is almost invariably a resounding “No.” How can this be done in a way that is both automated and disk efficient?


Use Case: Site Assets for Local Developer Servers (i.e., localhost:4502)

Pulling down a copy of the production site pages to a local server is easy. Pulling down all of the assets associated with that site? Not so much. How can this be done in a way that leaves behind assets that are not applicable to the site?

A simplistic, brute-force solution might be to use AEM’s package manager to bundle up the entire DAM, copy it down to the Sites server, and call it a day, right? Not exactly. Assets are big…and numerous… Last I checked, numerous big things is rarely a simple situation. Copying the entire DAM can be problematic in terms of disk space, network transfer, and effective package sizes. And even if you can do it manually, as soon the first asset on the remote server changes, you’re out of date!

Ok, so why not just reference the assets directly from their remote location? This would be a nightmare for your authors and developers, no longer able to leverage simple OOTB tools like image components, DAM search, and the authoring sidebar. Ultimately, you’d no longer be able to leverage the full power of AEM sites.

In short, you need a solution that achieves all of the following objectives:

  • Access to all remote AEM Assets from the AEM Sites instance
  • Remote AEM Assets stored locally in AEM Sites for seamless authoring w/OOTB features
  • Copies of just the required remote AEM Assets, not the entire DAM
  • All accomplished in an automated fashion


Sync What You Need, When You Need It

AEM Remote Assets tackles this tricky problem in a unique way. The seemingly opposed objectives of “Access to all remote AEM Assets” and “Copy of just the required remote AEM Assets” are achieved by a “sync what you need, when you need it” strategy. What this means is the automated asset sync first copies the entire node structure from the remote DAM, pulling in the tags and metadata of all of the remote assets but leaving behind the large binary files in the source DAM. If and when any of these assets are requested for a real use case, only then does Remote Assets copy the binary files “just in time” via a second sync, leaving behind all of the other asset binary files that are not needed.

Let’s see how this works in practice. AEM Remote Assets first syncs in the node structure of the remote AEM Assets, substituting in a small, temporary binary file to keep all unused assets very small compared to their real counterparts.

Admin user viewing folder of remote assets on an AEM Sites instance.

As an admin user on the AEM Sites instance, I can see all of the “remote” assets that have been synchronized from the remote AEM Assets server. And though an asset may say it is 500+ KB in size, in actuality it is far smaller due to the temporary binary file.

Now the true magic begins. Because we have synchronized in all of the remote asset nodes and tags, we have everything we need as an author to search and use those assets, and AEM will take care of pulling over the binary files for the ones I want to use. Say for example I open a browser and search for “Bike” assets. The system finds the two assets, but as the request is being processed it first pulls over the associated binary files from the remote Assets server, making those two assets now “real” on the Sites server.

Right: Author user viewing two searched assets; Left: Admin user viewing folder with searched assets now made “real.”

The same thing happens if I pull up the page authoring sidebar to add an image to my page.

Right: Author user choosing asset from page authoring sidebar; Left: Admin user viewing folder with referenced asset now made “real.”

This is amazing for the “Enterprise Remote AEM Assets” use case, where authoring sites with remote assets is a critical business function. But what about the use cases of “Migrating Assets from Production to Non-Production Environments” and “Site Assets for Local Developer Servers” where largely we just want to be able to browse the site with all assets. Turns out that scenario (and any others you can think of) works as well.

Right: Web page as seen by an author user, all assets being made “real” simply by browsing to the page; Left: Web page with remote assets before access by an author user.


This is Awesome! Can I Has AEM Remote Assets Too?

You absolutely can! HS2 Solutions has contributed AEM Remote Assets to ACS AEM Commons, the most prominent open source feature library for AEM in the industry. You’re probably using this library already! We look forward to the community pitching in with their ideas on configuration options, additional functionality, and even direct code contributions!

For more on AEM Remote Assets, including a video demonstration, view my article on You may also contact me via LinkedIn or email at

All opinions are Brett Birschbach’s own and are not Adobe’s.

4:31 PM Permalink
August 30, 2017

Tips & Tricks: Link Tag Management for AEM

We are back with another Rockstar Tip & Trick guest post from Steven Carter, who is a Web Developer for HS2 Solutions, a digital transformation company based in Chicago. Like our other guest bloggers, Steven was a runner up in this year’s AEM Rockstar competition. For more from Steven, connect with him on LinkedIn ( or GitHub (

Link Tag Management for AEM

Links (anchor tags) are a ubiquitous part of any site, and yet as developers, we hardly give them a second thought. We tell the link where we want the user to be directed to next, and that is generally the extent of the consideration needed for them to work properly. On an AEM site, however, there are a few additional dimensions to the thought process that we need to consider. Will this site be internationalized? Does the label for this link need to be translated, or the target address changed for the internationalized version of the page? For example, say you have an external link pointing to, but on the Spanish translated version of your site, should that external link instead be  Should this link be opened in an external window or tab instead of in the current tab? These considerations and more can be addressed easily if a little planning and forethought are put into the way you add links to the page. By adding a custom JSTL tag to resolve links before adding them to our templates, we have been able to exercise considerable control over our links and can add to this functionality even years after the site was initially built.

Fig. 1: Here is an example detailing the usage of our resolveLink tag. The path is passed to the tag, and then the resulting map of properties is returned into a variable. We can then access specific properties, such as the “resolved” link href, label, or the target attribute and place those within the anchor tag.

Getting Started

The first step in managing your links is adding a simple tag that can take a link and “resolve” it, and then use that tag for every link on your site. This tag takes the link address and applies rules and other behaviors to alter the final link. In the next few sections, I’ll give some examples of different alterations we perform to the final link. Before we get into those specific examples, I want to point out that since we pass all of our links through this tag before they are rendered on the final page, we have a lot of control. As an example, let’s say that months after a site was built, we decide the links going to a certain portion of the site should open in a new tab. Instead of returning to the templates and identifying all of the links that point to that section of the site, we can simply add a new rule to our link resolution tag. A quick substring match and we can update the anchor tag target attribute as desired.

Internal vs. External links

One of the first checks we added to our tag was to identify whether the href attribute pointed to an internal (served by our AEM instance) or an external location. Since we would like to keep the user on the site, all external links should be opened in a new tab or window.

Translation of External URLs

One item that is easy to overlook when translating a website is the external websites. As an example, while is the correct domain for English users, your Spanish users should ideally be linked out to It’s also possible that if you’re linking to an external site somewhere, that the paths may completely differ based on the language. Both of these scenarios are easily handled by a link resolution tag.

Automatic Generation of Link Label

For internal links which point back to a page on our internal AEM site, we use the page’s navigation title as the default link label. This prevents the need for a content author to set a label for each link they might add to a page and allows for easier link generation for components that automatically construct a link tree. For sites that are translated, the navigation title will already have been translated, so this is one less item that needs to have a translation added for each language.

Externalizing Paths

In some cases, we want the final path provided from this tag to be externalized. That is, it has the virtual host instead of the internal publish server address. We created our own code to handle the externalizing of these paths to provide us more control over the final path. We also have a Boolean attribute on the resolveLink tag so that we can choose when we want this externalizing code to run, as there are some cases where we may want the path externalized.

Append Extension or Sling Selector

Here’s another case where we have a Boolean attribute added to the resolveLink tag to modify what we’re asking the tag to do for us. In this case, we default the attribute to true, because in most cases we want an extension to be appended to the final path. Now, when the author uses the pathbrowser widget to select a path (which typically only points to the JCR node, and does not supply its own extension) we can add the required extension to the URL. This is also powerful if you have need of custom sling selectors, which can be added to the URL before the extension is appended. The addition of these extensions is another place where our earlier check for internal vs. external links is helpful because extensions should never be added to external URLs.


When using the AEM launches feature, we sometimes wanted to have a little more control over where content was being loaded from. Say for example we have a component that pulls its content from a path, but the content from that path is not included in the launch. With our launch path resolution code, we can verify if the data exists at the launch path and fall back to the base site automatically if the content does not exist there.

Final Thoughts

As with most things in the programming world, you will be rewarded if you plan ahead and are diligent in your implementation. If every link is resolved with a custom tag before being added to your templates, you can exercise a lot of control and simplify fixes and other adjustments you might need at a later time. You could compare this to always using an i18n tag when displaying text on pages, which pays dividends later when you begin to internationalize your site.

All opinions expressed by Steven Carter are his own and not Adobe’s.

1:26 PM Permalink
August 29, 2017

AEM Best Practices are Live on the SPP

If you haven’t visited the Solution Partner Portal (SPP) lately, it has an updated training experience that includes a new series by our team, Adobe Partner Experience (APx). These Implementation Best Practices, written by our team of expert Technical Architects, are drawn from our experiences implementing solutions across Adobe Experience Cloud Platform. Our first installment features articles related to Adobe Experience Manager, but we have upcoming articles on how to access resources for all the solutions, and also a series on Campaign Best Practices. 

The following APx Best Practices are now published on the SPP. Click the title to be redirected to the full article.

Multitenancy and Concurrent Development in AEM: An analysis of the types of issues that a business might face when attempting to implement AEM, using multiple teams of developers and trying to meet the demands of multiple brands.  Explore strategies for mitigating risks and driving communication and efficiency in project delivery.

Performance and Load Testing AEM – Author Basics: Explore the topic of load and performance testing and the basic best practices for ensuring a successful go live by utilizing tools such as JMeter and ToughDay.

Continuous Integration for AEM: Learn more about three commonly used tools that are central to the continuous integration process:

  • Jenkins: used for continuous integration, version control, and the compiling, testing, and deployment of your code.
  • SonarQube: used for code analysis and to track and measure code quality and technical debt.
  • Nexus OSS: a free repository manager that allows for the mirroring and storage of Maven dependencies.

The new training experience on the Solution Partner Portal has combined all of Adobe’s best training content in one place. Resources are organized by Solution and by role, and the on-demand training is now powered by Adobe Captivate Prime. You’ll also find new Partner Learner Journeys that will guide you through which trainings to take to achieve certification.

Stay tuned for details about our APx Best Practices webinar, which will be presented by Ian Reasor, an A.C.E Architect from Adobe Partner Experience team. 


2:12 PM Permalink
June 12, 2017

AEM Multi-Site Tips & Tricks

And…..he’s back! We are excited to share another post in the AEM Rockstar Tips & Tricks Guest Blog series! This Tips & Tricks post is a follow-up from Brett Birschbach, an AEM Certified Architect and AEM Rockstar semi-finalist who presented at Adobe’s global virtual developer conference, IMMERSE 2017. Brett previewed his Tips & Tricks in a preview post before IMMERSE. As promised, he’s returned to share more from his presentation. 

Brett is the Adobe Marketing Cloud Solutions Architect for HS2 Solutions, a digital transformation company based in Chicago. He is a hands-on problem solver with experience leading large multinational, multi-site platform projects.  Brett led the development of the new Shared Component Properties feature in the open-source ACS AEM Commons library. For more from Brett, connect with him on LinkedIn,  ( ) or visit his Github: HitmanInWis.


AEM Multi-Site Tips & Tricks – Top 3½ Tips from IMMERSE 2017


Faced with a multi-site project and looking to get off on the right foot?  As mentioned in my previous article, most mature AEM installations involve multiple sites, but nearly all began as a single site before expanding to support more.  Why should you care about “getting it right” up front, rather than figuring it out as you go?  Well…

  1. Multi-site code structures don’t happen by default.
  2. Setting up the right structures makes it easy for developers to do the right thing.
  3. Getting multi-site wrong early will haunt you as long as the sites live.

But hey, I don’t need to convince you of this, or else you wouldn’t invest your time into this article.  You’ve got sites to write, and lots of them!  So let’s get right to the good stuff – the tips most voted as new/helpful by the attendees of the Adobe IMMERSE session on Multi-Site Platforms – Setting your Codebase Up for Success.  These tips were demonstrated in the context of coding a multi-site platform for a fictitious football league (HFL) including the Green Bay Peckers (Go Peck Go!) and Chicago Boars (a.k.a. Chicago Bores), the demo of which is available to download at the bottom of this article.


Tip #3-1/2 – Leverage the Page Root Provider in ACS Commons

IMMERSE Presentation Time Slots: 18:21-19:24, 27:04-28:09

OSGi Configs for Page Root Provider:

Coming in at a virtual tie in votes with Tips #3 and #2, the Page Root Provider in ACS Commons earns the distinct honor of being Tip #3½ by playing a supporting role making Tips #3 and #2 possible.  The Page Root Provider in ACS Commons gives your code a simple, reliable way to determine the homepage of the site pertinent to the request being processed.  This allows you to:

  • Write OSGi services and components with generic code that executes on content specific to the applicable site.
  • Easily reference the homepage node from code for complex use cases as well as simple tasks like rendering a link to the homepage.


Tip #3 – Use the “Contextual Path Browser” Field

IMMERSE Presentation Time Slots: 19:24-20:12, 28:09-29:05 

OOTB Path Browser Field:


Contextual Path Browser Field:

Frankly, I was blown away by the popularity of this tip–it is such a simple and narrow concept compared to Tips #2 and #1.  The tip’s simplicity, however, is offset by its even simpler effort to implement.  The Contextual Path Browser field in ACS Commons (sling:resourceType = acs-commons/touchui-widgets/contextualpathbrowser) is a drop-in replacement for AEM’s OOTB Path Browser field with one powerful improvement – the ability to limit the author to the “context” of the site on which the component lives.  The main benefits include:

  • Less clutter and clicks for authors, automatically putting them where they need to be.
  • Authors working on multiple sites are far less likely to accidentally navigate into an incorrect site and potentially create invalid links.


Tip #2 – Use Shared/Global Properties

IMMERSE Presentation Time Slots: 20:13-22:09, 29:05-30:31

Component Supporting Shared and Global Properties Dialogs:


Shared Properties Dialog – Properties Shared Across All Pages within a site:


Global Properties Dialog – Logo Shared with Header:

Tip #2 comes as a long-awaited boon to battle-hardened AEM developers, who have custom-built support for “global properties” again and again. Developers try to ease the burden on authors for component values that need to be repeated on multiple pages of a site, but that authors don’t want to have to set (and maintain) on every page.   Often, it is tempting to hard-code these values, but that has limitations in that it doesn’t allow authors to change the values (the opposite of a CMS) and it doesn’t allow the value to differ between two sites.  Shared Component Properties in ACS Commons solves both of those issues, allowing a property to be set once for an entire site, but still different on individual sites.

Take the “Tout” component in the images above that links off to the Schedule page.  This component needs to link to the same page and have the same copy on all pages of the Green Bay Peckers site, but have a different link and potentially different copy on the Chicago Boars site.  Shared Component Properties allows this component to do just that, with no specialized coding on the part of the developer.  The “Tout” component also renders the team logo on all pages, another great use case for Shared Component Properties.  Because the site header also uses that logo, however, a “global” property dialog is used to share the logo between the two components.

There are numerous applications of Shared Component Properties, even in non-multi-site solutions.  I encourage you to check out the main documentation page for Shared Component Properties to learn more.  In summary, benefits include:

  • Allowing repeated component copy and configs to be authorable without putting a burden on authors to maintain on multiple pages.
  • Allowing shared properties to be internationalized via standard AEM translation (as opposed to a solution using the design dialog).
  • Sharing properties within a sling:resourceType (termed “shared” properties).
  • Sharing properties across sling:resourceTypes (termed “global” properties).
  • Ability to simplify headers, footers, and other site-wide content to no longer require the use of an iparsys.

For a deep dive on Shared Component Properties, check out my article on Shared Component Properties.

Tip #1 – Add a Living Style Guide to Each Site

IMMERSE Presentation Time Slots: 34:57-37:49, 42:10-43:36 

Green Bay Peckers Style Guide vs Chicago Boars Style Guide

Let’s just call this tip “the secret to make everyone like you.”  When this tip came in as the top voted tip, I can honestly say I wasn’t surprised.  Why?  Simple – it is extremely useful, everyone (especially clients) loves it, and it costs you nothing to implement.

Living style guides are so highly touted by UI designers, front-end developers, and marketers, that the term is a buzzword applied to nearly all style guides these days, regardless of whether they are actually living.  However, when you do a living style guide in AEM, you get the real thing.  Because the style guide is rendered by AEM using real live code, it is guaranteed to be 100% up to date at all times.

Though few people will argue against the usefulness of a living style guide, many will claim that such a construct is too expensive to produce and maintain.  I’ll be the first to admit that I was originally a skeptic sitting in this camp.  However, after having done this on multiple projects, I’ve come to a new realization – a living style guide in AEM is effectively free.  Here’s why:

  • Your front end developers are already authoring components in all of their variations in order to style them. As such, the only overhead for a front-end developer is the original setup of the style guide page structure (perhaps a day) and incremental overhead of exporting their authored content from AEM to the codebase (literally seconds).
  • Your QA personnel is likely testing components by authoring them completely from scratch, repeating the work that is already being done by your front-end developers. With the style guide exported to the code base and thus deployed to AEM, along with the code changes to test, your QA team will often now be 75-100% set up for their component testing, recouping any extra time (and likely more) spent by your front-end developers creating and maintaining the style guide.
  • Because a complete style guide requires all variations of the component to be displayed, it is a forcing factor to ensure your developers actually work through all variations, thus reducing the number of bugs that make it to QA in the first place.

Your economics professor probably drilled into your head that “there’s no such thing as a free lunch,” but when it comes to AEM living style guides your professor was wrong!  Benefits of a living style guide include:

  • 100% up-to-date rendering of site components in a consolidated, easy to navigate location.
  • The ability for developers to easily verify a styling change across multiple sites and components.
  • The ability for marketers to see what a new brand site and/or styling scheme will look like with very little development time and effort.
  • Fewer bugs that get to and/or through QA.

But wait, there’s more!

…says the infomercial trying to sell us the latest widget, I know I know.  But there really is more to multi-site tips & tricks – 12 more tips to be exact!  Each principle covered in the IMMERSE session on Multi-Site Platforms – Setting your Codebase Up for Success received numerous votes as being new and/or helpful to attendees – the ones covered here are just the start.  If you’re able to access the IMMERSE site and view the entire presentation, it will be time well invested.  Otherwise, download the presentation deck and associated code demo to dig directly into the details yourself.  As always, please reach out if there’s any way I can help! You can contact me on LinkedIn or email

All opinions expressed by Brett Birschbach are his own and not Adobe’s.

6:00 PM Permalink
May 22, 2017

AEM – Circuit Breaker Innovation via a Hystrix Integration

From time to time the Adobe Partner Experience (APx) team has the privilege to check out some truly innovative stuff. Yogesh is a great guy and offered to show us a cool integration pattern that he has been working on. We liked it so much that we decided to let him share it with the world via the Content Management blog. – Darin Kuntze @DarinKuntze

Yogesh Kulkarni is an experienced Adobe AEM/CQ developer/architect specializing in best practices for designing connected digital experience using AEM technology stack.

He is currently working for AKQA (a digital agency) as a Senior Software Engineer (Adobe AEM/CQ).

AEM 6.1 SP1 – Hystrix Integration

We had a requirement where the client wanted to add the Circuit Breaker pattern to an AEM component which calls RESTful endpoints, to support the following use cases:

  • If more than 10% of the calls fail within a minute then the circuit should trip.
  • After the circuit is tripped, the system should periodically check if the external service API is back up and working using a background thread.
  • The component prevents users from experiencing a sub-optimal response time.
  • The component should present a user-friendly message in case of any service failure.

Circuit Breaker Pattern

In our case, the component is responsible for making a call to RESTful endpoints to register/log in the user and provide an option to update related data/content after login.

The Circuit Breaker pattern can handle remote resources and service call failures more gracefully. It can prevent an application from repeatedly trying to execute an operation that’s likely to fail, allowing it to continue without waiting for the fault to be fixed or wasting CPU cycles while it determines that the fault is long lasting. The Circuit Breaker pattern also enables an application to detect whether the fault has been resolved. If the problem appears to have been fixed, the application can try to invoke the operation once again.

Hystrix  (a Netflix library) has a built-in ready-to-use Circuit Breaker. When we apply a Circuit Breaker to a method, Hystrix watches for failing calls to that method, and if failures build up to a pre-defined threshold, Hystrix opens the circuit so that subsequent calls automatically fail. While the circuit is open, Hystrix redirects calls to the method, and they’re passed on to a specified fallback method.


OSGi Dependencies

In order to get Hystrix running in AEM, you need to install the following dependency bundles in Felix.

Artifact ID(s) Version
1 org.apache.servicemix.bundles.hystrix 1.5.9_1
2 org.apache.servicemix.bundles.hystrix-event-stream 1.5.9_1
3 rxjava 1.2.9
4 org.apache.servicemix.bundles.commons-configuration 1.9_2
5 com.diffplug.osgi.extension.sun.misc 0.0.0
6 HdrHistogram 2.1.9


Apply the Circuit Breaker Pattern

Netflix Hystrix looks for any method annotated with the @HystrixCommand annotation and wraps that method in a proxy connected to a Circuit Breaker so that Hystrix can monitor it.

The code to be isolated is wrapped inside the run() method of a HystrixCommand similar to the following:



public class HelloServiceGetCommand extends HystrixCommand<HelloResult> {

private final HttpGet httpGet;

    public HelloServiceGetCommand(final HttpGet httpGet) {

     LOG.debug("Is CC breaker open " + isCircuitBreakerOpen());
      this.httpGet = httpGet;
    protected HelloResult run() throws IOException {

       //your logic goes here
        CloseableHttpClient httpClient = HttpClientBuilder.create().build();

        LOG.debug("Health count : TotalRequests " + metrics.getHealthCounts().getTotalRequests());        

               //call httpClient.execute


               //catch any error and populate HelloResult object

               return helloResult;




To handle the failure of external services, Hystrix has built in the following defaults:

  1. Timeout for every request to an external system (default: 1000 ms)
  2. Limit of concurrent requests for external system (default: 10)
  3. The Circuit Breaker to avoid further requests (default: when more than 50% of all requests fail)
  4. Retry of a single request after the Circuit Breaker has triggered (default: every 5 seconds)
  5. Interfaces to retrieve runtime information at the request and aggregate level (there’s even a ready-to-use realtime dashboard for it) * Yet to be defined in OSGi.

Simple Fallback method using Fallback: Stubbed pattern:

protected HelloResult getFallback() {

         LOG.debug("FALLBACK : is CC breaker open {} isResponseTimedOut() {}             isResponseTimedOut() {}",  isCircuitBreakerOpen(), isResponseTimedOut(),isResponseThreadPoolRejected());

LOG.debug("Health count : TotalRequests {} ErrorPercentage {} ErrorCount {}", metrics.getHealthCounts().getTotalRequests()
            , metrics.getHealthCounts().getErrorPercentage()


// returns error object to service to send it to FE

return getHelloResultError();

The fallback method returns the error code which is then consumed by a UI component.

How to Run Hystrix Command

There are many ways to run the command. Following simple call is triggered from HelloServiceImpl to invoke Hystrix command.

public class HelloServiceImpl implements HelloService {


  private callCommand(){

    new HelloServiceGetCommand(getRequest).execute();

   //other service logic goes here



Hystrix Runtime Configuration

Configuring a Hystrix command details can be found here: Hystrix Configuration. It is simple to update the configuration.

For example, the default value for circuitBreaker.requestVolumeThreshold is set to 20. We override the property using HystrixCommandProperties.Setter, as shown below.

public HelloServiceGetCommand(final HttpGet httpGet) {
            .withGroupKey(HystrixCommandGroupKey.Factory.asKey("HelloGroup "))
                    andCommandKey(HystrixCommandKey.Factory.asKey("HelloGroup ")));





A dashboard for monitoring applications using Hystrix is available in the hystrix-dashboard module. However, hystrix-dashboard has not been deployed to our AEM instance at this time.

1) Circuit Breaker is close at the start

DEBUG [hystrix-HelloGroup2] com.akqa…services.commands.HelloServiceGetCommand CC breaker open false

All HelloCommand requests are going through.

2) Now FAILURE occurs

DEBUG [hystrix-HelloGroup-2] com.akqa…services.commands.HelloServiceGetCommand CC breaker open True Events[SHORT_CIRCUITED]

3) Lastly, CB is closed once host is back online.

DEBUG [hystrix-HelloGroup-2] com….services.commands.HelloServiceGetCommand CC breaker open false

The example above just scratches the surface of how to improve the Service Resilience in a Felix container using Hystrix. The following resources can provide more advanced tricks to help make your application more fault tolerant.


As demonstrated, it is possible to use the state-of–the-art, industry standard fault-tolerance library Hystrix in AEM to protect your service against cascading failures and to provide fallback behavior for potentially failing calls.


All opinions expressed by Yogesh Kulkarni and are his own and not Adobe’s.


11:14 AM Permalink
  • Authors

  • Archives

  • Developer Resources