Association relationship between TMS and Event Service implementation of SAP Spartacus

Most customers use a Tag Management System (TMS) to add additional tags to Storefront. Add these tags to integrate into other systems, such as search or social crawlers, analytics solutions, sales systems, and more. Using a TMS will bring agility to the application life cycle, as changes can be applied without going through the development cycle.

Spartacus' goal is to support a variety of TMS vendor solutions. The most popular tag manager seems to be GTM, but we don't want to limit the architecture and technical implementation to GTM. Furthermore, CDS relies on similar concepts.

TMS solutions can be integrated via the so-called data layer. Although no official data layer standard exists, the core principle is the same: applications push data to a central JavaScript object.

Google Tag Manager (GTM) supports a flat dataLayer array on the window object, while Adobe Launch is driven by a more complex JavaScript object that calls digitalData on the window object. Neither solution seems to provide an API, so we have to manipulate these global JSOs directly.

The high-level architecture for integrating Spartacus with multiple tag managers is shown in the figure below. This example describes integration with GTM, but other tag managers can be integrated in a similar fashion.

event service

ngrx action is an important source of event system, a typical example is the use of EventService in Spartacus shopping cart component. Thanks to the common event system in Spartacus, developers can easily observe events.

To decouple from existing ngrx actions, we map ngrx actions to public EventActions under the hood. EventActions are likely to become standard in Spartacus, rather than low-level ngrx actions. This is mainly because we might consider sunset drop the ngrx implementation in Spartacus in the future.

While there are a large number of (ngrx) operations available in the Store, these are primarily driven by data integration from the backend. There are many other events that can also be taken into account, such as router events, scroll events, mouse interactions, etc. While we can start with a simple mvp to map existing storage operations, the design should not be limited to a single source of events. Multiple EventServices can be used (we can use multiple EventServices to inject tokens).

We may need to consider the event payload. The event payload can hold some (meta) data for the event. This is useful and efficient for event systems, so event subscribers don't need to collect all the data from scratch.