Re-factoring Catalog Items for Service Portal

[rrshah83]

I have been working on re-factoring catalog items so that they function on Service Portal. Here are some things that may help others:

Guidelines to design or re-factor catalog items for Service Portal

Browser Console Messages

jslog does not work with Service Portal. You can use console.info, console.warn or console.error depending on the context of the message.

Sample: Replace jslog('RequestersInfo getAttributes response: ' + response); with console.info('RequestersInfo getAttributes response: ' + response);

UI Type for Catalog Client Scripts

If you want a catalog client script to work on both service portal / mobile and regular platform, you must select UI Type = ALL or service portal / mobile.

Although it may be tempting to simply make UI Type = All for all catalog client scripts, but it may not be a good idea for performance reasons. Sometimes, there is a valid reason not to make the catalog client script available on portal due to functional requirements

Run scripts in UI type for Catalog UI Policies

If you want a catalog UI policy to work on both service portal / mobile and regular platform, you must select Run scripts in UI Type = All. Use All, Desktop or Service Portal / Mobile based on your requirement as explained above. This field is not available on the form, you can change it from list view.

Re-usable utility functions

Macros are not supported on Service Portal. We have used macros for several re-usable code (via UI scripts) on our catalog items.

In Service Portal, you can add widget dependencies for re-usable utility functions. However, we have to cautious NOT to add too many dependencies because they may impact performance. Refer to product documentation for adding dependencies.

However, in order for these re-usable functions to be available in rest of the portal, you have to duplicate these utility functions in onLoad catalog client script (with UI Type = Desktop).

This is not the best, but at least we only have 2 places to maintain and not 100 different catalog client scripts within the same variable set. This has been confirmed via HI incident: INT3405728 . We may have better options in future releases (hopefully).

g_form does NOT work if used within a re-usable utility function in UI script

As confirmed by HI incident: INT3405728, g_form is NOT available as a global variable in service portal like it is in rest of the platform. There are multiple use cases where you will require to use g_form in catalog items within Service Portal. This can be achieved with some JavaScript functionality wherein a function can return a function. Click link for details. To work around this issue, you can pass g_form object from catalog client script scope to the utility function - which in turn returns a function object.

For sample usage, see catalog client script: SN:Lookup Requesters Info_v2

CMS vs. Service Portal (detecting whether you are on CMS or Service Portal)

You can use window object to detect if your catalog item is being used in Service Portal or CMS (Rest of platform).

To identify if you are in CMS or Service Portal use window object as shown below:

Sample

if (window) //you are in CMS
else //you are in Service Portal

See usage in common_resolver_lookup - catalog client script: onLoad_resolver_lookup

Refer Documentation in Usage Examples at https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/build/service-portal/concept/un...

gel to get catalog item sys_id

gel is not supported on Service Portal. Instead you can use g_form.getSysId() to get sys_id for the catalog item (or order guide) in Service Portal.

Refer: https://community.servicenow.com/thread/257865

[robertyoung]

I'm interested specifically in your section on reusable utility functions. We've done the same thing where we have a bunch of code in global UI scripts.

I'm running into a problem where I've added the ui script as a widget dependancy but am still getting: Error while running Client Script "XYZ": ReferenceError: XYZ is not defined

Did this actually work for you?

Our UI Script is marked global and works in the old catalog.

The catalog client script that is calling the function "XYZ" is executing, it has it's UI Type set to "ALL"

I can't figure out why the catalog client script can't "See" the script dependency I added to the widget.

Could you also explain some more about how you managed to get g_form working from that ui script? I'm afraid as soon as the client script can "see" the function from the script include I'll run into that issue you mentioned.

[Russell Hart2]

Did you get this sorted ? I'm seeing similar issue.

[robertyoung]

Sorry for the massive delay. I'm sure you are passed this now but I would be interested in how you solved it. We ended up passing g_form as a parameter from the client scripts into the UI scripts like:

//...
//inside the catalog client script
doUIScript(g_form);
//
//...



//ui script method signature
function doUIScript(g_form){
g_form.setValue("SomeCatVariable","SomeValue");

}