Anyone know where the sratchpad data for a record is located ?

[poyntzj]

Anyone know where for a record (in this case a kb_knowledge) article, the scratchpad data is stored ?

I am using a UI Action which loads a UI Page and the user can add a new "valid to" date.

What I then do is reset the workflows and set the KB back to draft

At the moment, the process that runs when the reset is triggered will clear all the dates and reloads the form.   An display Business Rule reads some values from our KB categories and places it in the scratchpad.   A Client Script will take that scratchpad data and obtain the lead times and populates the date fields - all good.

What I am trying to do is to locate this scratchpad data and add the new_valid_to date to it.   Of course a UI page cannot do this.

I am trying desperately not to add a new field to the form and add an extra save step or rewrite the reset process (as it would mean writing a few specific ones)

If it was a workflow, I know I can go into the wf_context table, locate the record and read the value for the field scratchpad and update as needed

Of course, nothing like this exists on the kb_knowledge table.

Cheers

[poyntzj]

Little background

At the moment the UI action is there and on the "original" spec, if the type was a "Known Error", the "Change Valid To" appeared and only the relevant workflows were restarted (based on where we were) and that works a treat

They like the way it was implemented so instead of just choosing "Reset to Draft" as per the original spec, they now want the new button

[Brian Dailey1]

Hi Julian,

When you say "locate" the scratchpad data, where exactly are you when trying to use it?   On a page? etc.   The scratchpad object (g_scratchpad) used in display BRs and Client Scripts gets generated when you load an object for display, I believe, and doesn't persist beyond that.   It would only be there while that page is loaded.   From either BR or CS you would access it the same way as:

  g_scratchpad.myvariablename

This is different from the scratchpad available in a workflow context, which is actually a field on the wf_context table that contains name:value pairs, and would be accessible as long as the record exists.   Use of the same name makes it a bit confusing, but they are different beasts.

Is that helpful?   If not, maybe you could provide more detail as to how you are trying to use it.

Thanks,

-Brian

[poyntzj · Accepted solution]

Hi Brian

The idea was to avoid changing a reset routine, but I have now gone via the route - I knew it would not be simple.

What I wanted to do was to simply store the new "Valid To Date" as selected from the called UI Page on the record

I was then going to modify the routine that populates the proposed dates and make it look at that scratchpad value if it existed.

Problem is that the UI Page has no access to the scratchpad and I cannot see it anywhere.

I guess that unlike with a Workflow where I can see the "scratchpad", the scratchpad for a record is truely temporary and is a pity the UI Page cannot get access to it.

[Brian Dailey1]

Hi Julian,

If this type of task has a workflow attached to it, then you could still use that workflow's context (wf_context) record as a repository for your value by storing it in that record's scratchpad field.   It's not as simplistic as you'd probably like, but it should work.   From the client side, you can access and update the record from [wf_context] using a GlideAjax utility to handle it for you on the server-side.   (I don't think a client-side GlideRecord call would work because I don't see any method for it to update your record, as it seems it can only query, delete, or insert a new record).

1. From the client-side, you would want to send your new date value along with the sys_id of your current record as parameters.
2. On your server-side GlideAjax utility, you would create a new GlideRecord and query the [wf_context] table looking for a match to that sys_id value in the 'id' field to find the correct wf context.   Once you have the record, you can write your variable to the scratchpad field of your GlideRecord and then update the record, essentially pushing your value into the table's record so that it is persistent.
3. You can then access the same record later for whatever processing.

Here is their ref on using GlideAjax, as well as a good community article on using it:

GlideAjax - ServiceNow Wiki

GlideAJAX API

Good luck,

-Brian