X Force Scripts

[Jomega Gibson]

Inour system we use system.util.invokeAsynchronous() to run a number of state machines in a dedicated thread. At times some of the functions running in this thread can fault and stop working while the remaining functions will continue working. We have a mechanism to stop and restart the state machines and dedicated thread, but this does not always work to bring them all back to a working state. In such cases, we have found to get everything working again we get the Designer to think there are changes to the Gateway Event Scripts by opening the Gateway Event Script dialog, pressing the Apply button, and then closing the dialog. We then save and publish the Project from the Designer which will go through the Shutdown Script and then the Startup script. This typically will resolve any issues and all the state machines will function normally. We have also seen this resolve issues with Gateway Timer Scripts that have stopped responding. We would like to be able to accomplish this via scripting inside a button or a timer script so we can do this automatically when we detect this is needed without needing to have access to a Designer. Is there any way to do this? I have tried system.util.retarget() back to the same project, but it does not seem to restart the project scripts.

Consider using a timer script instead of an asynchronous thread to run your state machine, with the state information held in a script module global variable. That will always run the correct code, and will have empty or freshly initialized state information after any scripting restart. Again, use system.util.getGlobals() to hold information that should persist in spite of script restarts.

I'm looking for a clean way to re-run the CTA initializers (I guess the web-interactives-embed.js script? Or maybe ?), without forcing my users to refresh the page. There are precedents for this in other Hubspot tools, for example:

I have tried exploring the relevant JS objects that exist on the page via the browser console, but most of them are poorly documented (if at all), and I haven't been able to find a way to do a sort of "CTA force refresh". Some potentially relevant "keywords":

Any help or ideas for alternate approaches are greatly appreciated. Ideally, I don't need to do anything different on my back-end; There should be a client-side solution for this, I think? It doesn't feel like it should be as hard as it is.

Thanks to jsegars for the insight that solved the problem. I'd been been putting off reviewing and implementing this for many months, but here's how I solved it with a custom Tag in Google Tag Manager:

5. Load a page and open the console. Then click to a new page on your website, and see what mutations take place on the page change in your web app. You need to find a mutation that is (1) consistent across all page changes, and (2) executed after the content on your page loads.

Hey, @baribeau I saw your post with links to similar SPA-related issues in another post. I'll take your post and share it with the team that owns the new, not a beta anymore, CTA tool and ask for some guidance.

After weeks trying to find out how to import properly data coming from an Excel file (the only workaround I found was to save data as .txt but I was not satisfied to have two files instead of one), I may have found a path to solve my issue: forcing JMP Windows specific preferences. Indeed, when disabling "Use JMP language rather than system local settings for number, date and currency formats" option, it prevents JMP from incorrectly interpreting data from my XL file and I finally get all data with the right format (see secreenshot enclosed).

Now, in order to make my script work for every JMP user of my company, I need to force this setting in my jsl script. Any idea what the command would be? I guess it would be something like: Preferences( Pref( "value" ) ).

Unless you are in a position to decide how everyone in your company uses JMP, I would suggest that do not change the settings without changing them backbecause changes like this might break something else.

Good point Neally. I should of mentioned that I thought that the script would run and add the networked folders very much how it would add mapped drives(Even though mapped drives are not created by scripts). If any mapped drives were missing we would run a gpupdate to get them back. I was hoping for a kind of similar function if GPO allowed it.

...currently the best way is the Scriptrunner built in script "Clear classloader or jira internal caches"; If I clear the "Groovy class loader" cache, all scripts are recompiled when they are used the next time. This just slows down the next script executions, but works fine for me.

There is definitely a need for the same mechanism in Confluence, however we have not yet been able to force a recompilation of Scripts in Confluence. Even worse, there is no "built in script" in Scriptrunner for Confluence to clear the class cache. Current workaround is to deactivate an reactivate the Scriptrunner plugin in Confluence - does the job, but this should never be routine in a production instance...

I was able to fetch the dex param from the interface. I tested with UR5 and the threshold mentioned here is correct. In case someone needs a sample code for this, @ajp already posted a sample code for it as he mentioned.

I was able to compute the dexterity with the information from @malacasse but with a 0.00002 difference from the actual dexterity reported by the robot. I think I will be able to use this to avoid singularity in my grasp planner.

We can understand dexterity as an ability to move well in different directions in cartesian space. There are different ways to evaluate it and using Jacobian determinant is one of the commonly used methods. As it approaches zero, movements along some directions may become unreachable. As @malacasse mentioned, UR sets a threshold on this value to prevent the robot from going into the singularity.

As @ajp said, there is nothing you can do really with the robotDexterity value fetched from the client interface because it only tells you the dexterity from the current robot position. If they develop a feature that can compute dexterity from an arbitrary position, maybe we can do something inside the urscript.

What I did was pretty simple. I was solving some kind of bin picking problem and had to apply force_mode for a z-axis-constrained motion. So I computed the dexterity of discrete points along the desired path. If the path is valid, then perform the movement otherwise plan a different grasp pose and approach path. These are done outside of urscript.

Consider the following situation. You have been tasked with developing a user experience in ServiceNow that is a bit outside of the normal UI functionality. You decide to develop a UI Script to handle the requirements. Maybe you are consolidating logic that exists in Client Scripts into one function that is available on all forms. You develop and roll out the initial version which looks something like this:

You save, test, and roll to production. All is well. However, a bug is soon discovered and you need to troubleshoot it. You try calling the function with debug on, but it doesn't work. You research a bit and find that you forgot to declare the parameter for the function. So you fix the issue:

You test your work thoroughly this time, but it keeps failing. The debug statements simply don't work. After much research, you discover that, although you updated the UI Script, the old version is still being loaded into the form. You try everything you know to no avail, but nothing fixes the issue (cache.do, multiple saves, toggling active, etc...). You become frustrated at this point and flush your browser cache, and voila! It's fixed. But your developers and customers that have previously used the functionality still have the issue. So you turn to workarounds.

...and I do mean workaround. This is by no means to be considered a fix. The secret is in the browser cookies. We know that many plugins contain UI Scripts. These applications are updated from time to time (including the UI Scripts) and that works fine. What's the difference? Activating a plugin triggers a forced cache update for the users' browsers. The difference is that updating a UI Script doesn't trigger this. Not even a cache.do triggers it. It simply forces the server to update cache. Installing/updating plugins seems to be the sole trigger that forces the browser to ask the server for updated cache for UI Scripts.

The check for building new cache in this instance is controlled by a cookie on the client browser that ServiceNow creates. The cookie is controlled by a property in ServiceNow called glide.lastupdate. To force this update to happen, all you have to do is set that property to a newer dateTime than it currently is (e.g. the current timestamp). You can do this manually, but that can also be a form of kicking the can down the road. You will be back here soon. At Walmart, we wrote a Business Rule to update this whenever a ui_script is updated:

I have attached an export of this business rule for any who are interested. The info message reminds developers to ensure this updated property is included in their update set, since business rules are not triggered on update commit.

3a8082e126