From our Depsters June 24, 2019
A Decoupled Technical Solution
OMRON Automation Americas identified a need to modernise its approach to digital marketing, with a new website being central to its future plans. In this article, we’ll show you how we approached the technical solution for OMRON’s new site, built on SDL Tridion Sites 9.
Architecture and Solution Design
The first architectural challenge was to find a way to bring together the technologies that OMRON was already working with so that it didn’t become cost prohibitive to change them later or require a full re-implementation of the framework. We designed a series of microservices for different responsibilities, including customer, product, content, layout, marketing automation, search and data. In addition, we introduced an experience service that could act as the conductor for the orchestra of microservices to facilitate inter-relationships between systems and consolidate the domain models for different responsibilities into presentation models for the channels.
We wanted to produce a dev-ops implementation as automated as the industrial automation products themselves, so we used Amazon ECR / ECS to handle deployments of services and provision infrastructure on demand with code. TeamCity was responsible for pushing versioned images to ECR so that Octopus could pull them and deploy them to version-specific docker containers.
We used .NET Core running on Linux to get all the benefits of a modern development framework and the performance of the Linux operating system. We have RESTful contracts and internally use Refit to generate RESTful clients from interfaces that ensure we honour the API specifications between versions.
We followed semantic versioning to help us properly increment a patch version for enhancements and bug fixes, increment a minor version when adding endpoints or marking endpoints for deprecation, or increment a major version for breaking changes.
WEB: THE PILOT CHANNEL
Instead of building yet another DXA application (YADA), we wanted to ensure that OMRON was decoupled from any technology provider, including their CMS. This would allow them to get much more longevity from their implementation and to manage their own roadmap. We decided to use React on Node with Express for the web channel and enabled server-side rendering with hydration.
The application consumes the RESTful endpoints from the framework APIs, particularly the Experience API. It can produce a context for each API interaction that includes information about the user, the globalisation, the request, etc. This information is used internally within the APIs and the providers that expose OMRON’s underlying technology platforms, so that we can customise the response accordingly. This facilitates personalisation and localisation, and it can be used as a means of abstraction if there is a need to interrogate different systems based on the context of the interaction.
The web implementation is a best-practice, responsive, modular framework that builds upon years of experience creating template-based content managed experiences. This has provided OMRON with a huge increase in control and flexibility to provide market-structured content to their customers efficiently and effectively.
OMRON previously had a basic search implementation based on SI4T, but we decided to make some dramatic improvements in alignment with our overall architectural approach. We used Elasticsearch as the underlying technology but followed the provider model to ensure that the framework API for search encapsulated it behind intuitive endpoints tailored to the OMRON business requirements.
We designed a genericized search document that supported concepts like globalisation, authorisation, and classification. In addition, the document had elements of polymorphism for type specific fields and logic.
We implemented a very simple SDL Tridion Sites 9 deployer extension that would take our serialized page (composition) or component presentation (fragment), determine whether they should be included in search, and POST them to the APIs for indexing or updating (or deletion if being unpublished). So to adhere to CMS best practice the business logic and complexity was encapsulated in the Search API enforcing SOLID principals.
Elasticsearch allowed us to have an effective search algorithm and complex aggregations for faceted navigation and filtering, all with exceptional performance. Internally we can take advantage of all the features of this wonderful product but expose it in a much simpler business-centric way.
Managing content with SDL Tridion Sites 9
We developed the CMS providers (layout and content) against SDL Web 8.5. Instead of DXA we decided to write custom TBB serializers to achieve our desired domain model right from rendering. It is very simple to implement a wrapper around the .NET CIL to consume the serialized page / component presentations, deserialize them to our domain models, resolve links, and then cache them for high availability.
During the final phase of development, we upgraded the implementation from SDL Web 8.5 to SDL Tridion Sites 9 and migrated from our AWS hosting to the SDL Cloud within a week. This was an excellent demonstration of the development velocity achievable using the framework and provider abstractions.
By removing any dependency on DXA, the content editors are free to organise the SDL Tridion items however they see fit and align them with how they want to use the product. They can also take advantage of new features such as page regions without having to having to customise DXA or wait for DXA to implement them.
Our Content and Layout APIs are highly performant middleware that help us to obtain our domain models based on the context, while the Experience API acts as a proxy for the channels to delegate route interception, enrichment and model transformation. This allows it to remain lightweight and unburdened by anything beyond presentation logic.
We dive a little deeper into this project with some exceptional results.