Recent changes for sys_choice entries in Domain Separated instances

[Alex Coope - SN]

In the Tokyo release we introduced a new means of installing the Language packs. Gone are the days of a Language pack taking hours to install. However this new method changes a few things, so grab your favourite beverage and / or snack and lets delve into the details.

What's changed?

Previous to the Tokyo release, we would unpack the data of the language packs into Import set tables to then run Transforms to load them into the 5 tables (If you need a quick refresher of what 5 tables we're talking about, check out my other blog post about them here). Where-as now, the data of the Language Packs can be reliably and directly added to the tables significantly increasing the performance, going from 3+ hours per pack down to 20-30mins per pack.

With this new design of loader, there is a side effect, in that specifically for [sys_choice] entries it means that the "sys_domain" and "sys_domain_path" fields do not have a value (e.g. "global" for the Domain value and "/" for the Path value). This is a change to the previous behaviour as those data points were included in the source data and therefore were included in the transform maps.

Can this be corrected?

Yes it is possible for you run a script to update the values to your needs, and it is something we will be changing in a future release.

For example, you could run a script (ideally a scheduled job / fix script so that you can stop it should you ever need to) similar to this one (you will need to test in a sub-production environment to ensure you get the desired results, and you make potentially need to make some tweaks to fit your needs):

checkChoiceDom();

function checkChoiceDom() {
    try {
        // we need to see if we have any records on the [sys_choice] table without a domain 
        var properDom = 'global';
        var properPath = '/';
        var checkChoice = new GlideRecord('sys_choice');
        checkChoice.addQuery('sys_domain', '');
        checkChoice.orderBy('language');
        checkChoice.query();
        while (checkChoice.next()) {
            // we need to check the domain field and the domain path field 
            if (checkChoice.sys_domain == '') {
                checkChoice.sys_domain = properDom.toString(); 
                //gs.log('Domain - we have a result for ' + checkChoice.getDisplayValue() + ' - ' + checkChoice.sys_id + ' - ' + checkChoice.sys_domain);
            }
            if (checkChoice.sys_domain_path == '') {
                checkChoice.sys_domain_path = properPath.toString(); 
                //gs.log('Path - we have a result for ' + checkChoice.getDisplayValue() + ' - ' + checkChoice.sys_id + ' - ' + checkChoice.sys_domain_path);
            }
            checkChoice.setWorkflow(false); 
            checkChoice.update(); 
        }
    } catch (err) {
        gs.log('Error in checkChoiceDom - ' + check.err + ' - ' + check.message);
    }
}

 
I've purposefully left the gs.log statements incase you need to validate stages, in which case you would need to comment out the .update() line so you don't go and update all the records whilst you are investigating things.

And be conscious that when you go and update the records, that if you have multiple Language Packs installed it could be multiplied, so you might want to add additional conditions to maybe do one language at a time. You will also need to be conscious which domain you are running the script in so that you can correctly set it to "global", otherwise you may find they go into the "Default" domain.

If you are curious about learning more about this topic, we also have a deep-dive KB article on NowSupport available here,

What have we learned?

Well, with new concepts sometimes comes new ways of thinking, but at the same time if we are familiar and comfortable with how data structures in the platform work, we can almost always over come them.

If you found this helpful, please like and share as it always helps