Loading...
Loading...
The Service Portal has an API that allows functionality similar to the Core UI. This API essentially allows all the things ServiceNow users are used to doing in the core UI to work in Service Portal; Related Lists, Sections, UI Actions, UI Scripts etc. This API is enabled through the $sp.getForm() method. When UI Scripts are defined as "Mobile / Service Portal" or "All" and the $sp.getForm() method is used on a widget, all those UI Scripts are downloaded and uploaded over and over, causing performance overhead. 1.) Every single Service Portal widget that leverages a Service Portal form will need to download the UI Scripts for every transaction, without any possibility of it being cached on the client side. This causes excessive form render time, CPU processing and memory overhead on the server side as well as adds to network latency, impacting download times. Client-side resources should only be loaded once and then cached on the browser. 2.) Every single Service Portal form submission (e.g. when you click "Save") will upload the UI Scripts in the form data, creating excessive network latency. Since upload bandwidth is typically far less than download bandwidth this is the more impactful of the two issues. For example, just 4Mb of UI Scripts can cause 1-minute of network latency on some connections. This is especially impactful for customers with larger UI Scripts (e.g. combining to over 1Mb). Steps to Reproduce 1. Go to incident.list 2. Import the XML attached to this KB Article. ( It is just a UI Script by the name 'mana_bar') 3. Copy sys_id of any existing incident from the incident list. 4. Use the below URL: https://<myinstance>.service-now.com/$sp.do?id=form&table=incident&sys_id=9c573169c611228700193229fff72400 6. Change the sys_id to sys_id from step 4. 7. Open the developer tools-> Console tab. 8. Check the network panel and notice that there is a request that loads the entire UI Script 9. No matter how many times you reload the page you will need to download that UI Script each time 10. Change any field on the form 11. Click "submit" 12. Check threads.do and notice the thread is stuck downstream from SPRestService.getJSON() 13. Check the logs and notice warnings like the following: "WARNING *** WARNING *** SizeAwareServletInputStream@31838286: Large amount of data has been streamed:" "Slow deserializing request body" Exepected behavior: UI Scripts would behave like they do everywhere else in ServiceNow and be loaded as cachable script files that are separate from the form data Actual behavior: 1.) UI Scripts are repeatedly downloaded with every form load and cannot be cached 2.) Form data submitted to ServiceNow's servers includes the entire contents of all of the "All" and "Mobile / Service Portal" sys_ui_script records
This issue can be completely mitigated through using a different approach to including UI Scripts in Service Portal. Instead of using "Mobile / Service Portal" or "All" UI Scripts, you can use JS Includes to connect them to the appropriate Service Portals via Themes. If you do that, then the UI Scripts will only be loaded the first time a user visits a Service Portal. Any subsequent form loads will use the cached script resource. In addition, the UI Script will no longer be included in the form submission payload. See Create a portal theme.
1. Change all UI Scripts (sys_ui_script_list.do) defined as "Mobile / Service Portal" or "All" to be non-global "Desktop" UI Scripts 2. For each of those UI Scripts, create a record in the JS Includes table with type "UI Script" and select the UI Script in the "Soure" field 3. For each UI Script that needs to be added to a certain Service Portal, edit the "JS Includes" related list in the relevant Service Portal record
PRB1405409
Click on a version to see all relevant bugs
ServiceNow Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.