Adobe recently announced a new release of their Commerce Integration Framework (CIF) with a fresh new architecture and design that dramatically changes Adobe’s ability to integrate with commerce applications. Adobe I/O powers the framework and is Adobe’s new serverless offering that they are planning to release together with CIF in the third quarter this year. The new cloud-based offering integrates commerce platforms and other third party applications with the entire Adobe Experience Cloud, not just Adobe Experience Manager (AEM), using a microservices architecture.
The following diagram outlines the interoperability with the new framework. Adobe I/O will power the new framework driven by a microservices architecture and common data schema. This blog will provide more details on the following areas to provide a better understanding of the framework:
- Adobe I/O Runtime
- Microservices (Action Sequences) for business functions
- Sample flow of a microservice
- Common data model definition
- Benefits of the new framework
- Potential Risks for Early Adopters
Adobe Commerce Integration Framework Interoperability
Adobe I/O Runtime
The CIF all comes together in the Adobe I/O runtime. Adobe I/O is a cloud-based, server-less platform that provides developers with tools to deploy custom code as microservices, or action sequences, using standard javascript. The services architecture is based on OpenWhisk actions, which are the main building blocks of the new serverless, commerce microservices. These microservices, or OpenWhisk actions, run on the Adobe I/O Runtime inside an isolated container, stateless and serverless interacting with the commerce backend systems or other third party systems.
The new platform will be hosted on Adobe’s infrastructure, supporting not only the CIF integrations but also interactions between Adobe Cloud products using Adobe’s common APIs. Adobe has designed I/O to handle high-performance loads with auto-scaling capabilities necessary for many commerce deployments that experience peak loads at various points throughout the year.
To isolate customer implementations, Adobe I/O provides organizations with unique namespaces to build custom actions or to extend existing CIF actions as needed. These namespaces provide version control of the deployed actions and are unique to each implementation.
Customer Namespaces and CIF Action Sequences
Microservices (Action Sequences) for business functions
Action sequences, also known as microservices, are the building blocks of the CIF. Adobe will offer a number of common actions to perform commerce-related functions. These microservices are small, modular sets of storefront services providing specific business functions suitable for all channels. Developers can extend these storefront services or develop new ones to support various omnichannel experiences.
Each of these action sequences can be accessed using a common REST-based API to call the appropriate microservice from Adobe Experience Manager (AEM) or any Cloud product with JSON request and response data formats. Developers fluent in javascript can extend or create action sequences and deploy these discrete modular microservices into the Adobe I/O framework as serverless functions.
Adobe’s goal is to provide a comprehensive and extendable set of commerce storefront APIs available across all channels. The following are examples of microservices defined as action sequences in the I/O Runtime environment:
- Get a list of top-level categories from the commerce catalog
- Get a list of products in a category
- Get product detail information with a list of product variants
- Login a customer
- Add an item to a cart
- Get current cart contents
Sample flow of a microservice
To illustrate the invocation of an action sequence, consider the following simple scenario. A shopper wants to navigate the commerce catalog to view products and offers. Using Adobe Experience Manager’s WE.RETAIL sample application, a shopper needs to hover on the ‘Products’ menu option to bring up a list of top-level categories. This action or event of hovering on ‘Products’ triggers an action sequence to retrieve the list of categories from a back-end commerce system such as Magento.
The sequence of events are as follows:
- User hovers on the Products menu option which triggers invocation of a ‘getCategories’ REST action sequence
- The action sequence calls the appropriate Magento REST API to retrieve the list of top categories
- Magento returns the list of categories to the action sequence and the Magento response is transformed to a common data model layout
- AEM’s WE.RETAIL application receives the standard response and displays the list of categories
Sample Flow of an Action Sequence (Microservice)
Common Data Model Definition
To support these common interactions, CIF defines a common commerce data model to support multiple platforms. The anticipation is that all commerce applications will be unique and that these data models are adaptable to suit the specific implementation and business process. AEM and other products in the Experience Cloud will use these common definitions to communicate with any back-end commerce system using the standard JSON format of the data model.
By defining a common schema, CIF provides a framework for communication to commerce platforms for all Adobe Cloud products. As an example, the following is a subset of common definitions used in the new framework:
- Address
- Cart
- Category
- Discount
- Login Result
- Order
- Payment
- Product
- Shipping Info
- Shipping Method
- Tax Info
Benefits of the New CIF
Adobe has completely rewritten the entire integration framework and they have changed the architectural approach to integration. One of the key improvements not to be overlooked is that the catalog is now rendered dynamically via microservices from the commerce platform. The prior version required synchronization of catalog data into AEM. Products were synchronized into AEM and tagged, catalogs and categories required manual creation and a separate page generated for each product.
This introduced a number of problems as well as manual processes to build the catalog navigation in AEM and also eliminated core product entitlement capabilities central to most commerce and more specifically B2B implementations. Larger catalogs and dynamically changing catalogs were also problematic requiring a complex re-publication process, prone to error with checks and balances to ensure proper synchronization.
Dynamic catalog rendering through microservices eliminates this problem and natively allows the catalog to be managed by the commerce system which typically provides a robust method of defining and managing products as well as managing entitlements for B2B accounts.
Some additional advantages of the framework include:
- Modular microservices offering allowing common access to commerce functions across the entire marketing cloud and not just AEM
- Reduced time to market to develop and customize complex omnichannel scenarios and to adapt to changing market conditions
- Dynamic catalog access allows the commerce system to manage product entitlement
- Supports entire marketing cloud
- Open JavaScript programming model improves productivity and access to qualified resources
Potential Risks for Early Adopters
As with anything new, a new framework means it has yet to be battle tested. Some open questions about the new platform will play out with the first adopters of the framework. Will the framework scale as advertised for customer during peak periods? What kind of support will Adobe provide for the I/O Runtime to troubleshoot critical downtime issues? Will the framework be stable and provide the isolation needed so that organizations experiencing issues do not affect other implementations?
Additionally, a new framework and skill set needs to be adopted, learned and implemented adhering to the new framework concepts. New technical resources need to be educated and trained. Adobe needs to identify best practices around extensibility of action sequences and the data model to ensure future compatibility.
Each commerce platform also brings its challenges. Some platforms have out of the box REST services made for an external headless commerce experience. Others provide REST services but lack the granularity or the data payload to be effectively integrated without customization. This can always add significant time and complexity to a project and the commerce platform will need evaluating to determine the readiness of the platform.
To learn more about the Adobe Magento acquisition, and how we can help, click here.
Hi Patrick, that’s an amazing write up to summarize the integration. One quick query- how do you see the rest API security aspect being handled in this integration ?
Hi Nipun,
Good question and there are several layers to security to be considered. Each namespace with the CIF framework has a corresponding authorization code generated by Adobe specifically for that namespace and organization. To update/create action sequences will require this security auth id. Action sequences can also be versioned to provide backward compatibility to all systems if a major change has been made. Communication between components is via SSL to secure the transport.
Now, most commerce systems also have their own security layers as well. Magento, for example, requires an authorization token to be included in the REST header that corresponds to a guest or registered identity. The same holds true for other commerce platforms as well such as IBM Commerce and Oracle. Configuration connectivity should be managed during the implementation to validate configuration settings such as store id, catalog id, identity can only be retrieved from a valid source.
Hope this helps.