For Episerver Data Repository
Reality Premedia Services developed a CMS solution using EPiServer for a Travel and Hospitality client, focusing on performance and flexibility. The site included booking cards and a booking block synchronized periodically with an external system. The site was fully accessible under WCAG guidelines and tested with various assistive technologies. The team scaled from 2 to 30 resources over two years.
Business Process Name
For Episerver Data Repository
- No customization, difficult to use for content editors
- Not easily Accessible
- Low visitors count on the website
- Not compliant with Web standards
- The solution needed to work across multiple DXC instances
We built tools for content editors to create Vacation brand websites using wireframes provided by the client’s design team. We used API documentation for the booking engine to create different block types, ensuring code-level compatibility with different types of services. All development took place on secure Citrix VMs provided by the client. We customized site and global settings and integrated with the booking engine
FOR EPISERVER DATA REPOSITORY
To store data fetched from API. We decided to use EPiServer’s own caching mechanism that was based on HTTPCache. When pulling data from the External API (for booking information) and caching it, we ran into an issue with the way EPiServer DXC is setup where cache is not synchronized across multiple server instances within one DXC. The ISynchronizedObjectInstanceCache only synchronizes deletions. To solve this issue, we created a new module called “DDSCache”. This was essentially a cache that was backed by DDS (Dynamic Data Store). The idea was that everything is loaded into HTTPCache, but If it needs to do a cold reload, then instead of having to make the API calls, it will use the database instead.
FOR CODE SEGREGATION
With multiple DXC and different audience types and feature sets, we wanted the feature set available to each one to be configurable without having to clone the code across those DXCs. We decided to create multiple NuGet packages that were self-contained. The only dependency was the Core package that had all the interface definitions. If any add on needed to support site settings, it just declared it as a dependency and processed to use it in the standard Dependency Injection pattern. The dependent add on itself was responsible for managing the admin UI etc. for that feature. So, when we went from DXC to DXC, we were able to install the libraries needed for each on (for example, which booking engines were supported) and they were auto registered.
By default, Episerver keeps “site settings” as a tab on the home page for content editors. This causes a couple of issues when managing permissions. We went out and created a brand-new service called the ISiteSettingsService. This service was backed by DDS and had a whole separate admin panel in EPiServer that could be controlled on its own with granular permissions (Permissions for Functions). Using this service, any external addon could inject its own definition of what it needed the content editor to specify at a site level and could be made completely plug and play. The same concept was extended to both the style manager as well as global settings.
Technology stack used to achieve the results :
- EPiServer CMS / ASP.NET MVC 5
- Frontend – jQuery + AngularJS
- Datastore – Azure SQL
- Content Data Storage – Azure Blob
- CDN – Cloudflare
- Cache Synchronization – Azure Event Hub
Reality Premedia later worked with a client to build a cutting-edge solution on top of EPiServer CMS. We added mutliple features that EPiServer does not support yet (at the time of writing) and ensured that all of them were extremely performant. The entire application was enterprise-grade and not just your run-of-the-mill website.
- Built new addons from scratch
- Optimized underlying framework
- Build a better caching mechanism than the out-of-the-box solution
- Supported easy maintenance across multiple DXCs
- Reduced GTM turnaround time