REST API to use for Incidents and Requests

[Nisha30]

Hi experts,

I know REST API for multiple tables as Inbound and Outbound.

Can anyone suggest what is the best way so That

1. I have one single API which determines based on certain value if that should be inserted as Incident or Request.

2. The third party application they only have single ticket type and based on specific value we have to decide if this is INC or REQ 

3. Its bidirectional and we need to send back any updates as well

Any leads on this please.

THanks

[Vrushali Kolte]

Hello @Nisha30 ,

To meet this requirement, you can utilize a Scripted REST API. Within the resource script, you can access the "request" object to read values from the incoming API request. Based on your conditions, you can then insert a record into either the Incident (INC) or Request (REQ) table as appropriate.

Please refer below docs for more info on Scripted Rest API.

https://docs.servicenow.com/bundle/tokyo-application-development/page/integrate/custom-web-services/...

https://developer.servicenow.com/dev.do#!/learn/courses/washingtondc/app_store_learnv2_rest_washingt...

If my answer solves your issue, please mark it as Accepted ✔️ & Helpful👍!

[Rajesh Chopade1]

Hi @Nisha30 

You can achieve this requirement with single ’Scripted REST API’ & two resources in API.

Create a single REST API that accepts incoming requests from the third-party application. The API will inspect the payload to determine whether to create an Incident or a Request.

1) Example API Design

• Endpoint: /api/custom/ticket
• Method: POST
• Request Body:
  

{
  "ticket_type": "incident",  // or "request"
  "short_description": "Issue description",
  "priority": "High",
  "caller_id": "user@example.com",
  ...
}

2) Create a new Scripted REST API:

• Name: Ticket API
• API Name: ticket
• API Namespace: custom

3) Create a Resource:

• HTTP Method: POST
• Script: Add a script to inspect the ticket_type and decide whether to insert an Incident or Request.

Here's an example of a script that could be used in your Scripted REST API Resource:

(function processRequest(request, response) {
    var requestBody = request.body.data;  // Get the request payload

    var ticketType = requestBody.ticket_type;  // Inspect the ticket type
    var gr;

    if (ticketType === 'incident') {
        gr = new GlideRecord('incident');
    } else if (ticketType === 'request') {
        gr = new GlideRecord('sc_request');
    } else {
        response.setStatus(400);
        response.setBody({ error: 'Invalid ticket_type value' });
        return;
    }

    // Set common fields
    gr.short_description = requestBody.short_description;
    gr.priority = requestBody.priority;
    gr.caller_id = requestBody.caller_id;
    // ... map other fields

    var sysId = gr.insert();  // Insert the record and get the sys_id

    // Prepare the response
    response.setStatus(201);
    response.setBody({
        message: ticketType + ' created successfully',
        sys_id: sysId
    });

})(request, response);

4) Receiving Updates from the Third-Party System

• Update Resource: Create another resource in the same API to handle updates, using the PUT or PATCH HTTP method.
• Script: Similar to the creation process, but with logic to fetch the existing record by sys_id and update its fields.

(function processRequest(request, response) {
    var requestBody = request.body.data;

    var sysId = requestBody.sys_id;
    var ticketType = requestBody.ticket_type;
    var gr;

    if (ticketType === 'incident') {
        gr = new GlideRecord('incident');
    } else if (ticketType === 'request') {
        gr = new GlideRecord('sc_request');
    } else {
        response.setStatus(400);
        response.setBody({ error: 'Invalid ticket_type value' });
        return;
    }

    if (gr.get(sysId)) {
        // Update fields
        gr.short_description = requestBody.short_description;
        gr.priority = requestBody.priority;
        gr.update();

        response.setStatus(200);
        response.setBody({
            message: ticketType + ' updated successfully',
            sys_id: sysId
        });
    } else {
        response.setStatus(404);
        response.setBody({ error: 'Record not found' });
    }

})(request, response);

Sending Updates to the Third-Party System

• Outbound Integration: Set up an outbound REST message or a script to send updates back to the third-party system whenever an Incident or Request is updated.

Automation with Business Rules

To ensure updates are sent automatically:

1. Create a Business Rule:
• Table: Incident and/or Request (sc_request)
• Trigger: After Update
• Script: Send the update using a REST message or HTTP request back to the third-party system.

Example Business Rule Script

(function executeRule(current, previous /*null when async*/) {
    var restMessage = new sn_ws.RESTMessageV2();
    restMessage.setEndpoint('https://third-party-system.com/api/update');
    restMessage.setHttpMethod('POST');

    var requestBody = {
        sys_id: current.sys_id.toString(),
        ticket_type: current.getTableName() === 'incident' ? 'incident' : 'request',
        short_description: current.short_description.toString(),
        priority: current.priority.toString()
        // ... other fields
    };

    restMessage.setRequestBody(JSON.stringify(requestBody));

    var response = restMessage.execute();
})(current, previous);

I hope my answer helps you to resolve your issue, if yes please mark my answer helpful & correct

THANK YOU

rajesh chopade.

[Nisha30]

Hi @Rajesh Chopade1 

Thankyou very much for that explanation it was really a very great example and start.

One thing is it best to have scripted API or to have separate API for each INC and REQ, as the third party source thay only have single ticket Type= INC 

Thanks

[Rajesh Chopade1 · Accepted solution]

Hi @Nisha30 

Depends on your requirement you can decide, where you go with single API or dedicated.

Following are the cons and pros of both.

• Scripted API (Unified Endpoint):
• Pros:
• Simplified Interface: Having a single API endpoint that handles all types of requests can simplify client interaction, especially if the operations on different ticket types are similar.
• Maintenance: Easier to maintain and update since changes are centralized.
•  
• Cons:
• Complex Logic: May require more complex logic within the API to determine how to handle different requests.
• Scalability: As the number of request types increases, the endpoint may become harder to manage.
•  
• Separate APIs (Dedicated Endpoints):
• Pros:
• Simplicity: Each endpoint is simpler since it only handles one type of operation.
• Clarity: Clear separation of responsibilities, making it easier for developers to understand and use.
•  
• Cons:
• Maintenance Overhead: More endpoints to maintain, especially if there are many similar operations.

i hope my answer helps you to resolve your issue, if yes please mark my answer correct and helpful.

THANK YOU

rajesh.