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

Scripted REST API or OOTB API

Joshua Cassity
Kilo Guru

We have a requirement to allow an external system to submit an item out on our service catalog.   Here's what we are doing using the 'Buy Item' resource using the 'SN_SC' api:

1. Peoplesoft initiates a REST call to begin an onboarding catalog item once approval is gathered for the hire. (this is working)

2. RITM is created and populated with that employee's information. (this is working)

3. Response is sent back to Peoplesoft with the RITM number to save on the approval record.

Item 3 poses an issue for us because the response only gives the REQ number and we really need the RITM number to be sent back in the response (which they'll store in their system) instead because if they need to update the RITM with new information (say Mary's last name changes during onboarding because she got married or her first day was going to be Monday but is now Friday, etc...).

Is the only way to handle such a thing is to create a scripted REST api (which we've never done before so it'll be a learning curve for me) or is there some other mechanism in the header or body to specify what needs to go back in the response?

Thanks for your assistance.

24 REPLIES 24

Moving the second query into the API is creative, though it doesn't avoid the additional query, it just puts it onto the SN side instead of the PeopleSoft side. If it were me, I'd look to avoid having to maintain an updated API through patches and upgrades unless it was really the most appropriate solution. I do like the possibilities of this though




Item 3 poses an issue for us because the response only gives the REQ number and we really need the RITM number to be sent back in the response (which they'll store in their system) instead because if they need to update the RITM with new information (say Mary's last name changes during onboarding because she got married or her first day was going to be Monday but is now Friday, etc...).



Going back to your original reason for the requirement, updating the RITM due to info changes. Something else to consider on pushing updates back to the RITM, is that some fulfillment teams are quicker to fulfill than others and the RITM could be closed while the REQ is still active. Are you going to allow PeopleSoft to update a closed RITM or REQ should information change?


I did as you suggested and it creates the event but gives me an error message instead of returning the RITM number.


Figured it out... sc_req_item_list does not exist.. it's sc_req_item.



Getting the following returned now:



{
  "result": {
  "request_number": "REQ0010182",
  "request_id": "96300c880f720300043106bce1050ef3",
  "ritm_id": "1a300c880f720300043106bce1050ef3",
  "ritm_number": "RITM0010211"
  }
}



Though this now poses an issue when we go to update this we're really updating the variable table options.. oh boy. Looks like another scripted REST API where they'll have to supply us with both the RITM and the name of the variable to be updated. Since that's the case.. idk that we gain much by not simply using the REQ number since we'll have to create a custom REST call to go take that number, query the RITM, query the variables table, find the proper dependant and then update it's value.


Yeah, the extra queries to update the variables would add complexity. Would the updated variables be used after submission for workflow/automation/Bus Rules/Script/etc, or just fulfillment by a person?



If not being used for workflow/automation, you could just provide the PeopleSoft information update as a comment or work note on the RITM for the fulfillment teams instead of a variable update.



If you go that route, you might also want to add the RITM.Comments and Work Notes to your form layout on the Catalog Task above (or below) your Activity filter so that any catalog task associated to the RITM has visibility on the task form to a comment or note added to the RITM. We've done this for other reasons and it helps with visibility on the catalog tasks for comments added on the RITM, especially for items with multiple tasks to different teams. Of course you could also query for the catalog tasks associated to the RITM and perform the same comment/note update to each task too.


I've been able to write the following scripted rest api to update the effective date using both the item options mtom and item options table as such:



find_real_file.png



(function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) {


     


      // Initializing Variables for Usage


      var recordID = request.pathParams.sys_id;


      var effectiveDate = request.pathParams.effective_date;


      var optionID = '';


             


      // Query the Item Option Table to find the RITM provided and it's effective date variable value.


      var gr = new GlideRecord('sc_item_option_mtom');


      gr.addEncodedQuery('request_item.sys_id=' + recordID +'^sc_item_option.item_option_new=61953cb60f200300043106bce1050e58');


      gr.query();


     


      if(gr.next()){


             


              // If found, take that item option and populate it's value with the effective date provided.


              var gr2 = new GlideRecord('sc_item_option');


              gr2.query('sys_id', gr.sc_item_option);


              gr2.query();


             


              if(gr2.next()){


                      // Update the effective date using the date provided.


                      gr2.value = effectiveDate;


                      gr2.update();


              }


      }


      else {


                return new sn_ws_err.BadRequestError('RITM record was not found in ServiceNow to be updated.');


      }


     


      response.setBody({


              RITM: recordID,


              New_Effective_Date: effectiveDate


      });


     


      response.setStatus(200);


     


})(request, response);




Though now I have a question. I'm passing both the system id of the record to be updated and the effective date as part of the relative path but I need to get the effective date to be in the body of the incoming REST message instead because our dates are formatted MM/DD/YYYY in our organizational instances where as in this dummy instance the format is 'YYYY-MM-DD' and the extra '/'s are not playing nice since it thinks another parameter is attempting to be passed.



So two parts:



1. How would the body need to be formatted to include the effective date there?


2. How would I read that body for that specific piece of information to update the record?



Thanks.