Operating in a world of constant evolution can be a difficult task for any company as we all work toward a new normal and keeping our lives as efficient as possible. With this new normal, it has required long standing companies with dated technologies to look to a new frontier. Realizing that your technology is outdated can be stressful and seem like an impossible task to catch up to the rest of this ever-changing world regardless of the magnitude of your IT debt. No transition is easy, so naturally, we asked ourselves, "How are we going to integrate a legacy ERP to a new eCommerce platform like Episerver?” Seems like an easy question, but let's be honest, we all know the solution is going to be more complex than connecting Point A to Point B, so let’s dig-in a bit.
Recently, we worked with a company looking to make that transition from a Legacy ERP to a Modern ERP and ECP. They relied heavily on their ERP and it was a focal point of their business, holding information for their catalog, product, pricing and inventory (managing their catalog directly from their ERP), with no other systems to help manage their data (no PIM, OMS, Inventory Systems, etc.). They operated out of two warehouses and two stores which made sense to use D365 to manage everything since their business was not overly complex for this setup. Their biggest concern was making sure that they had all their data in their ERP and avoided any data duplication or any other performance issues that may arise.
Option 1 – Use the Dynamics SDK that calls the Retail Server using HTTP. The benefits to this are having the business logic all in one place, the ability reuse business logic that is implemented on the ERP server, the reuse of promotion and campaign logic, and conveniently the logic implemented on the server can be called using the SDK. Example: The guest checkout with minimal work can associate purchases with individual accounts instead of having one massive account containing all the orders, creating easier analysis of your client’s market and the trends of their consumers.
Option 2 – Implement a New ERP before making the transition across platforms. The benefit of this decision is that there is the opportunity to limit duplication without a larger concern of performance issues. The downside to this choice is that by creating an extra step you are adding more project time on for your developers and extending the length of the project which inevitably decreases the speed.
Ultimately, the best decision is to go with Option 1, but that came with two big pieces we had to manipulate.
The first big piece was to import our client’s catalog data. We were able to do this using the Avensia connector. We imported catalog, product categories, and variants. The digital assets came from SharePoint and used an Episerver add-on from which they provided the source code. We then modified the code to work in the specific situation we had with our client. The importing done in the background, was mostly incremental updates that can be controlled through Dynamics. You can choose to publish latest changes or publish the entire catalog itself.
On the Episerver side, we have the same processing logic (one import pipeline). Our import was done with the Avensia Connector (3-4 DLLS). This works in two stages: Staging Phase and Processing Phase. There were no changes made on the Staging Phase, but we had to heavily customize the Processing Phase.
This presented us with the challenge of complex data models (many products and variant types) that forced us to implement dynamic data mapping/model solution. We used Meta Classes and Meta Fields to dynamically generate new Meta Classes and Meta Fields in Epsierver in order to keep them in sync. (Sidenote: 3-4 years ago, IList property was not supported so we were not able to use dynamic attributes list.) The downside of this dynamic MetaClass/MetaField approach is that it introduces a higher complexity. Application to application authorization was needed as well as authorization on the Episerver app using the client Active Directory.
The second big piece was the cart, promotion, order, customer, price, and inventory. All these data points are stored in Dynamics only, leading us to integrate directly with D365 using their SDK. This ultimately allows us to store nothing in Episerver.
For Price and Inventory, the PDP calls directly to D365’s PDP. SRP and PLP, then calls directly to D365 when indexing the products in the search provider. With this we don’t retrieve pricing and inventory from the Episerver Database. You might be asking, why would we do this? We did this for multiple reasons: to avoid data duplication, avoid putting too much load/pressure on D365 and creating a faster response time. For customer, it was essential to have integration with an Identity Server for customer authentication & authorization. We had to build this server, code and deploy it using OAuth2. Communication with D365 needs to be authorized through the Identity server. The Identity server is generating a token that is then used for all calls to authenticate & authorize customers. Finally, for cart, order, promotion and shipping, we made sure that all actions and transactions are called directly from D365. We also used D365 for the promotion engine and built-in tax logic as well. The tax logic is exposed to Episerver via the SDK, making it transparent to Episerver.
This project, like all integrations, was not as simple as Point A to Point B, but we were able to provide our client with a seamless integration that will allow the client to have a scalable and reliable infrastructure for the future as they continue to build and expand. Not only from the perspective of revenue and customer satisfaction, but also as the client builds on their digital blueprint with other integrations and eCommerce capabilities.