‹ All interview questions

Integration

Your enterprise customer has a critical integration between ServiceNow Incident Management and Jira.

The question

Your enterprise customer has a critical integration between ServiceNow Incident Management and Jira. Production data shows: 500 incidents/day average, peaking at 2,500 during major outages. Current batch MID Server job runs every 15 minutes, processing updates via REST API. However, during last quarter's Black Friday outage, 847 incidents were created in ServiceNow but only 312 synced to Jira within SLA (under 2 minutes), causing dev teams to miss escalations and delay resolution by 45+ minutes on average. Stakeholders demand 'real-time sync' but IT ops warns of API rate limits (10k calls/hour) and MID Server CPU spikes to 95% during peaks. Question: Walk us through your root cause diagnosis approach. Propose 3+ integration architecture options (batch vs real-time vs hybrid) with clear trade-offs. Provide production code example showing the current problematic batch script AND your recommended fix. Explain why your approach scales and what monitoring you'd implement.

Context

In production, batch integrations fail SLAs during volume spikes because they process queued changes at fixed intervals, creating inherent latency. Root cause diagnosis starts with ServiceNow System Logs, MID Server stats (CPU/Memory), and IntegrationHub transaction logs to confirm: API throttling, payload bloat, or unhandled errors. Query syslog for 'REST' errors during peaks, check Flow Designer execution stats, and correlate with incident volume via Performance Analytics. Good answers identify symptoms (delay); great answers quantify impact (e.g., '45min resolution delay = $X lost SLA credits') and trace to specifics like unpaginated queries or missing idempotency.

The Solution

Current Problematic Batch Script (Scheduled Job, runs every 15min):

// Problem: Single bulk query overloads MID Server, no error handling, no dedup
(function() {
    var inc = new GlideRecord('incident');
    inc.addQuery('sys_updated_on', '>', gs.minutesAgo(15));
    inc.addQuery('state', '!=', 7); // Exclude closed
    inc.query();
    while(inc.next()) {
        var jiraPayload = {key: inc.number, fields: {status: inc.state.getDisplayValue()}};
        var r = new sn_ws.RESTMessageV2();
        r.setEndpoint('https://jira.company.com/rest/api/2/issue/' + inc.jira_key);
        r.setRequestBody(JSON.stringify(jiraPayload));
        r.setHttpMethod('PUT');
        var response = r.execute();
        if(response.getStatusCode() != 204) gs.error('Jira sync failed: ' + response.getErrorMessage());
    }
})();

Recommended Fix: Event-Driven Hybrid (Business Rule + Transform Map): Use 'after Update' Business Rule for real-time critical fields (state/priority), fallback to scheduled batch for non-urgent. Why? 80/20 rule: 80% updates are routine (batch), 20% urgent (real-time) avoids rate limits.

// Business Rule: after Update, incident table - Real-time for high-priority
(function executeRule(current, previous) {
    if (current.priority <= 2 && current.state.changes() || current.priority.changes()) { // Critical only
        var grEvent = new GlideRecord('sysevent');
        grEvent.initialize();
        grEvent.setValue('name', 'incident.jira.sync');
        grEvent.setValue('parm1', current.getUniqueValue());
        grEvent.insert();
    }
})(current, previous);

// Event Script: Processes real-time queue with rate limiting
(function runAction(/*void*/context) {
    var id = context.getParameterValue('parm1');
    var inc = new GlideRecord('incident');
    if (!inc.get(id)) return;
    // Rate limit: Check last 10 calls
    var limitCheck = new GlideAggregate('syslog');
    limitCheck.addQuery('level', 'info');
    limitCheck.addQuery('sys_created_on', '>', gs.secondsAgo(60));
    limitCheck.addAggregate('COUNT');
    limitCheck.query();
    if (limitCheck.next() && limitCheck.getAggregate('COUNT') > 10) return;
    // Sync logic here (same as batch but single record)
    gs.info('Jira real-time sync: ' + inc.number);
})(current, previous);

Senior Considerations

  • Trade-offs Matrix: Batch (low cost, high latency); Real-time (Business Rules/Webhooks: zero-latency but chatty APIs); Hybrid (best: SLA compliance w/o overload). Great answers include table comparing throughput/cost/failure modes.
  • Scalability Why: Event-driven scales horizontally (add MID Servers), idempotent (sys_id check prevents dupes), rate-limited (avoids 429s). Handles 2.5k peaks by prioritizing P1/P2 only.
  • Production Hardening: Idempotency via u_jira_last_synced field; retry queue (Transform Map on failure); monitor via Flow Designer dashboards + AIOps for anomaly detection on sync_lag KPI.
  • Edge Cases: Network partitions (dead letter queue), data skew (Jira->ServiceNow conflicts via ECC Queue), audit via sys_audit. Great: Discuss IntegrationHub event persistence.
  • Great vs Good: Good = 'Use REST Message'; Great = Quantifies ROI ('reduces MTTR 45min'), proposes A/B testing via Scoped Apps, references docs.servicenow.com for Event Management scaling.

Bottom line: the hybrid approach protects the SLA during spikes without paying for a fully real-time pipeline.