FujiForty - Converting Update Sets to Scoped Apps

I've been lucky enough to be involved in many of the Fuji development tools since early alpha stages. One tool I've seen a lot of progress in is a conversion tool that allows you to convert pre-Fuji application update sets to scoped application. 

In order to publish Fuji applications to the store they must be scoped and certified by ServiceNow. At a high level there's two ways to create a scoped app. You can build it from scratch in a Fuji instance, or you can migrate an update set to a scoped app. I have plenty of posts explaining the details of building Fuji apps from scratch so I'll limit this to a review of the Pre-Fuji Conversion tool.

Conversion Process

  • Import, preview, and commit the conversion tool update set - this adds new conversion actions to the retrieved update set form as well as all of the conversion logic
  • Import your pre-Fuji update set to retrieved update sets - same as it's been for years
  • Run a check for conversion compatibility - identifies some common issues that must be resolved before conversion. Don't get excited, passing this check in no way means that your app is going to just magically convert and work in Fuji.
  • Preview for scope conversion - creates a new app scope
  • Commit - loads and converts the update payloads and assigns them to the new scope
  • Figure out all the stuff that's broke - this is where most of your time will be spent

It's worth point out at this point how important it is to have documented application use cases that you can use to test your application whether you convert it or rebuild it. It hasn't hit my review list yet but it might be worth checking out the new Fuji Test Management application.

During the conversion all table names and most likely field names will be changed. The tables will follow the new "x_mycode_app_name" prefix format. Fields will be created without the typical "u_" prefix. This is going to impact everything that references table and field names. The conversion will handle the most common pointers, but it won't replace script references by default.

The latest version of the tool provides an option to replace names in scripts. This is basically a bulk search and replace. It will get you closer but you're still going to need to verify all scripts. In some cases you'll need to cross-reference the old scripts since it might not be clear what the old version was trying to do. Since the text replacement is done during record import there's no history to compare to. 

A common issue I have encountered is when there is a field name that is the same name as a table name. For example, the field name (u_aircraft) in the script was replaced with the table name.

//previous
    getInspections: function(aircraft) {
        var gr = new GlideRecord("inspection"); 
        gr.addQuery("u_aircraft", aircraft);
        gr.query();
        return gr;
    },
      
 //converted
    getInspections: function(aircraft) {
        var gr = new GlideRecord("x_cavu_convert_me_inspection");   
        gr.addQuery("x_cavu_convert_me_aircraft", aircraft);
        //should be addQuery("aircraft", aircraft);
        gr.query();
        return gr;
    },

 

There are many other small cases like this so take the time to really analyze the converted scripts. While this is better than not having any script conversion help, I would really prefer to have an editor mid-conversion that suggests changes and lets me review each one. I'd also like to see the original version as a version record so I can leverage the compare feature. 

I did some digging and found some artifacts of the conversion process that might come in handy as you are cleaning up the migration. Perform a test conversion then checkout the following tables:

  • conversion_log - mapping of old name to new names
  • conversion_payload - mapping of update xml payloads

After experimenting with converting close to a dozen apps, my personal preference is to rebuild applications from scratch. While it's a bit more work, it's much more predictable and it also gives me a chance to implement backlog features and code optimizations that might not have made it into the previous version.

I expect this utility to continue to evolve and improve especially once more customers and vendors get their hands on it and provide feedback.