← Home
🔥0 DAY
0 XP
Interview Prep · IntegrationHub & REST

INTEGRATIONHUB
INTERVIEW.

Four scenario lessons on REST vs SOAP, IntegrationHub Spokes, authentication profiles, and Flow Designer error handling — each with a runnable simulator trace showing the exact platform behavior.

Pair with the Flow Designer guide and the Discovery guide for full integration coverage.

  1. 1. REST vs SOAP — which one do you pick, and why?

    The upstream vendor supports both REST and SOAP. Which do you wire into IntegrationHub, and how do you justify it in the review?

    How to answer

    • REST is stateless, uses JSON, and maps cleanly to IntegrationHub REST Steps — lower payload, easier to debug in the outbound REST message logs.
    • SOAP is contract-first (WSDL), heavier payload, and better when the vendor mandates WS-Security or strict schemas.
    • In ServiceNow, prefer REST for modern SaaS integrations (Jira, Slack, GitHub) and reserve SOAP for legacy on-prem (SAP, Oracle EBS, older ITSM).
    • Either way, wrap the call in a Subflow with an Action step so error handling and retries live outside the raw HTTP step.

    Reference script

    // REST Message — outbound to Jira
    var r = new sn_ws.RESTMessageV2('Jira Cloud', 'createIssue');
    r.setStringParameterNoEscape('summary', current.short_description);
    r.setRequestHeader('Content-Type','application/json');
    
    var resp = r.execute();
    var status = resp.getStatusCode();      // 201 = created
    var body   = resp.getBody();            // { "id":"10231", "key":"OPS-42" }
    
    if (status !== 201) {
      gs.error('[Jira] create failed ' + status + ' ' + body);
    }

    Pitfall

    Don't call RESTMessageV2 straight from a Business Rule — a slow vendor blocks the transaction. Push the call into an async Subflow or an Event so the record save returns instantly.

  2. 2. IntegrationHub Spokes — what's inside, what's licensed?

    A team wants the Microsoft Teams Spoke. What do Spokes actually give you, and what's the licensing gotcha?

    How to answer

    • A Spoke is a Scoped App containing pre-built Actions (post message, create channel, etc.), authentication profiles, and connection aliases.
    • Actions are consumable inside Flow Designer without writing REST steps — the vendor API is abstracted behind typed inputs and outputs.
    • Spokes require an IntegrationHub subscription tier: Starter, Standard, Professional, or Enterprise — each unlocks a wider Spoke catalog and higher transaction limits.
    • Transactions are counted per outbound Action execution — plan Flows so a single event doesn't fan out into hundreds of billable calls.

    Reference script

    // Using the Microsoft Teams Spoke inside a Flow
    // Trigger: incident.priority changes to 1
    // Action:  Post Message (Teams Spoke)
    inputs.connection = 'msteams_ops_channel';   // connection alias
    inputs.message    = '🚨 P1 ' + current.number + ' — ' + current.short_description;
    
    // The Spoke handles OAuth token refresh + retry
    outputs.message_id = '17245552-abc';

    Pitfall

    A Flow that loops over N records and calls a Spoke Action per row is N transactions, not one. Batch server-side (or use a single bulk Action) before you burn the annual quota in a week.

  3. 3. Authentication profiles — Basic, OAuth 2.0, mutual TLS

    How do you set up OAuth 2.0 for an outbound REST integration, and where does the refresh token actually live?

    How to answer

    • Create an OAuth Provider profile under System OAuth → Application Registry (type: 'Connect to a third-party OAuth Provider').
    • Bind it to a Connection & Credential Alias so Flow Designer / REST messages resolve the token at runtime — never hard-code the client secret in a script.
    • ServiceNow stores access + refresh tokens in oauth_credential; refresh happens automatically before expiry when the token store record has a valid refresh_token.
    • For mutual TLS, upload the client cert to the Certificates table and reference it on the Connection — the platform handles the TLS handshake.

    Reference script

    // Retrieve token programmatically (rarely needed — Spokes do it for you)
    var oa = new sn_auth.GlideOAuthClient();
    var params = { grant_type: 'refresh_token' };
    var tokenResp = oa.requestTokenByRequest('jira_oauth', JSON.stringify(params));
    
    var token = tokenResp.getToken();
    gs.info('access_token expires_in=' + token.getExpiresIn());
    
    // Attach to a REST message
    r.setRequestHeader('Authorization','Bearer ' + token.getAccessToken());

    Pitfall

    Basic Auth with a personal named account works — until that person leaves. Always bind integrations to a dedicated integration user + OAuth or cert, never a human account.

  4. 4. Flow Designer error handling — retries, alternate paths, alerting

    The vendor returned 502 for 4 minutes overnight. Your Flow silently dropped 30 records. What's the correct error-handling pattern?

    How to answer

    • Wrap the risky Action in a Subflow so you can control the return contract, then check the HTTP status code in a Decision step.
    • For transient errors (5xx, 429), throw a script step error inside a retry loop — Flow Designer honors the sys_hub_flow.retry_policy for automatic backoff.
    • For permanent errors (4xx), branch to an alternate path that writes to a queue table and notifies the integration owner.
    • Always log the raw response body — truncated errors in the operations logs are the #1 blocker when triaging production outages.

    Reference script

    // Subflow — resilient outbound call
    try {
      var resp = restStep.execute();          // Action: Send REST Request
      if (resp.statusCode >= 500) throw 'retryable';
      if (resp.statusCode >= 400) {
        gs.eventQueue('integration.dead_letter', current, resp.body, resp.statusCode);
        return { status: 'dropped' };
      }
      return { status: 'ok', id: resp.body.id };
    } catch (e) {
      // Flow Designer retry policy will re-invoke the Subflow
      throw new Error('retryable: ' + e);
    }

    Pitfall

    Catching an error in a Script step and returning success masks the failure — the Flow context shows COMPLETED but the record never left. Re-throw so the platform records the failed run.

Keep going