Any success creating new records with JMeter? (Istanbul, service portal, scoped app, custom tables)

[Jesse Triplett]

Hello,

I'm attempting to create a JMeter script for an Istanbul instance. The script logs into the service portal and submits a form to create a record in custom table (in a scoped app).
What I'm observing on the uiAction step (the POST that should generate the record) is that I only get a response when I submit with a sys_id of -1.
That is great and understandable (there is no sys_id yet).

Doing so I get the response below with the intended sys_id. Doing anything else (attempting to assign a sys_id) comes back with an effectively blank response.

{"result":{"sys_id":"4f84293edb6803000b3d75131f9619af","$$uiNotification":[],"isInsert":true}}

The issue from here - that record is not created. Instead it attempts to assign the sys_id of "-1" to the new record. If no record with a -1 exists it does create one (which is then not possible to delete through any conventional means). When that broken record does exist the insert fails due to a duplicate primary key of -1.

So I'm not quite sure what is missing... I NEED the -1 to be in the uiAction POST step or nothing happens (removing the key/value doesn't work, assignign a value doesn't work, blank string doesn't work...). However if it is there it attempts to assign a -1 and not the sys_id that it ends up returning to me.
Anyone have any insight? Is it even possible to use JMeter? (I noticed in their ATF documentation for istanbul they mention the user cannot create new records using ATF it seems? Would this be why maybe?)
Could it be a service portal javascript executable that's missing since JMETER does not execute javascript?

Any thoughts are appreciated!

[Shahed Shah1]

Hi Jay

JMeter is more of an application for performance/load testing than an actual functional test application. Plus, our internal teams are sensitive at detecting any "unauthorised" load tests. So be careful with how heavy the testing will be with the actual application.

With that safety message out of the way, I'm pretty new to the JMeter game, but I take it that you are breaking it down into two steps:

1. initialise the empty form
2. Submit the form with populated data

The first step is a simple get to incident.do, passing the sys_id=-1 parameter, and you would want to add an extractor at this point to get the sys_id generated to by the platform. For example, using the CSS/JQuery extractor you can use something like input[id="sys_uniqueValue"] and store it in a variable.

In the second step, you will be doing a post to incident.do using that variable along with an identifier for the UI Action. The parameters I normally send are:

sysparm_scope=global

sysparm_want_session_messages=true

sys_target=<table_name>

sys_row=-1  

sys_uniqueName=sys_id

sys_uniqueValue=<sys_id_variable> e.g. ${sysID}

sys_action=<sys_id_of_submit_or_save_ui_action>

// field values

sysparm_ck=<csrf_token>

sysparm_encoded_record=<encoded_version_of_record>

In the ATF there is documentation showing you can submit a form, so you should be able to create a record that way. To be honest here, I've not had any exposure to ATF in ServiceNow... yet. But, I would have thought that you would not need to resort to an external tool. Nevertheless, I hope this gives some food for thought.

Regards

Shahid

[Jesse Triplett]

Thank you Shahid!

For transparency the ultimate intention is to use this for performance testing, not functional testing. We are aware of the current (unfortunately) limited support for load testing and will work with SNow through our account rep for both the immediate and long term needs in that regard separately from the creation of the script.

Thanks for the insight! I'll take another look at my script and report back - as i mentioned above I believe I am POSTing with the -1 and that was the first place I saw the sys_id returned to me (and capture it there), so perhaps the GET step missed being recorded or otherwise is my issue. I'll let you know!

[Shahed Shah1]

No problem, Jay. Good luck with completing your test plan!

- Shahid

[Jesse Triplett]

Hi Shahid,

I checked my script (created using the JMETER recorder functionality) and the scripted steps are a little different but I imagine its because im recording in the service portal. There is no get, and the post thats recorded follows a different URL path to the UI action - {instantUrl}/api/now/sp/uiaction/{uiActionSysId}.

Navigating to the standard UI I think I can see how you arrived at your initial post - the URL follows what you have outlined. I assume the use of "incident.do" is an example but also, just to be clear to any future readers, I'm not intending to make incidents at all only entries in a custom, scoped table (so {targetTable}.do?) with the goal of imitating the user experience in the service portal.

I think I'll need some time to maybe try it out again and plan further, but where my thoughts are now is that I'm wondering if I take the essence of the approach above (using the default servicenow user experience URL to imitate the form?) if its substantially similar enough to the actual UI experience so my load testing results are valid.

I'm not the most experienced with JMETER either.. but from what I understand basically any logic captured in the client script of our widget or any ajax calls on our form are already not properly tested using JMeter. In our case in the Service Portal, we have both (ajax calls on reference fields for expensive validation and prepopulation logic; client script rest calls to external API's) and even client script redirects that occur when the UI Action is submitted. Anyways, these fundamental issue are neither here nor there in terms of being unable to submit my form - if I end up trying to use the default URL patterns and it can submit my service portal form I'll update this thread again!

Thank you!