4 minute read
New York features for Admins!
It is ServiceNow new release season! With the New York release in Early Access, today, we will show some platform features and enhancements that are a bit more admin focused. Typically the Developer Blog is focused on application development, but we are aware that handling the instance and data also is done by developers.
Instance Data Replication
Cloning is the solution for keeping instances synchronized from developer drift. You should continue to clone regularly to reduce test failures and incidents in production instances. The new Instance Data Replication (IDR) capability does not replace the need for cloning. Its purpose is to provide ServiceNow to ServiceNow data synchronization. Many developers have built their integrations to move data between instances previously. This new feature is intended to make that process quite a bit easier.
IDR is set up on a Producer instance which provides the data. Consumer instances are then configured to retrieve data from one or more producer instances. The data transferred can not be metadata. [Docs](https://docs.servicenow.com/bundle/newyork-servicenow-platform/page/administer/instance-data-replication/reference/IDR-blacklisted-tables.html contains the list of tables that can not be set up via IDR. The intended purposes for the data replication are Core data (locations, departments, categories), and bi-directional records (replication of stories between prod<->dev instances, shared task records, the transference of work notes, etc.)
In our example, we will create a new replication set to move some artifact data between instances.
Start with a table and the fields you wish to offer consumers. And you are now done! Is it that easy, you ask? Yes, it is. Now I can set up my consumer instances to retrieve the data. The consumers can take the data directly as it is, or transform the data. Leave a comment if you wish for a further technical dive into how to configure the consumers and the architecture. Note: this feature can have a cost associated.
Cloning
As noted above, cloning is vital to keeping your instances synchronized. With the New York release, several quality of life enhancements have been added to the cloning process. The first of these new features is ‘where is my clone’? In larger instances, cloning can take hours, and it wasn’t always clear the progress of the clone until it was completed. Now you can check the status of the clone while it is in progress without having to reach out to support.
Scheduling of recurring clones is the second feature we will highlight. The scheduling of clones will help automate the process of keeping your instances fresh and reduce the errors and headaches caused by having your development not match your production and test instances.
Using this new scheduling automation will enable development teams to focus on development and less on administration. A few limitations exist in this first iteration. The number of recurring clones scheduled is limited to 30. Moving the scheduled time for a recurring clone is not possible. Instead, that clone instance must be canceled and a single clone at the new time must be requested. The data preservers can be adjusted up until the scheduled clone process starts.
While not new in New York, clone rollback is worth mentioning while we are on the topic of clones. After the completion of a clone, it is possible to use the rollback feature to restore the target of the clone to one of their backups as long at it is requested within seven days of the clone.
Delegated Development
I might have talked about Update Sets once or twice in the past. If you are unaware, delegated development allows for enabling developers to work on their application without having to have full administrator access. This feature provides for the granting of development rights without the risks and extra training required to have full admin level access. Managing and publishing the applications update sets is now grantable within the delegated development screen. These two rights are exclusive on a per-application basis.
To enable this feature, you must add system properties. Take care on which instances you enable these properties and permissions such that they align with your companies process. If you don’t see the choices in the image below, refer to the docs link above and check the following properties exist and are set to true: com.snc.dd.manage_update_set_enabled and com.snc.dd.publish_to_update_set_enabled.
Share this post
Twitter
Facebook
Reddit
LinkedIn
Email