“As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications.”
— David Lorge Parnas
Now that we have completed the initial version of the application publishing process, it would be nice to release a new Update Set so that the folks who are inclined to help out with the testing can try it all out. However, we have already received feedback from the earlier testing of the set-up process, and we should really address all of those issues before publishing a new version for further testing. Here are the items discovered during the testing of the first version of the software released earlier:
- Installation error: Table ‘sys_hub_action_status_metadata’ does not exist
- Not allowing update of property: x_11556_col_store.store_name
- Not allowing update of property: x_11556_col_store.host_instance
- In the setup, the instance name field doesn’t inform you that you only need the instance prefix, not the full url
- You can only collaborate with one host
I was able to reproduce them all, and here is what I ended up doing for each:
Installation error: Table ‘sys_hub_action_status_metadata’ does not exist
I tried to find out some information on the purpose and use for this table, but I couldn’t really find anything that told me anything of value. I still believe that the ‘sys_hub_action_status_metadata’ table is related to a version or plugin that I have in my instance, but was not present in the instance on which the test installation was being performed. Since it didn’t seem as if it was anything that had anything to do with the operation of the application, I decided to just delete all references to it in the Update Set, just to avoid this issue. I’m not sure if that will cause any issues with any instances that actually do have this table, but it seemed like something worth a try and we’ll see what happens. If it causes a problem, I will not do that in the future and just throw in some release notes that say just ignore the error if it comes up. But let’s see if this works, first.
Not allowing update of property: x_11556_col_store.store_name
Not allowing update of property: x_11556_col_store.host_instance
This one took a little bit of research and a little bit of trial and error (mostly error!), but I eventually solved the problem by moving all updates to these properties into my global utilities so that the command was being executed by a global component instead of a scoped component. I did this once before with the gs.sleep() function, and this worked out just as well. Here is the function that I added to the global utilities:
setProperty: function(name, value) {
gs.setProperty(name, value);
},
Once I created the function in the global utilities, it was just a matter of changing all gs.setProperty() function calls to csgu.setProperty() and that seemed to have done the trick.
In the setup, the instance name field doesn’t inform you that you only need the instance prefix, not the full url
Since the snh-form-field tag provides for a “help” attribute, which appears underneath the label, I simply updated the definition for that field to include a little help:
<snh-form-field
snh-model="c.data.host_instance_id"
snh-name="host_instance_id"
snh-label="Host Instance ID"
snh-help="Enter the instance ID only, not the full URL of the instance (https://{instance_id}.servicenow.com))"
snh-required="c.data.instance_type == 'client'"
ng-show="c.data.instance_type == 'client'"/>
This renders a little help text underneath the label, and looks like this when the page comes up:
That should resolve this issue.
You can only collaborate with one host
As I mentioned earlier when this was first reported, this is by design. Allowing multiple Host instances introduces a level of complexity with which I’m not quite ready to deal just yet. At this point, we will just file this one under Will not fix or Future release for now.
Other than these issues, I have not personally encountered or heard of any other issues with the set-up process, but that doesn’t mean that the testing is complete by any means. If anyone wants to join the testing process and you missed out on testing the earlier version, you will still have to work your way through the set-up process for any instances involved, so please report any issues with the set-up process as well as any issues with the application publication process.
Speaking of the application publication process, there is still yet another aspect of this process that remains to be developed. Once a new application has been published to the Host instance, the Host instance will need to push that version out to all of the other Client instances. This version does not include that functionality, but we will need to throw that in at some point. I just did not want to hold up the testing for that particular feature, since it really is a completely independent operation.
For those of you who are interested in participating in the testing, you will need this new Update Set, plus this additional global component that is not included in the scoped application. Also, if this is your first time installing the application, you will also need the latest version of snh-form-fields, which you can find here. As always, if you have any feedback, positive or negative, please leave the details in the comments. All information is welcome and much appreciated. Thanks in advance for your assistance.
Mark Beaver says:
Hey Hannibal,
I attempted to load your latest update sets into my PDI but got a number of errors. Here is one:
FAILED TRYING TO EXECUTE ON CONNECTION glide.9 (connpid=22): INSERT INTO sys_metadata (`sys_id`,`sys_package`,`sys_update_name`,`sys_updated_by`,`sys_created_on`,`sys_mod_count`,`sys_name`,`sys_scope`,`sys_updated_on`,`sys_class_name`,`sys_created_by`,`sys_policy`) VALUES(‘e57a16972f5370104425fcecf699b6da’,’5b9c19242f6030104425fcecf699b6ec’,’sys_scope_privilege_e57a16972f5370104425fcecf699b6da’,’system’,’2021-10-25 02:31:05′,0,’ScriptableRESTResponse.haveError’,’5b9c19242f6030104425fcecf699b6ec’,’2021-10-25 02:31:05′,’sys_scope_privilege’,’system’,NULL),INSERT INTO sys_scope_privilege (`sys_id`,`target_name`,`target_type`,`source_scope`,`target_scope`,`operation`,`status`) VALUES(‘e57a16972f5370104425fcecf699b6da’,’ScriptableRESTResponse.haveError’,’scriptable’,’5b9c19242f6030104425fcecf699b6ec’,’global’,’execute’,’allowed’)
java.sql.BatchUpdateException: (conn=22) Duplicate entry ‘5b9c19242f6030104425fcecf699b6ec-global-ScriptableRESTResponse.h’ for key ‘source_scope_2’
There was also a flow update that I had to skip because it had no content.
Thanks for your consideration.
Mark
snhackery says:
Hey, thanks for giving things a shot. I believe that the error that you are receiving is related to the manual updates that I did to the Update Set in an effort to remove the sys_hub_action_status_metadata error that was received with the first Update Set. I probably should have just left that alone. As for the sys_properties errors, you should skip those, as the set-up process updates the value of some of those properties and you would not want to undo that. Probably something else that should be mentioned in some kind of release notes.
As for what to test, the new functionality allows you to publish an application to the Host via the new UI Action that you mentioned. That is the process that needs to be evaluated.
Thanks for your help!
Mark Beaver says:
The other errors had to do with a few sys_properties that had newer versions, probably because my pdi was recently upgraded.
Mark Beaver says:
We could use some help with testing criteria (maybe a usage tutorial?)
If we had installed your initial test version and set up a host and client, should we delete those and set up from scratch?
Thanks
Mark Beaver says:
I found the ui action on the sys_app table (Publish to Collaboration Store) so we can start testing there.
Mark Beaver says:
Your update set link produced the following error:
Forbidden
You don’t have permission to access this resource.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.