"You know it’s all about that base(line data)..."
“I’ll make a brand new start of it”
As we’ve come to expect from ServiceNow, the Now Platform New York release brings a wealth of new innovations (more than a pleasingly-sequential 678 of them) for us to explore, exploit and enjoy.
In this blog, I’ll discuss a couple of the data-centric features that I think will help Administrators and Developers to ‘do more’ with ‘less effort’ (or, more correctly, less effort to achieve your ‘what’, rather than fumbling with the ‘how’), so they can continue to concentrate on delivering customer value (rather than the necessary, but often under-appreciated, maintenance and stuff-that-needs-to-be-done-to-ensure-a-successful-development-environment activities).
Instance Data Replication (IDR)
“If I can make it there I’ll make it anywhere”
Imagine if you were able to test in your sub-production instances with ‘real’ (subject to the appropriate controls) data - how much easier would that make testing, both for yourself and your customers? No more worrying about generating test data sets; no more bamboozling your customers with abstract test conﬁgurations.
You could also (if appropriate) keep User, Group and other ‘platform’ information aligned to enable a consistent experience whether ‘testing in Test’ or ‘running in Production’. No more ‘XML import/export’ malarky to try and keep sys_ids in sync, so less of those ‘(empty), but I do know really’ references!
IDR allows you to securely replicate data from one instance to another, or to multiple instances (eg. Development and Test) should that be required. It could be as simple as ‘send the whole table’, but you can naturally ﬁlter for a subset of records and, if required, transform and redirect the data en route - plus execute Business Rules and Workﬂows once the data arrives.
There are some caveats, of course - instances must (at least for now) be in the same ServiceNow Data Centre and replication is ‘only’ triggered every 15 minutes (so it’s not a ‘live’ data synchronisation service). Seeding (initial setup or a data reset) also needs to be done ‘an instance at a time’ and is ‘limited’ to 3 million records. In this ﬁrst version of IDR, you can only coalesce on sys_id - which is likely to be desirable but may preclude some use cases.
It does not seem possible (yet?) to enable IDR on Developer instances, but hopefully, we will soon be able to replicate data with our peers and take this exciting new functionality for a spin...
Outside of this, IDR could also be used to communicate with ‘external’ instances - for example sending tasks to a third party for action then consuming any updates from their side, leveraging this ‘in platform’ capability to remove the need for those sometimes complicated web services.
For a great presentation and video from CreatorCon 2019 discussing this in much further depth in the ServiceNow Community click here.
“I want to be a part of it”
Imagine if you were able to retrieve data from an external system, process it on the platform as if it were native and not have to worry about managing or maintaining the data in ServiceNow at all. That’s Remote Tables.
There’s all sorts of temporary data accessed across enterprise systems every day and yes, we could write an integration - but, you have to put that data somewhere. With Remote Tables, you don’t - but it still looks like you did! In addition, you still get standard GlideRecord functionality, dot-walking, scripting, plus normal behaviour in form and list views. It’s like an ‘always upto-date lookup table’ for data held externally, or perhaps a ‘created-on-the-ﬂy context-speciﬁc report source’ for information to be presented in, for example, Agent Workspace.
It’s also possible to specify how long the data should be cached for before it is refreshed - you might allow contact details from a CRM system to remain valid for an hour, say, but refresh any contract entitlements every time. A table containing the ‘daily specials’ for the onsite canteen could remain ‘fresh’ for 24 hours.
Of course, we need to be aware of the performance impacts and cautious about the implementation - collection scripts run every time the table is accessed (caching aside) and the returned information lives in memory, so data sets need to be relatively compact. There's also a small bunch of development tools that need to be learnt and the implementation is relatively unguided (read: you need to write the script yourself from scratch). That said, once you have it up-and-running the table looks ‘just like everything else’ to other developers and users on the system.
ServiceNow’s Product Documentation includes further examples of where this might be useful and how to set it up.
“Start spreading the news”
Clearly these new features offer huge opportunities for enterprise data management within and without the Now Platform, helping to cement ServiceNow’s position as a ‘tool for everyone’ and the ‘go-to data consolidator’. Providing agents with concise, relevant and timely information will surely help elevate how useful, reliable and respected the tool will become.
One burning question though: do you bite the bullet and re-write existing implementations to simplify them with native capabilities now, hoping to avoid on-going maintenance costs in the future, or will these be ‘just another way’ of collecting data that needs to be supported alongside everything else?
As always, we’ll have to compare and contrast with our current conﬁgurations, but I for one am excited to see how these can help simplify our data management needs. Will it work in your environment?
“It’s up to you...”