“Continuous delivery without continuous feedback is very, very dangerous.”
— Colin Humphreys
Last time, we started to tackle some of the issues that were reported with the last set of Update Sets released for this project. Today we need to attempt to address a couple more things and then put out another version with all of the latest corrections. One of the issues that was reported was that the application publishing failed because the Host instance was unavailable. While technically not a problem with the software, it seems rather rude to allow the user to go through half of the process only to find out right in the middle that things cannot proceed. A better approach would be check on the Host first, and then only proceed if the Host is up and running.
We already have a function to contact the Host and obtain its information. We should be able to leverage that existing function in a new client-callable function in our ApplicationPublisher Script Include.
verifyHost: function() {
var hostAvailable = 'false';
if (gs.getProperty('x_11556_col_store.host_instance') == gs.getProperty('instance_name')) {
hostAvailable = 'true';
} else {
var csu = new CollaborationStoreUtils();
var resp = csu.getStoreInfo(gs.getProperty('x_11556_col_store.host_instance'));
if (resp.status == '200' && resp.name > '') {
hostAvailable = 'true';
}
}
return hostAvailable;
}
First we check to see if this is the Host instance, and if not, then we attempt to contact the Host instance to verify that it is currently online. To invoke this new function, we modify the UI Action that launches the application publishing process and add a new function ahead of the existing function that kicks off the process.
function verifyHost() {
var ga = new GlideAjax('ApplicationPublisher');
ga.addParam('sysparm_name', 'verifyHost');
ga.getXMLAnswer(function (answer) {
if (answer == 'true') {
publishToCollaborationStore();
} else {
g_form.addErrorMessage('This application cannot be published at this time because the Collaboration Store Host is offline.');
}
});
}
With this code in place, if you attempt to publish a new version of the application and the Host is unreachable, the publication process will not start, and you will be notified that the Host is down.
That’s a little nicer than just throwing an error half way through the process. This way, if the Host is out of service for any reason, the publishing process will not even begin.
I still do not have a solution for the application logo image that would not copy, but these other issues that have been resolved should be tested out, so I think it is time for a new Update Set for those folks kind enough to try things out and provide feedback. There were no changes to any of the globals, so v0.7 of those artifacts should still be good, but the Scoped Application contains a number of corrections, so here is a replacement for the earlier v0.7 that folks have been testing out.
If you have already been testing, this should just drop in on top of the old; however, if this is your first time, or you are trying to install this on a fresh instance, you will want to follow the installation instructions found here, and just replace the main Update Set with the one above. Thanks once again to all of you who have provided (or are about to provide!) feedback. It is always welcome and very much appreciated. Hopefully, this version will resolve some of those earlier issues and we can move on to discovering new issues that have yet to be detected. If we get any additional feedback, we will take a look at that next time out.
Joe Blogs says:
Hi,
Getting a failure in the commit log:
FAILED TRYING TO EXECUTE ON CONNECTION glide.20 (connpid=42): INSERT INTO sys_metadata (`sys_mod_count`,`sys_updated_on`,`sys_class_name`,`sys_id`,`sys_package`,`sys_update_name`,`sys_updated_by`,`sys_created_on`,`sys_name`,`sys_scope`,`sys_created_by`,`sys_policy`) VALUES(0,’2022-08-04 00:37:18′,’sys_scope_privilege’,’c65ad39a97015110ca2671571153af8f’,’5b9c19242f6030104425fcecf699b6ec’,’sys_scope_privilege_c65ad39a97015110ca2671571153af8f’,’snhackery’,’2022-08-04 00:37:18′,’sys_app_module’,’5b9c19242f6030104425fcecf699b6ec’,’snhackery’,NULL),INSERT INTO sys_scope_privilege (`target_name`,`target_type`,`target_scope`,`sys_id`,`source_scope`,`operation`,`status`) VALUES(‘sys_app_module’,’sys_db_object’,’global’,’c65ad39a97015110ca2671571153af8f’,’5b9c19242f6030104425fcecf699b6ec’,’read’,’allowed’)
java.sql.BatchUpdateException: (conn=42) Duplicate entry ‘5b9c19242f6030104425fcecf699b6ec-global-sys_app_module-sys_db…’ for key ‘source_scope_2’
Should I continue on the other 2 instances?
Thanks
snhackery says:
Yes. That seems to be another benign error that doesn’t seem to hurt anything. You should be able to continue without further issue. Also, you may need to update the properties after the install as the Update Set assumes a new installation. If you hit the pencil icon on the Collaboration Store menu item, you can activate all of the post-set-up menu items (System properties is one of those options)and then just put your instance name back in the host instance property if it was removed.
Joe Blogs says:
I tried on one of the other instances and got the same error.