The CreatorCon Call for Content is officially open! Get started here.

Creating Request via inbound action is skipping request numbers

rlehmann
Kilo Sage

Running on London Patch 4 Hot Fix 2.
Created a new inbound action to create a request ticket based on specific criteria.
It has been set as the lowest order inbound action and the "stop processing" check box has been selected.
There are no other inbound actions that target the Request [sc_request] table.
According to the logs, it appears that the system is processing my inbound email message twice, skipping it on the first pass and then creating the request on the second. find_real_file.png I suspect this may be what is causing the REQ numbers to be skipped. In this example, I already have REQ0053770 and expect the inbound action to create REQ0053771, but instead creates REQ0053772, with no record of there ever being a REQ0053771.
The request is being created correctly, but it shouldn't be skipping request numbers during the process.
Here is a copy of the inbound action script running:

createRequest();

function createRequest() {
	// setup variables
    var short_description = email.subject.toString();
	var body = email.body_text.toString();	
	var message = "received from: " + email.origemail + "\n\n" + body;
	var cat_item = 'e2e6fb3d1b0cf7406ec2a82fbd4bcbc3'; // my catalog item sys_id
	var requested_for = email.origemail;
	
	var cart = new sn_sc.CartJS();
	//var cart = new Cart();
	var item =
		{
			'sysparm_id': cat_item,
			'sysparm_quantity': '1',
			'variables': {
				'notes': message
			}
		};
	cart.addToCart(item);
	
	var request =
	{
	  //'special_instructions' : '',
	  'requested_for' : requested_for,
	  //'delivery_address' : '',
	};
	// Place order from cart
	var requestDetails = cart.submitOrder(request);
	//var requestDetails = cart.checkoutCart();

	// update details in the Requested Item
	// pull out the Request Sys ID from the order
	var reqSysID = requestDetails.request_id;

	// update the RITM to have a short description from the email
	var rec = new GlideRecord('sc_req_item');
	rec.addQuery('request', reqSysID);
	rec.query();
	// check for a record
	if (rec.next()) {		
		// get the RITM, should be the only item with this parent
		rec.short_description = short_description;
		rec.comments = message;
		rec.update();
	}
	var ritmSysID = rec.sys_id;
	var email_log = new GlideRecord('sys_email');
	email_log.addQuery('uid', email.uid);
	email_log.orderByDesc('sys_created_on');
	email_log.query();
	var email_sys = "";
	if (email_log.next()) {
		email_sys = email_log.sys_id;
		GlideSysAttachment.copy('sys_email', email_sys, 'sc_req_item', ritmSysID);
	} else {
		email_sys = 0;
		GlideSysAttachment.copy('sys_email', email_sys, 'sc_req_item', ritmSysID);
	}
}

Anyone have any suggestions as to why the request numbers are skipping?

As always, thanks for any and all assistance.

Cheers!
Ron

6 REPLIES 6

Allen Andreas
Administrator
Administrator

From those highlights, it's just letting you know that it did meet the criteria for that inbound action, but then it didn't take any action with it...usually due to script issue. Then it's telling you that it's stopping the processing and won't look anywhere else.

With Incidents, Requests, etc...if you open a new record, as in the page to create one, even without fully submitting it, you use up that number. You can turn this off in your system properties, but that's most likely what's going on here.


Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

Michael Fry1
Kilo Patron

Looks like you're using the CartJS API for Scoped app, vs Cart() API:

https://docs.servicenow.com/bundle/london-application-development/page/script/server-scripting/refer...

Maybe that has something to do with it?

Thanks for the suggestion Michael. but updating to using the Cart() API is resulting in the exact same behavior.

It was definitely worth a try, but unfortunately didn't correct the issue.

I read a pile of forum posts over the past few days and there was mention of this being a bug at one time in a previous version of the platform, so I will try logging a HI ticket and see if it may be an issue within the system.

Inactive_Use407
Giga Contributor

Hi, @rlehmann

 

Did you get any solutions?

I am with the same problem, I opened ticket in HI, however the answer given by them is that this is even the expected behavior 😞