The history of SnowMirror began back in 2011. We were part of a huge ServiceNow implementation project in one logistics company having one of the largest ServiceNow instances in the world. Our goal was to design an integration architecture and to implement 30+ integration points. Many of them were read-only interfaces in nature or they needed data just for reporting purposes on top of service desk data. And that was the point where the idea of mirroring the data was born.
Let’s say 40% of the integrations in that project were about creating an incident or some other ticket. Another 40% were those read-only interfaces and the rest of 20% were some special cases such as monitoring integration, orchestration or discovery. The read-write access integration points were implemented using standard ServiceNow tools such as import sets, direct web services or REST API. Of course everything was designed in a SOA way.
So over 12 third-party systems needed to read ServiceNow data, and usually big data. There were 5 applications that required service desk master data to work correctly. Data such as users, user groups, services, configuration items, catalog items, etc. And such master data does not change very often, right? The rest of about 7 or 8 systems were reporting or business intelligence tools. We had to integrate with Cognos, Microsoft Reporting Services, Tableau, data warehouse (or data mart) or even with Microsoft Excel reports and some custom PHP applications.
The first idea most of the consultants have is to use standard ServiceNow means. But do you really want to let a reporting tool to send complicated queries into your production ServiceNow instance every time the report is generated? Do you really want your PHP application to send several web service calls to direct web services every time someone accesses a page in that application? Or how do you export millions of incidents every day when the data mart is being loaded?
Our answer was: “If the application does not necessarily need a real-time data it will not access ServiceNow directly”. The benefits for the instance are clear:
The solution we designed and implemented was an agent deployed in the customer’s environment (i.e. customer’s network) mirroring ServiceNow data into an Oracle database. All applications that needed the data for whatever reason accessed them in standard Oracle ways (e.g. ODBC driver, JDBC, ETLs or plain SQL). Even for the integrating applications and reporting systems there are benefits:
The first version of the mirroring solution was very simple and designed just for the project. We realized there is a need for such a solution among other ServiceNow users. Nowadays 75% of our customers use or need such a database mirror. So we designed SnowMirror from scratch. The replication algorithm has been fine-tuned to have the best possible performance and lowest impact on the instance. SnowMirror supports several database types, the agent contains user-friendly UI to configure everything, there is a SnowMirror Dashboard application to be installed into ServiceNow to monitor the mirror and much more.
Since 2011 we have gained a lot of experience and SnowMirror proved it is a useful solution for most of the ServiceNow customers and partners. It is an enterprise-class solution from ServiceNow professionals.