JECIS 2 - FAQ

Thank you all for the overwhelming interest in JECIS 2 announcement and thank you for the interesting and profound questions. Instead of answering everybody individually, I decided to put this FAQ together, which is a collection of most of the questions.

When is JECIS 2 with AEM available?

We will do our first public presentation of JECIS 2 at Evolve 19 in San Diego (August 5 - 7, 2019). Starting from August on, we will do presentations for whoever is interested.

Launch of JECIS 2 will be in Q4 of 2019. JECIS 2 is subscription based, requiring a subscription per AEM publish instance used in production. Subscriptions come with SLA-1 support.

For those who build commerce experiences, you want to become a partner to receive full support and of course a developer license. The partnership is free.

Will AEM/JECIS 2 replace AEM/Magento?

Nope, no way. It's not the intention to replace any AEM/Commerce integration, and it will never be. JECIS 2 is an extension of capabilities/options to build compelling commerce experiences with AEM.

Think of it like the time when the JCR Content Repository was first introduced. Did it replace RDBMS? Nope, it was a great addition to how we build Web experiences and it's still the foundation of AEM.

Why a new AEM/Commerce Solution?

In 2006 I did my first CMS/Commerce integration, and it was a painful experience. In 2011 I worked on a prototype with AEM/Hybris. It still was not satisfactory. But is challenging technology really the only reason to put so much effort into a new CMS/Commerce solution?

1. We are seeing more and more, that most modern Web experiences contain monetary elements, requiring some sort of commerce capabilities. It's not just pure content or pure commerce anymore. These Web experiences require a flexible system.
2. The JCR Content Repository API is the foundation of AEM, making it a powerful, content-centric CMS and top contender among analysts. An integration means that the commerce content and the commerce functionality are in another system. Why give up these unique and award-winning AEM capabilities?
3. Commerce experiences will require a lot shorter turn-around cycles for updates/improvements, than sites with "general" content. Marketers will constantly want to tweak the commerce experience to improve conversion rates. This calls for a commerce environment that is flexible, scalable and manageable by authors/marketers.
4. eCommerce is not just products, catalogs and pims anymore. Many different industries require different commerce approaches. We need a commerce environment that can be configured for different industries, like hospitality, insurances, manufacturers, etc.
5. eCommerce is not just local. The same product segments may require different market approaches depending on geography, demography or legal requirements. Such a commerce environment must be scalable and adaptable to different markets.

JECIS is a JCR-Commerce Framework that covers the above points. This makes AEM a top commerce experience contender, today and for the future.

Who is the JECIS Audience?

JECIS extends Adobe AEM's capabilities of creating commerce experiences. A couple of years ago, an analyst agency downgraded AEM for the lack of eCommerce. Today, AEM clients have the option between integrating with an eCommerce solution or use an eCommerce framework. Hence the question is now: when do you want to select JECIS, the CMS/eCommerce framework?

• When you are starting a new commerce experience project and need to look into an eCommerce environment.
• When you are in an industry, for which you want/need to adapt and customize your commerce environment (e.g. hospitality, insurance, auctions, etc.).
• When the commerce part of your Web experience isn't "big enough" to justify the investment in a 3rd party eCommerce solution (e.g. for product manufacturers).
• If you are marketing-technology savvy and want to delegate (commerce) content responsibility to marketing/business.
• If you need to ramp up a commerce experience in a short time.

Who builds Commerce Experiences with JECIS?

Our partners assist clients in planning, designing and implementing commerce experiences, with our support, where needed. We at Kleiber Digital focus on the development of JECIS.

A JECIS Partnership is free. We assist our partners in implementing "best practices", developing custom modules or cool new features. And of course we use all the valuable input from our partners to improve JECIS, constantly.

How can JECIS be adapted to other Industries?

JECIS is based on the JCR Content Repository API (aka as Oak). One of the powerful features of the JCR API is that it can create content objects dynamically. Am sure you remember the CQ/AEM "dialogs", in which you define an input control and the name used will be the property name the API creates a new content property with.

JECIS follows a similar principle. In JECIS 2, authors can modify existing JECIS features by adding new content properties. But they can also create new JECIS Features.

At Evolve 19 I will show how an author can modify the out-of-the-box commerce environment for a hotel resort. Then we create a new commerce feature, amenities, add some content and show it on the Web site.

What Commerce Features are available with JECIS?

Perhaps a screen shot says more than words!

All these commerce features can be adapted/modified by authors or superusers.

Is JECIS scalable?

Yes, JECIS is scalable in content definition as well as in functionality. At Evolve 19 I will present how we adapt JECIS for a hospitality resort and show how we create a new commerce feature "amenities".

1. The JCR Content Repository allows dynamic content creation. JECIS uses that concept to enable authors to create new commerce features (and of course edit existing ones).
2. The JECIS commerce code base is provided as an API. While the API has its core functionality, it also enables developers to add new or extend existing commerce functionality, any time.

What is the difference between JECIS API and a Commerce Engine?

When doing my first CMS/Commerce integration I noticed that the code base of most commerce solutions was rather static and siloed. In some cases it was impossible to extend anything, in others it was rather cumbersome, especially when it came to things like payments or shipping.

