During my first upgrade, I believe it was Jakarta to Kingston, I wrote a little tool that allowed me to compare records from different instances, because I wanted to know if there are any differences in the plugins installed.

This is the story of the journey to bring that old code to leading practices and do business smart customizations (and yes, you can download the tool as well).

The baseline

The compare application consists of a table to store the compare configuration and results (if you choose to compare a list on a remote system you can save the result as a CSV), some menus and forms incl. UI policies and a UI action that does a AJAX call to a script include that does the compare.

The goal

Since the initial implementation the platform has improved a lot and so has my knowledge about the platform. So I decided to rebuild the application with some leading practices applicable today:

• Scoped application (initial code was in a global app)
• ECMA 21 JavaScript (only available on Tokyo)
• Connection and Credential Alias (initial implementation used an URL and a reference to a Basic Authentication Credential)

The journey

The migration from global app to a scoped app is not supported. All artefacts have to be recreated in the application scope. This allowed me to simplify and harmonize my UI actions, field names and to directly implement the desired changes to use Connection and Credential Alias instead of managing the URL and Credentials in the record itself.

The basic work of creating the table, the navigation menu and the forms including UI action and policies where completed quickly.

When rewriting the code I was looking for opportunities to leverage the ECMA21 functions to simply code. I found that while there was a lot to be done to improve code clarity by defining more and simpler functions I did not actually have a good use case that would allow me to profit from the supported ECMA21 functions with Tokyo. So in the end, the desire to be backwards compatible to N-2 was more important than to be on the latest technology stack.

The challenge

The single record compare uses the baseline Script Include DiffHelper and the GlideRecordXMLSerializer scriptable java class to build the HTML code to show in the popup. As I quickly found out they both are not usable in an application scope.

The Script Include TableUtils is also not available in scoped applications. The TableUtils are used to retrieve all fields for the remote compare in case no field was selected by the user and also in the reference qualifiers used on the keys and fields reference lists.

Here are the options that I looked at to overcome this challenge:

---

Page 2

During my first upgrade, I believe it was Jakarta to Kingston, I wrote a little tool that allowed me to compare records from different instances, because I wanted to know if there are any differences in the plugins installed.

This is the story of the journey to bring that old code to leading practices and do business smart customizations (and yes, you can download the tool as well).

The baseline

The compare application consists of a table to store the compare configuration and results (if you choose to compare a list on a remote system you can save the result as a CSV), some menus and forms incl. UI policies and a UI action that does a AJAX call to a script include that does the compare.

The goal

Since the initial implementation the platform has improved a lot and so has my knowledge about the platform. So I decided to rebuild the application with some leading practices applicable today:

• Scoped application (initial code was in a global app)
• ECMA 21 JavaScript (only available on Tokyo)
• Connection and Credential Alias (initial implementation used an URL and a reference to a Basic Authentication Credential)

The journey

The migration from global app to a scoped app is not supported. All artefacts have to be recreated in the application scope. This allowed me to simplify and harmonize my UI actions, field names and to directly implement the desired changes to use Connection and Credential Alias instead of managing the URL and Credentials in the record itself.

The basic work of creating the table, the navigation menu and the forms including UI action and policies where completed quickly.

When rewriting the code I was looking for opportunities to leverage the ECMA21 functions to simply code. I found that while there was a lot to be done to improve code clarity by defining more and simpler functions I did not actually have a good use case that would allow me to profit from the supported ECMA21 functions with Tokyo. So in the end, the desire to be backwards compatible to N-2 was more important than to be on the latest technology stack.

The challenge

The single record compare uses the baseline Script Include DiffHelper and the GlideRecordXMLSerializer scriptable java class to build the HTML code to show in the popup. As I quickly found out they both are not usable in an application scope.

The Script Include TableUtils is also not available in scoped applications. The TableUtils are used to retrieve all fields for the remote compare in case no field was selected by the user and also in the reference qualifiers used on the keys and fields reference lists.

Here are the options that I looked at to overcome this challenge: