Parsing JSON From REST API Request

[Mike C2]

Hello all. Long time lurker, first time poster!

To start with, I appreciate everything I've been able to take in over the years. It's only because of this Community that I'm at the point I am now, and whilst that is a "point" of trouble I'm appreciative that I'm at a place of asking for help.

Long story short, I'm working to set up a ServiceNow to ServiceNow integration. What I've currently done;

- On target instance, table has been created, extends import set, necessary fields populated, transform map built

- On target instance, REST user has been created, roles provisioned correctly, validated with REST API EXPLORER that user can provision new tickets

- On source instance the Outbound REST message has been created for a POST to the staging table, the "CONTENT" block of the HTTP request is populated with variables

- On source instance, a business rule has been created to run "ON INSERT" to Incident table in source. It replaces the variables of the HTTP request block with the ticket information and sends it, as well as captures the response and logs information from target instance into the ticket on source instance.

So far EVERYTHING is working except I cannot gather the SYS_ID and NUMBER from the response. Below is the code from my business rule. I'm definitely weak on this subject matter but working to correct that. In checking the syslog I see a few lines of entry that indicate "org.mozilla.javascript.EcmaError: Empty JSON string" so I'm pretty sure my issues reside in parsing the JSON.

(function executeRule(current, previous /*null when async*/) {

// Add your code here
var request = new sn_ws.RESTMessageV2("Target ServiceNow Instance", "create_incident");
request.setStringParameterNoEscape("presincnum", current.number);
request.setStringParameterNoEscape("presincsys", current.sys_id);
request.setStringParameterNoEscape("abrincnum", current.u_client_incident_number);
request.setStringParameterNoEscape("shodes", current.short_description);
request.setStringParameterNoEscape("des", current.description);
request.setStringParameterNoEscape("incsta", current.incident_state);
request.setStringParameterNoEscape("imp", current.impact);
request.setStringParameterNoEscape("urg", current.urgency);
request.setStringParameterNoEscape("pri", current.priority);
request.setStringParameterNoEscape("connam", current.caller_id.name);
request.setStringParameterNoEscape("conema", current.caller_id.email);
request.setStringParameterNoEscape("conite", current.cmdb_ci);
request.setStringParameterNoEscape("addcom", current.comments);
request.setStringParameterNoEscape("rescod", current.close_code);
request.setStringParameterNoEscape("resnot", current.close_notes);
request.setStringParameterNoEscape("respar", current.u_sync_ticket);

var response = request.execute();
var requestBody = request.getRequestBody();
var responseBody = response.getBody();
var httpStatus = response.getStatusCode();

parsedJSON = JSON.parse(responseBody);

var result = parsedJSON["result"];
var targetTicNumber = result[0]["display_value"];
var targetSys_id = result[0]["sys_id"];
current.u_client_sysid = targetSys_id;
gs.log(targetSys_id);

})(current, previous);

[Mike C2]

Hey Michael, create_incident is just the "Name" of my custom HTTP Method. It is still a "POST" type method. I get where you are going though because the POST method SHOULD definitely be returning some sort of response if successful.

[Mike Patel]

last try

gs.log(parameterArr.result[0].display_value);

[Michael Jones - · Accepted solution]

The last thing I can think of would be to perhaps execute the process using credentials with admin and see if that makes any difference. If it does, it might be a role or something getting in the way. If it doesn't work with admin, I'd review the logs on your target instance. Maybe an error is occurring that doesn't stop the record creation, but stops the response?

[Mike C2]

Hey, you're a genius!

Yes, the TARGET instance is now allowing the RESPONSE to be populated! After assigning the admin role to the user on the TARGET instance it's fully working.

In my research for this project I saw a lot of battling answers on what roles are required in order to achieve this integration. I don't want to have this user account with ADMIN rights, so can you indicate what the lowest level of right can be set up for? What would the best practices be for an integration user?

Current;

u_incidents_for_rest

web_service_admin

rest_api_explorer

Web Service Access Only: NOT CHECKED

[Michael Jones -]

Well, at least we now have an idea of what the issue is, but I'm sorry to say it will still take some investigation to figure out. Two of the roles you mention (web_service_admin, rest_api_explorer) are the ones that you typically need, so the issue is not with the REST API, but most likely with ACL's on some of the tables involved in processing. 

Since this is incident-centric, you might try assigning the ITIL role and see if it still works. Otherwise, you will have to play detective, trace the tables that are coming into play, and measure your credentials against the ACL's until you find the right concoction. 

Sorry I don't have a better answer, but at least you've made some headway!