We decided to go with an API instead of a closed commerce engine. It's a similar concept like the JCR Content Repository API. Next to the core API, JECIS also has "abstract" classes that developers can implement, use and extend. Take for example a promotion action. While we have actions like "buy 1 get one free" or "xx% discount", developers can extend the class and write their own functionality.

JECIS API is of course under copyright, but developers can use it to build their own functionality.

Is JECIS "headless"?

The JCR Content Repository and Sling are per-se already "headless". This of course makes JECIS "headless" as well.

We actually use a headless concept to create the commerce content. Commerce content can be served to any device.

In an upcoming version of JECIS, we will extend that capability to also create commerce content from any device. This way marketers can take direct influence on their commerce experience, immediately.

At the end of the day though it all depends on how clients build their commerce experience.

How does JECIS handle Transactions?

In multi-tier solutions, transactions used to be responsible for data security and consistency. If somewhere in the process things went bad, the complete transaction needed to be rolled-back. To some degree, this is still valid in current CMS/Commerce integrations.

In a direct client-server communication, like we will have with AEM/JECIS, we can break critical transaction processes into smaller communication packages and follow on their (artificial) state. For example, if a user books a room, we "monitor" the process with states. The booking request may pass the server, but not be confirmed on a third party system. This allows developers to act on exceptions. They can decide if the whole booking process needs to be rolled back, or if the booking request is dispatched to another system, or if the booked room is flagged as "reservation" until the booking can be completed. On the other hand, if a payment cannot be processed, developers can reset the checkout to "open cart" and do not have to abort the whole purchase process.

Note: While JECIS provides the capabilities of defining process states, it leaves the implementation to the developers, giving them a lot more flexibility in how to handle exceptions within a failed transaction. It's not just "roll-back" anymore!

How does JECIS compare to Sitecore or EpiServer?

I am afraid I am too biased to answer this question directly! However, let me list three points you want to consider, when comparing different CMS/Commerce solutions.

1. With JECIS, we move the commerce content and commerce functionality from the 3rd party eCommerce system directly into AEM. Authors and developers can now use commerce content/functionality exactly the same way as they manage "general" content. This is known as AEM/Commerce Framework. Most other solutions integrate a CMS with an existing eCommerce solution. The difference is between the CMS/Commerce framework and CMS/Commerce integration. An integration typically requires a significant amount of code and micro services just to deal with the content.
2. We use JCR Content Repository concepts heavily, including dynamic property creation. This means that authors can not only add new properties, dynamically, but also create new commerce features, or even adapt the whole out-of-the-box commerce environment to their industry needs (e.g. hospitality, insurance, etc.).
3. By using JECIS you don't need a third party eCommerce solution. This not only reduces costs significantly, but also reduces infrastructure complexity and time to market for a commerce experience.

How does JECIS manage Payments, Shipping and Sales Tax?

In JECIS, we call such specific functionality "modules". E.g. a payment module is an implementation of the abstract payment class. JECIS comes with such modules (e.g. for Authorize.net, BluePay, VISA, PayPal, etc. But developers can create new modules at any given time. In addition, every module is added to the commerce environment via configuration and authors can later select which modules to use.

These modules can also connect to 3rd party APIs. The sales-tax module, for example. can use the author's configuration or connect to a 3rd party API. Remember, JECIS is by definition an API itself and can be scaled in any direction.

How does JECIS manage Carts?

From a content perspective, the Cart per-se is content that is displayed in different "states". Such states can be "open", "payment", "shipping" "delivered", etc. The commerce experience decides what states shall be used. And yes, all states are configurable too.

The purpose of a cart is to collect the items a customer intends to purchase. A lot depends on how the implementation handles a cart (e.g. single-page checkout, multi-page checkout, etc.). In fact, an implementation could even "clone" the whole cart on every state change, rather than just updating a cart state. JECIS typically stores the cart information for registered users and creates id's matching cookie id's for non-registered guest users.

JECIS creates an order based on the change of the state. This can be e.g. after payment is received, but it can also be when creating an invoice.

All the cart- and checkout states are flexible and can be defined by authors/developers!

What is Performance like with a large amount of Content?

We are JCR Content Repository experts since 20 years. And yes, we use the API to its full extent. The "secret" lays in how we define the content strategy and combine the content model with the pre-indexing capabilities of Oak.

For JECIS 1 we did benchmark tests with 100,000 clients and products each, up to 1,000,000. Performance was surprisingly good, but only if you don't require the whole content set at once! For JECIS 2 we are working on an intelligent "predictive-slice-buffer" that will leverage performance, no matter if you have 1,000 or 1,000,000 entries.

Furthermore, you can of course use Solr or ElasticSearch for content indexing and search.

Can JECIS integrate with Solr or ElasticSearch?

Yes, as with any AEM content you can configure Solr search or ElasticSearch and index all commerce content. You can also isolate digital assets from normal commerce content and index only those assets with Solr or ElasticSearch. At the end of the day everything is content!

What about other JCR-based Content Management Systems?

JECIS is fully compliant to the JSR-283 standard for "Content Repository API for Java Technology". We have tested JECIS with the following JCR-based CMS solutions:

• Jahia DX
• Magnolia CMS
• Peregrine

If there are other JCR-based CMS interested in using JECIS, please contact me directly.