Skip to main content

Integration Hub

Detailed Summary of ServiceNow Integration Hub Series

This series by Rohit provides a comprehensive guide to Integration Hub in ServiceNow, focusing on activating Integration Hub, understanding spokes, and building custom integrations with external systems like Jira, Zoom, and Okta.

Video 1: Introduction to Integration Hub

This video serves as an introduction to the Integration Hub series, outlining its purpose and key concepts. Rohit emphasizes the importance of Flow Designer as a prerequisite for understanding Integration Hub.

Key points covered:

  • Series Focus: Integration Hub in ServiceNow.
  • Prerequisite: Viewers are strongly recommended to watch Rohit's complete Flow Designer series before proceeding with Integration Hub, as Integration Hub is built upon Flow Designer.
  • Definition of Integration Hub: Integration Hub is described as a mechanism or technique within Flow Designer that facilitates low-code integration between ServiceNow and third-party systems (e.g., Google, Amazon, Zoom, Jira, Slack, etc.).
  • Integration Hub Activation:
    • Chargeable Feature: Integration Hub is a chargeable component. Users are advised to consult with their ServiceNow account team regarding licensing costs before activation and usage in customer environments.
    • Activation Process (Customer Environment): Activation in customer environments requires submitting a request through support.servicenow.com using corporate login credentials.
    • Activation Process (PDI): Activation in Personal Developer Instances (PDIs) is demonstrated directly within the PDI interface via "Activate Plugin."
  • Spokes Explained:
    • Spokes as Packages: Spokes are defined as packages or plugins within Integration Hub that contain pre-built actions and flows for specific third-party applications (e.g., Jira spoke, Zoom spoke, Microsoft AD spoke, etc.).
    • Out-of-Box Activities: Spokes provide out-of-box activities (actions) that can be readily used in Flow Designer Flows, reducing the need for custom development.
    • Example Spokes: Jira spoke, Zoom spoke, Slack spoke, etc.
  • Pre-Integration Considerations: Rohit outlines key factors to consider before integrating ServiceNow with any external system:
    1. Why Integrate? (Purpose): Clearly define the business purpose of the integration. Example: Jira integration to synchronize stories and issues between ServiceNow and Jira.
    2. Trigger Point: Determine the triggering event that initiates the integration. Examples: Story creation, Story update, Scheduled job, Inbound email, etc.
    3. Type of Integration (Inbound/Outbound/Bidirectional):
      • Outbound: Sending data from ServiceNow to the external system (e.g., ServiceNow to Jira - sending story data).
      • Inbound: Receiving data into ServiceNow from the external system (e.g., Jira to ServiceNow - receiving issue updates).
      • Bidirectional: Both sending and receiving data between systems.
    4. Endpoint URL: Identify the specific URL of the target external system's API endpoint. This is the address where ServiceNow will send requests.
    5. Credentials: Determine the authentication method and required credentials for accessing the external system's API. Common credential types: API Key, Basic Authentication (Username/Password), OAuth 2.0.
    6. Request Type (Method): Identify the HTTP request method required by the external system's API (e.g., POST for creating, GET for retrieving, PUT for updating).
    7. Request Body: Define the format and structure of the data to be sent in the request body (typically JSON format for REST APIs).
    8. Query Parameters: For GET requests, determine if query parameters are needed to filter or specify the data to be retrieved (e.g., filtering Jira stories by status).
    9. Response Body: Understand the format and structure of the response data returned by the external system's API (typically JSON format).
    10. Response Codes: Learn about standard HTTP response codes (e.g., 200 OK, 201 Created, 404 Not Found) and their meaning in the context of the integration.
    11. Documentation (Read and Build):
      • Read External System Documentation: Emphasizes the importance of reading the API documentation of the external system to understand its API endpoints, authentication methods, request/response formats, and best practices.
      • Build Integration Documentation: Advises creating clear documentation for your ServiceNow integrations so that others can understand, use, and maintain them.
  • Activating Integration Hub in PDI: Demonstrates the steps to activate the Integration Hub plugin in a Personal Developer Instance (PDI) via "Activate Plugin" search and selecting "IntegrationHub Installer."

Video 2: Custom Jira Action (Create Issue)

This video begins building a custom Jira action within Integration Hub, focusing on creating Jira issues from ServiceNow stories. Rohit outlines the integration purpose, trigger, and necessary Jira API details.

Key points covered:

  • Custom Jira Action - "Create Jira Issue": Starts building a custom Flow Designer Action to create Jira issues from ServiceNow story records.
  • Integration Purpose (Jira Story/Issue Sync): Defines the integration purpose as synchronizing stories created in ServiceNow to Jira as issues.
  • Trigger (Flow - Story Creation): Specifies that the integration will be triggered by a Flow Designer Flow that runs whenever a ServiceNow "Story" record is created (Outbound integration).
  • Jira API Documentation (Crucial): Emphasizes the importance of consulting the Jira API documentation ("Jira Cloud platform REST API") for details on API endpoints, authentication, request formats, and response formats.
  • Jira API - Create Issue Endpoint: Identifies the Jira API endpoint for creating issues: /rest/api/3/issue (using POST method).
  • Jira Authentication (API Token): Explains the Jira API authentication method using email address and API token (API Key).
  • Header Parameters: Identifies required HTTP Header parameters for Jira API requests:
    • Accept: application/json
    • Content-Type: application/json
  • Request Body (JSON Payload): Shows a sample JSON request body for creating a Jira issue, highlighting key fields like project, issuetype, summary, and description.
  • Creating a Custom Action in Flow Designer - "Jira Create Issue": Starts creating a new Custom Action in Flow Designer named "Jira Create Issue."
    • Input Parameters: Defines Input Parameters for the Custom Action:
      • Short Description: String (Mandatory).
      • Description: String (Mandatory).
    • Rest Step Action: Adds a "REST Step" Action to the Custom Action to handle the API call to Jira.
    • Connection Alias (Placeholder): Initially leaves the "Connection Alias" field blank, indicating that Connection and Credential Alias setup will be covered in the next video.
    • Method: Sets the HTTP Method to "POST."
    • Resource Path (Placeholder): Sets the Resource Path to /rest/api/3/issue (the Jira Create Issue endpoint).
    • Headers: Adds Header parameters:
      • Accept: application/json
      • Content-Type: application/json
    • Request Content Type: Sets Request Content Type to "Text."
    • Request Body (Placeholder): Initially leaves the Request Body blank, indicating that JSON payload construction will be covered later.

Video 3: Connection and Credential Aliases

This video focuses on setting up Connection and Credential Aliases in ServiceNow, essential for secure and manageable API integrations. Rohit explains the concept of aliases and demonstrates their creation for Jira integration.

Key points covered:

  • Connection and Credential Aliases Explained:
    • Aliases as Nicknames: Connection and Credential Aliases are introduced as nicknames or pointers to connection and credential details. They provide a level of abstraction and simplify integration management.
    • Three Components of an Alias:
      • Alias: The nickname itself (e.g., "Jira Custom").
      • Connection: Stores connection details like the base URL of the external system (e.g., Jira instance URL).
      • Credential: Stores authentication credentials (e.g., username/password, API key, OAuth tokens) for accessing the external system.
    • Benefits of Aliases: Centralized management of connection and credential details, improved security, and easier updates (e.g., changing password in one place).
  • Creating a Connection and Credential Alias for Jira: Provides a step-by-step guide to create a Connection and Credential Alias for Jira integration.
    • Navigating to Connection and Credential Aliases: Accessing the "Connection & Credential Aliases" module in ServiceNow.
    • Creating a New Alias: Clicking "New" to create a new Alias record.
    • Alias Type: Selecting "Connection and Credential Alias" as the Alias Type.
    • Alias Name: Setting the Alias Name to "Jira Custom."
    • Configuration Template: Selecting "Basic Auth Configuration Template" as the Configuration Template. This template pre-configures the Alias for basic authentication (username/password).
    • Creating New Connection and Credential: Clicking the "Create New Connection & Credential" related link within the Alias record.
    • Connection Name: Setting the Connection Name to "Jira Custom Spoke Connection."
    • Connection URL: Entering the Jira instance URL (e.g., https://snowexpert-rohit.atlassian.net).
    • Credential Alias (Auto-populated): The Credential Alias field is auto-populated based on the Connection Alias.
    • Authentication Details (Username/Password): Shows how to enter Jira authentication details:
      • Username: Jira email address.
      • Password: Jira API Token (generated in Jira profile settings).
    • Generating Jira API Token: Demonstrates how to generate an API Token in Jira:
      • Jira Settings -> Atlassian account -> Security -> API tokens -> Create API token.
      • Copying the generated API Token.
    • Addressing Password Encryption Error: Troubleshooting a common error "Password value is too long..." during credential creation, caused by password field length limitations in the discovery_credential_alias table.
      • Resolution: Increasing the "Maximum length" of "Password 2" fields in the discovery_credential_alias table to 1000.
    • Saving Connection and Credential: Saving the Connection and Credential record after entering authentication details.
    • Verifying Connection: Verifying that the Connection status is "Established" after saving.
  • Selecting Connection Alias in Custom Action: Returning to the "Jira Create Issue" Custom Action from Video 2 and selecting the newly created "Jira Custom" Connection Alias in the "REST Step" action.
  • Base URL Auto-Population: Demonstrates that after selecting the Connection Alias, the "Base URL" field in the REST Step action is automatically populated from the Connection Alias configuration.

Video 4: Request Body and JSON Parser

This video focuses on constructing the Request Body for the Jira API call and using the JSON Parser to process the Jira API response. Rohit shows how to build the JSON payload and extract relevant data from the response.

Key points covered:

  • Setting up Request Body (JSON Payload): Focuses on constructing the JSON Request Body for the Jira Create Issue API call within the "Jira Create Issue" Custom Action.
  • Using Script Step for JSON Construction: Demonstrates using a "Script Step" Action to dynamically build the JSON Request Body using JavaScript code.
    • Script Step Name: "JSON Build."
    • Script Code: JavaScript code to create a JSON object (jsonBody variable) that matches the required Jira Create Issue request format (as per Jira API documentation).
      • Hardcoded Values (Initial): Initially uses hardcoded values for project.key, issuetype.id, summary, and description within the JSON payload for testing purposes.
      • Dynamic Values (Later): Indicates that these hardcoded values will be replaced with dynamic values from Input Parameters later.
    • Output Variable - "bodyJson" (JSON Object): Defines an Output Variable named "bodyJson" of type "JSON Object" in the Script Step to store the constructed JSON payload.
    • Script Output Assignment: outputs.bodyJson = jsonBody; Assigns the constructed JSON payload (jsonBody) to the "bodyJson" Output Variable.
  • Mapping Request Body in REST Step: In the "REST Step" Action, sets the "Request content type" to "Text" and maps the "Request body" to the "bodyJson" Output Variable from the "JSON Build" Script Step.
  • Testing Initial Integration (Hardcoded Values): Tests the Custom Action with hardcoded values in the JSON payload by clicking "Test" and verifying that a Jira issue is created in the specified Jira project with the hardcoded summary and description.
  • JSON Parser for Response Processing: Introduces the "JSON Parser" Action to process the JSON response received from the Jira API after creating an issue.
    • JSON Parser Action: Adds a "JSON Parser" Action after the "REST Step" Action.
    • Source Data: Sets the "Source Data" for the JSON Parser to the "Response body" from the "REST Step" Action.
    • Sample Response Body (for Schema Generation): Pastes a sample JSON response body (obtained from Jira API documentation or a previous successful API call) into the JSON Parser configuration.
    • Generate Target Structure: Clicks "Generate target structure" in the JSON Parser to automatically create Output Variables based on the structure of the sample JSON response body. This automatically creates Output Variables for id, key, self, etc., based on the JSON response structure.
  • Output Variables from JSON Parser: Explains that the JSON Parser automatically creates Output Variables based on the JSON response structure, making it easy to access data from the response in subsequent Actions.
  • Updating Flow to Use Dynamic Values (Input Parameters): Modifies the "JSON Build" Script Step to use dynamic values from the "Short Description" and "Description" Input Parameters of the Custom Action instead of hardcoded values in the JSON payload.
    • Dynamic Summary: inputs.short_description
    • Dynamic Description: inputs.description
  • Testing with Dynamic Values: Tests the Custom Action again with dynamic values for Short Description and Description provided in the Test input, verifying that Jira issues are created with the dynamically provided values.
  • Output Parameters (Key and ID): Defines Output Parameters for the Custom Action: "Key" and "ID" (both String type) to return the Jira Issue Key and ID from the JSON Parser output.
  • Mapping JSON Parser Output to Action Outputs: Maps the "Key" and "ID" Output Variables of the Custom Action to the corresponding Output Variables generated by the JSON Parser ("key" and "id" from the parsed JSON response).
  • Publishing Custom Action: Publishes the "Jira Create Issue" Custom Action to make it available for use in Flows.

Video 5: Jira Spoke Integration

This video transitions to using the out-of-box Jira Spoke, showcasing how to leverage pre-built Jira Actions and comparing them to the custom Action built in previous videos. Rohit demonstrates creating, updating, and commenting on Jira issues using Jira Spoke Actions.

Key points covered:

  • Introduction to Jira Spoke: Introduces the out-of-box Jira Spoke for Integration Hub, highlighting its benefits:
    • Pre-built Actions: Jira Spoke provides a library of pre-built Actions for common Jira operations (creating issues, updating issues, adding comments, assigning issues, etc.).
    • Reduced Development Time: Using Jira Spoke Actions significantly reduces development time compared to building custom Actions from scratch.
  • Installing Jira Spoke: Demonstrates how to install the Jira Spoke plugin in ServiceNow via the "Plugins" module (searching for "Jira Spoke"). Notes that Jira Spoke is a paid plugin.
  • Jira Spoke Actions - Overview: Provides a quick overview of the Jira Spoke Actions available, accessible under the "Jira" category in Flow Designer Action selection.
  • Use Case - Story Synchronization (Create, Update, Comment): Outlines a use case for synchronizing ServiceNow Story records with Jira issues, covering three key operations:
    1. Create Issue (ServiceNow to Jira): When a Story is created in ServiceNow, create a corresponding Issue in Jira.
    2. Update Issue (ServiceNow to Jira): When a Story is updated in ServiceNow, update the corresponding Issue in Jira.
    3. Add Comment (ServiceNow to Jira): When a comment is added to a Story in ServiceNow, add the same comment to the corresponding Issue in Jira.
  • Creating a Flow - "Jira Issue Create (Spoke)": Creates a new Flow Designer Flow named "Jira Issue Create (Spoke)" to demonstrate creating Jira issues using Jira Spoke Actions.
    • Trigger (Record Created - Story): Sets the Flow trigger to "Record Created" on the "RM Story" table.
    • Create Issue Action (Jira Spoke): Adds the "Create Issue" Action from the Jira Spoke.
      • Project Key: Selects the "Training" Jira project.
      • Issue Type: Selects "Story" Issue Type.
      • Summary: Maps to "Trigger Record - RM Story - Short Description."
      • Description: Maps to "Trigger Record - RM Story - Description."
    • Update Record Action (Story - Jira Details): Adds an "Update Record" Action to update the ServiceNow Story record with Jira Issue details.
      • Record: "Trigger Record - RM Story."
      • Fields to Update:
        • Jira Key: Mapped from "Create Issue - Jira Issue - Key."
        • Jira ID: Mapped from "Create Issue - Jira Issue - ID."
        • Jira URL: Mapped from "Create Issue - Jira Issue - Self (URL)."
  • Creating a Flow - "Jira Issue Update (Spoke)": Creates another Flow named "Jira Issue Update (Spoke)" to demonstrate updating Jira issues using Jira Spoke Actions.
    • Trigger (Record Updated - Story): Sets the Flow trigger to "Record Updated" on the "RM Story" table.
    • Update Issue Action (Jira Spoke): Adds the "Update Issue" Action from the Jira Spoke.
      • Issue ID: Maps to "Trigger Record - RM Story - Jira ID."
      • Summary: Maps to "Trigger Record - RM Story - Short Description."
      • Description: Maps to "Trigger Record - RM Story - Description."
  • Creating a Flow - "Jira Add Comment (Spoke)": Creates a third Flow named "Jira Add Comment (Spoke)" to demonstrate adding comments to Jira issues using Jira Spoke Actions.
    • Trigger (Record Updated - Story - Work Notes Change): Sets the Flow trigger to "Record Updated" on the "RM Story" table, with a condition to trigger only when "Work notes changes."
    • Add Comment Action (Jira Spoke): Adds the "Add Comment" Action from the Jira Spoke.
      • Issue ID: Maps to "Trigger Record - RM Story - Jira ID."
      • Comment: Maps to "Trigger Record - RM Story - Work notes."
  • Testing Jira Spoke Flows: Demonstrates testing the Jira Spoke Flows by:
    • Creating a new Story in ServiceNow and verifying that a corresponding Issue is created in Jira and Jira details are updated in ServiceNow.
    • Updating the Short Description and Description of a ServiceNow Story and verifying that the corresponding Issue is updated in Jira.
    • Adding a Work Note to a ServiceNow Story and verifying that the same Work Note is added as a Comment to the corresponding Issue in Jira.

Video 6: Bidirectional Jira Integration (Webhooks)

This video focuses on setting up bidirectional Jira integration using Webhooks, allowing real-time updates from Jira to ServiceNow. Rohit demonstrates configuring Jira Webhooks and handling Jira events in Flow Designer.

Key points covered:

  • Bidirectional Jira Integration: Explains the concept of bidirectional integration, enabling data flow in both directions between ServiceNow and Jira.
  • Webhooks for Inbound Updates: Introduces Jira Webhooks as the mechanism for receiving real-time updates from Jira to ServiceNow. Webhooks are HTTP callbacks triggered by events in Jira (e.g., issue updates, issue creation).
  • Jira Webhook Configuration: Demonstrates the steps to configure a Webhook in Jira to send events to a ServiceNow endpoint.
    • Creating Jira Webhook: Navigating to Jira "System settings" -> "Webhooks" and creating a "New Webhook."
    • Webhook URL (Callback URL from ServiceNow): Emphasizes the need for a Callback URL from ServiceNow to configure the Jira Webhook. This Callback URL is generated in ServiceNow.
    • Webhook Events: Selecting relevant Jira events to trigger the Webhook (e.g., "Issue Created," "Issue Updated").
  • ServiceNow Webhook Registry: Explains the "Jira Webhook Registries" module in ServiceNow, used to register and configure ServiceNow as a Webhook receiver for Jira events.
    • Creating Webhook Registry Record: Creating a new "Jira Webhook Registry" record in ServiceNow.
    • Registry Name: Setting the Registry Name (e.g., ServiceNow Instance URL).
    • Token Verification: Generating a Secure Token and Verification Token in ServiceNow and configuring them in the Jira Webhook settings.
    • Callback URL Generation: Clicking the "Callback URL" UI Action in the Webhook Registry record to generate the ServiceNow endpoint URL for the Jira Webhook.
  • ServiceNow Webhook Routing Policies: Introduces "Jira Webhook Routing Policies" in ServiceNow, used to define how incoming Jira Webhook events are processed and routed to Flows or Subflows.
    • Creating Routing Policy Record: Creating a new "Jira Webhook Routing Policies" record.
    • Policy Label: Setting a Policy Label (e.g., ServiceNow Instance URL).
    • Default Answer Flow: Selecting a default Subflow to handle incoming Webhook events. In this case, the out-of-box "Process Jira Event" Subflow is initially selected.
  • Process Jira Event Subflow (Out-of-Box): Mentions the out-of-box "Process Jira Event" Subflow, designed to handle incoming Jira Webhook events.
  • Testing Bidirectional Integration (Issue Update from Jira): Demonstrates testing the bidirectional integration by:
    • Updating an Issue in Jira (e.g., changing the description).
    • Verifying that the update is automatically reflected in the corresponding ServiceNow Story record via the Jira Webhook and "Process Jira Event" Subflow.
  • Customizing "Process Jira Event" Subflow: Copies and customizes the out-of-box "Process Jira Event" Subflow to add custom logic and logging.
  • Updating Routing Policy to Use Custom Subflow: Updates the "Jira Webhook Routing Policies" record to use the customized copy of the "Process Jira Event" Subflow instead of the out-of-box version.
  • System User Context for Subflow: Changes the Run As context of the customized Subflow to "System User" to avoid permission issues when processing Webhook events triggered by external systems.
  • Enhanced Logging in Custom Subflow: Adds logging statements within the customized Subflow to track Webhook events and data flow.

Video 7: Zoom Spoke Integration

This video focuses on integrating ServiceNow with Zoom using the out-of-box Zoom Spoke. Rohit demonstrates creating Zoom channels, posting messages to channels, and creating Zoom meetings from ServiceNow Incidents.

Key points covered:

  • Zoom Spoke Integration: Introduces the Zoom Spoke for Integration Hub, enabling integration with Zoom for communication and meeting automation. Notes that the Zoom Spoke is a paid plugin.
  • Use Case - Incident Collaboration with Zoom: Outlines a use case for using Zoom Spoke to enhance Incident Management:
    1. Create Zoom Channel (P1 Incidents): Automatically create a Zoom channel when a P1 (Priority 1) Incident is created in ServiceNow for real-time collaboration.
    2. Post Work Notes to Zoom Channel: Automatically post work notes added to the Incident to the associated Zoom channel, keeping stakeholders informed.
    3. Create Zoom Meeting Button: Add a UI Action button ("Create Zoom Meeting") to the Incident form to allow agents to easily create Zoom meetings related to the Incident.
  • Zoom App Marketplace and API Credentials: Demonstrates creating a Zoom App in the Zoom App Marketplace to obtain API credentials (Client ID, Client Secret) required for Integration Hub configuration.
    • Creating Zoom App: Navigating to Zoom App Marketplace -> Develop -> Build App -> Selecting "OAuth" App type -> Web application.
    • Configuring Zoom App:
      • App Name: "ServiceNow."
      • OAuth Flow: "Authorization Code."
      • Redirect URL: ServiceNow Instance URL + /oauth_redirect.do.
      • Scope Configuration: Enabling relevant scopes for Team Chat, Meeting, and User access in the Zoom App configuration.
      • Client ID and Client Secret Retrieval: Copying the Client ID and Client Secret from the Zoom App credentials.
  • ServiceNow Zoom Connection Configuration: Shows how to configure the Zoom Connection in ServiceNow using the obtained Zoom API credentials.
    • Navigating to Zoom Connection: Accessing the "Zoom" card under "Connections" in Flow Designer.
    • Configuring Connection: Clicking "Configure" on the Zoom Connection card.
    • OAuth Entity: ServiceNow Instance Name.
    • Client ID and Client Secret: Pasting the Client ID and Client Secret from the Zoom App.
    • OAuth Redirect URL: Entering the ServiceNow Instance URL + /oauth_redirect.do.
    • Get OAuth Token: Clicking "Get OAuth Token" to authorize the connection and obtain an OAuth Token.
  • Creating a Flow - "Create Zoom Channel (P1 Incidents)": Creates a Flow Designer Flow to automatically create Zoom channels for P1 Incidents.
    • Trigger (Record Created - Incident): Sets the Flow trigger to "Record Created" on the "Incident" table, with a condition to trigger only for Priority 1 Incidents.
    • Create Channel Action (Zoom Spoke): Adds the "Create Channel" Action from the Zoom Spoke to create a Zoom channel.
      • User ID: Statically sets the User ID to Rohit's email address (for demonstration; in real-world scenarios, you would dynamically determine the User ID).
      • Channel Name: Sets the Channel Name to "Incident-" + Incident Number.
      • Channel Type: "New Chat."
    • Update Record Action (Incident - Channel Link): Adds an "Update Record" Action to update the Incident record with the Zoom Channel Link.
      • Field: "Zoom Channel Link."
      • Value: Mapped from "Create Channel - Zoom Channel - Channel ID."
  • Creating a Flow - "Post Work Notes to Zoom Channel": Creates another Flow to automatically post Incident Work Notes to the associated Zoom channel.
    • Trigger (Record Updated - Incident - Work Notes Change): Sets the Flow trigger to "Record Updated" on the "Incident" table, triggering only when "Work notes changes."
    • Send Chat Message Action (Zoom Spoke): Adds the "Send Chat Message" Action from the Zoom Spoke to post messages to the Zoom channel.
      • User ID: Statically sets the User ID to Rohit's email address.
      • Channel: Maps to "Trigger Record - Incident Record - Zoom Channel Link."
      • Message (Inline Script): Uses Inline Scripting to extract the latest Work Note entry from the "Work notes" Journal field and use it as the message content.
  • Creating a Subflow - "Create Zoom Meeting": Creates a Subflow to handle Zoom meeting creation.
    • Input Parameter - "Incident Number": Defines an Input Parameter "Incident Number" (String type) for the Subflow.
    • Output Parameter - "Zoom Link": Defines an Output Parameter "Zoom Link" (String type) to return the Zoom meeting join URL.
    • Lookup Record Action (Incident Lookup): Looks up the Incident record based on the Input "Incident Number."
    • Create Meeting Action (Zoom Spoke): Adds the "Create Meeting" Action from the Zoom Spoke to create a Zoom meeting.
      • User ID: Statically sets the User ID to Rohit's email address.
      • Meeting Type: "Scheduled Meeting."
      • Schedule Time and Duration: Statically sets the meeting time and duration (for demonstration).
      • Topic: "Incident-" + Incident Number + "-" + Incident Short Description.
    • Assign Subflow Output Action (Zoom Link): Assigns the "Join URL" from the "Create Meeting" Action's Output to the "Zoom Link" Output Parameter of the Subflow.
    • Send Chat Message Action (Post Meeting Link to Channel): Adds a "Send Chat Message" Action to post the Zoom meeting link to the associated Zoom channel (using the Incident's "Zoom Channel Link").
  • Creating UI Action - "Create Zoom Meeting": Creates a UI Action button on the Incident form to call the "Create Zoom Meeting" Subflow.
    • UI Action Properties: Table: "Incident," UI Action Name: "Create Zoom Meeting," Form Button.
    • Server-Side Script (UI Action Script): Pastes the code snippet for calling the "Create Zoom Meeting" Subflow.
      • Input Parameter Passing: Passes the Incident Number to the Subflow's "Incident Number" Input Parameter.
      • Output Handling: Retrieves the "Zoom Link" Output Parameter from the Subflow and updates the Incident record's "Meeting link" field with the Zoom meeting URL.
      • current.update(): Includes current.update() to save the changes to the Incident record.
  • Testing Zoom Spoke Integration: Demonstrates testing the Zoom Spoke integration by:
    • Creating a P1 Incident and verifying that a Zoom channel is automatically created and linked to the Incident.
    • Adding Work Notes to the Incident and verifying that the Work Notes are posted to the Zoom channel.
    • Clicking the "Create Zoom Meeting" UI Action button on the Incident form and verifying that a Zoom meeting is created, the meeting link is added to the Incident's "Meeting link" field, and the meeting link is posted to the Zoom channel.
  • Bidirectional Integration (Meeting Events): Starts setting up bidirectional integration for Zoom meeting events (Meeting Started, Meeting Ended, Participant Joined, Participant Left) to be processed in ServiceNow. This setup is continued in the next video.

Video 8: Bidirectional Zoom Integration (Meeting Events)

This video completes the bidirectional Zoom integration setup, focusing on handling Zoom meeting events (Meeting Started, Meeting Ended, Participant Joined, Participant Left) and updating ServiceNow Incident records accordingly.

Key points covered:

  • Zoom Webhook Validation Setup: Configures Zoom Webhook Validation in ServiceNow to securely receive events from Zoom.
    • Navigating to Zoom Webhook Validation: Accessing the "Zoom Webhook Validation" module in ServiceNow.
    • Creating Webhook Validation Record: Creating a new "Zoom Webhook Validation" record.
    • Secret Token and Verification Token: Copying the "Secret token" and "Verification token" from the Zoom App's "Access" settings in the Zoom Marketplace and pasting them into the ServiceNow Webhook Validation record.
    • Saving Webhook Validation Record.
  • Enabling Zoom Events in Zoom Marketplace: Enables specific Zoom events in the Zoom App's "Event Subscriptions" settings in the Zoom Marketplace to be sent to ServiceNow via Webhooks.
    • Enabling Events: Selecting and enabling "Meeting Started," "Meeting Ended," "Participant/Host joined meeting," and "Participant/Host left meeting" events under the "Meetings" category in the Zoom App's Event Subscriptions.
    • Webhook Endpoint URL: Setting the "Endpoint URL" in the Zoom App's Event Subscriptions to the ServiceNow Inbound REST endpoint URL, which is pre-populated in the "Zoom Webhook Registries" module in ServiceNow.
  • ServiceNow Zoom Webhook Registries: Explains the "Zoom Webhook Registries" module, which manages the registration of ServiceNow as a Webhook receiver for Zoom events.
    • Pre-configured Webhook Registries: Notes that the Zoom Spoke automatically creates pre-configured Webhook Registry records for "Meeting Created," "Meeting Ended," and "Meeting Registration Created" events.
    • Creating Webhook Registry Record for "Meeting Started" Event: Creates a new "Zoom Webhook Registry" record for the "Meeting Started" event.
      • Event Name: "Meeting Started Event" (Renames the default "Meeting Created Event" record).
      • Trigger Type: "Started" (Changes the trigger type from "Created" to "Started").
      • Verification Token: Ensures the "Verification token" field is populated with the Verification Token from the Zoom App.
    • Creating Webhook Registry Record for "Meeting Ended" Event: Creates a new "Zoom Webhook Registry" record for the "Meeting Ended" event.
      • Event Name: "Meeting Ended Event."
      • Trigger Type: "Ended."
      • Verification Token: Ensures the "Verification token" field is populated.
  • Process Meeting Event Subflow (Customized): Copies and customizes the out-of-box "Process Meeting Event" Subflow to handle Meeting Started and Meeting Ended events and update ServiceNow Incident Work Notes.
    • Copying Subflow: Copies the out-of-box "Process Meeting Event" Subflow and places the copy in the "Zoom Spoke" application scope.
    • Lookup Record Action (Incident Lookup by Meeting ID): Adds a "Lookup Record" Action to the customized Subflow to find the ServiceNow Incident record associated with the Zoom meeting event.
      • Table: "Incident" table.
      • Filter: "Zoom Meeting ID is [Subflow Input - Issue - ID]." This filters Incidents based on the "Zoom Meeting ID" field matching the Meeting ID received in the Webhook event payload.
    • IF Flow Logic (Event Type - Meeting Started): Adds an "IF" condition to check if the incoming Webhook event is a "Meeting Started" event.
      • Condition: "Flow Input - Event Name is Meeting Started."
      • THEN Branch (Update Record - Work Notes - Meeting Started): If the event is "Meeting Started," adds an "Update Record" Action to update the Incident record's "Work notes" field with a message indicating that the meeting has started.
    • ELSE IF Flow Logic (Event Type - Meeting Ended): Adds an "ELSE IF" condition to check if the event is a "Meeting Ended" event.
      • Condition: "Flow Input - Event Name is Meeting Ended."
      • THEN Branch (Update Record - Work Notes - Meeting Ended): If the event is "Meeting Ended," adds an "Update Record" Action to update the Incident record's "Work notes" field with a message indicating that the meeting has ended.
  • Updating Webhook Registries to Use Custom Subflow: Updates the "Meeting Started Event" and "Meeting Ended Event" Webhook Registry records to call the customized copy of the "Process Meeting Event" Subflow.
  • Testing Bidirectional Integration (Meeting Events): Demonstrates testing the bidirectional integration by:
    • Starting a Zoom meeting from the Zoom web interface.
    • Ending the Zoom meeting.
    • Verifying that "Meeting Started" and "Meeting Ended" work notes are automatically added to the associated ServiceNow Incident record, triggered by the Zoom Webhooks and processed by the customized Subflow.
  • Run As System User for Subflow: Changes the Run As context of the customized Subflow to "System User" to ensure proper execution and permissions when handling Webhook events triggered by external systems (Zoom).

Video 9: Multipart Attachment

This video focuses on handling multipart attachments in Integration Hub, specifically for sending attachments from ServiceNow to Jira and receiving attachments from Jira to ServiceNow. Rohit demonstrates building custom Actions for multipart attachment handling.

Key points covered:

  • Multipart Attachment Definition: Explains that Multipart Attachments are a specific format for sending data, particularly attachments, from ServiceNow to external systems that require or only support multipart data (e.g., Jira API for adding attachments).
  • Integration Hub Requirement for Multipart: Notes that Multipart data handling is primarily supported within Integration Hub.
  • Use Case - Jira Attachment Synchronization (Bidirectional): Outlines a bidirectional attachment synchronization use case between ServiceNow Stories and Jira Issues:
    1. Send Attachment (ServiceNow to Jira): When an attachment is added to a ServiceNow Story, send the attachment to the corresponding Jira Issue.
    2. Receive Attachment (Jira to ServiceNow): When an attachment is added to a Jira Issue, receive the attachment and attach it to the corresponding ServiceNow Story.
  • Jira API Documentation - Add Attachment Endpoint: Highlights the Jira API endpoint for adding attachments to issues: /rest/api/3/issue/{issueKey}/attachments (using POST method with multipart/form-data content type).
  • Creating a Custom Action - "Jira Send Attachment": Creates a Custom Action named "Jira Send Attachment" to handle sending attachments from ServiceNow to Jira using multipart data.
    • Input Parameters: Defines Input Parameters for the Custom Action:
      • Issue Key: String (Mandatory) - Jira Issue Key.
      • Attachment Sys ID: String (Mandatory) - ServiceNow Attachment Sys ID.
    • REST Step Action (Multipart Data): Adds a "REST Step" Action to the Custom Action to handle the API call to Jira for adding attachments.
      • Connection Alias: "Jira Custom."
      • Method: "POST."
      • Resource Path: /rest/api/3/issue/{issueKey}/attachments (with {issueKey} placeholder for dynamic Issue Key).
      • Header - "X-Atlassian-Token: no-check": Adds a Header Parameter X-Atlassian-Token: no-check as required by Jira API for attachment uploads.
      • Request Content Type: "Multipart."
      • Multipart Data: Adds a Multipart Data section to specify the attachment content:
        • Name: "file."
        • Type: "File."
        • Value (Attachment): Mapped to "Input - Attachment Sys ID."
        • Set Content Type from Attachment: Checked.
        • Set File name from Attachment: Checked.
    • JSON Parser Action (Response Processing): Adds a JSON Parser Action to process the JSON response from the Jira API after uploading the attachment.
      • Source Data: "REST Step - Response body."
      • Sample Response Body: Pastes a sample JSON response body for Jira attachment upload API.
      • Generate Target Structure: Clicks "Generate target structure" to create Output Variables based on the JSON response.
    • Output Parameter - "Attachment ID": Defines an Output Parameter "Attachment ID" (String type) to return the Jira Attachment ID from the JSON Parser output.
    • Mapping JSON Parser Output to Action Output: Maps the "Attachment ID" Output Variable of the Custom Action to the "id" Output Variable generated by the JSON Parser.
  • Testing "Jira Send Attachment" Action: Demonstrates testing the Custom Action by:
    • Providing a Jira Issue Key and a ServiceNow Attachment Sys ID as test inputs.
    • Verifying that the Action executes successfully and returns a Jira Attachment ID in the output.
    • Checking the Jira Issue to confirm that the attachment has been uploaded.
  • Publishing "Jira Send Attachment" Action: Publishes the Custom Action.

Video 10: Inbound REST Message

This video focuses on Inbound REST Messages in Flow Designer, enabling ServiceNow to receive and process data from external systems via REST APIs. Rohit demonstrates creating an Inbound REST Message Flow and handling incoming data.

Key points covered:

  • Inbound REST Message Definition: Explains Inbound REST Messages as a Flow Designer feature that allows ServiceNow to act as a REST API endpoint, receiving and processing requests from external systems.
  • Benefits of Inbound REST Messages (vs. Scripted REST APIs): Highlights the advantages of Inbound REST Messages over traditional Scripted REST APIs:
    • Low-Code Development: Reduced or eliminated scripting required for handling inbound requests.
    • Reusability: Leveraging Flow Designer's out-of-box Actions for data processing, record creation, updates, etc.
  • Creating an Inbound REST Message Flow - "Inbound Request - Issue Update": Creates a new Flow Designer Flow named "Inbound Request - Issue Update" to demonstrate handling inbound REST requests from Jira.
    • Trigger (REST API Asynchronous): Sets the Flow trigger to "REST API Asynchronous," the specific trigger type for handling Inbound REST Messages in Flow Designer.
    • REST API Trigger Configuration:
      • Method: "POST."
      • Relative Path (Optional): Leaves the Relative Path blank (for this example, the endpoint will be /api/sn_global_integration_hub/inbound_rest).
      • Authentication: Unchecks "Requires authentication" for simplicity (in real-world scenarios, authentication is crucial).
      • Media Type: Defaults to "application/json" for JSON request bodies.
    • Input Parameters (Request Body): Defines Input Parameters for the Flow to receive data from the incoming REST request.
      • Timestamp: String type.
      • Issue: Object type (JSON Object) - Represents the "issue" JSON object in the Jira Webhook payload.
        • ID: String type (nested within "Issue").
        • Key: String type (nested within "Issue").
      • Fields: Object type (JSON Object) - Represents the "fields" JSON object within the Jira Webhook payload, containing issue fields including "attachments."
        • Attachments: Array type (JSON Array) - Represents the "attachments" array within the "fields" object.
          • Child Object (Attachment - Index 0): Defines a child object structure to represent individual attachments within the "attachments" array:
            • Self: String type.
            • ID: String type.
            • File Name: String type.
  • Log Action (Request Body Logging): Adds a "Log" Action to the Flow to print the incoming Request Body data for debugging and inspection.
    • Message: "Hi" + "Trigger - REST API Request Body."
  • Testing Inbound REST Message Flow (Postman Simulation): Demonstrates testing the Inbound REST Message Flow using Postman to simulate a REST request from a third-party system (Jira).
    • Postman Setup:
      • Method: "POST."
      • Endpoint URL: ServiceNow Inbound REST Endpoint URL (copied from Flow Designer Trigger).
      • Request Body (Raw JSON): Pastes a sample JSON payload (Jira Webhook event payload) into the Request Body in Postman.
      • Sending Request: Clicking "Send" in Postman to send the simulated REST request to ServiceNow.
    • Verification in ServiceNow:
      • Flow Execution: Checking Flow Designer "Executions" to confirm that the "Inbound Request - Issue Update" Flow was triggered by the Postman request.
      • Logs: Checking the Flow Execution Logs to verify that the "Log" Action printed the Request Body data, confirming that ServiceNow successfully received and processed the incoming REST request.
  • Scripted REST API Comparison: Briefly compares Inbound REST Messages to traditional Scripted REST APIs, reiterating the low-code benefits of Inbound REST Messages in Flow Designer.

Video 11: Save as Attachment Action

This video demonstrates the "Save as Attachment" Action in Flow Designer, specifically for saving attachments retrieved from external systems (like Jira) into ServiceNow. Rohit shows how to use this Action to attach Jira issue attachments to ServiceNow Story records.

Key points covered:

  • Save as Attachment Action: Introduces the "Save as Attachment" Action in Flow Designer, used to save files or data as attachments to ServiceNow records.
  • Use Case - Jira Attachment Inbound Handling: Extends the Jira bidirectional integration scenario to handle incoming Jira attachments and save them to ServiceNow Stories.
  • Modifying "Inbound Request - Issue Update" Flow: Modifies the "Inbound Request - Issue Update" Flow from Video 10 to incorporate attachment saving logic.
  • For Each Loop (Attachment Array Iteration): Adds a "For Each Record" Flow Logic Action to loop through the "attachments" array received in the Jira Webhook payload.
    • Records: "Trigger - REST API Request Body - Issue - Fields - Attachments."
  • Lookup Record Action (External Tracker Check): Adds a "Lookup Record" Action inside the "For Each Loop" to check if an attachment with the same external Attachment ID already exists in the "External Tracker" table. This is to prevent duplicate attachments from being created in ServiceNow.
    • Table: "u_external_tracker" table (Custom table created by Rohit).
    • Filter Conditions:
      • "u_external_attachment_id" is "For Each - Attachment - ID."
      • "u_external_id" is "Trigger - REST API Request Body - Issue - ID."
    • Do not fail on error: Checked (to prevent Flow from failing if no matching record is found in the External Tracker table).
  • IF Flow Logic (Attachment Not Found - Error Status Check): Adds an "IF" condition to check the status of the "Lookup Record" Action.
    • Condition: "Lookup Record - Status is Error." This condition is true if the "Lookup Record" Action did not find a matching record in the External Tracker table (meaning the attachment is new).
    • THEN Branch (Attachment Saving Logic): Contains the Actions to execute if the attachment is new (not found in External Tracker).
      • Lookup Record Action (Story Lookup): Adds a "Lookup Record" Action to find the ServiceNow Story record based on the Jira Issue ID.
        • Table: "rm_story" table.
        • Filter: "u_jira_id" is "Trigger - REST API Request Body - Issue - ID."
      • Save as Attachment Action (Save to Story): Adds the "Save as Attachment" Action to save the Jira attachment to the ServiceNow Story record.
        • Attachment File Name: "For Each - Attachment - File Name."
        • Attachment File Record: "Lookup Record - Story Record."
      • Create Record Action (External Tracker Record Creation): Adds a "Create Record" Action to create a new record in the "External Tracker" table to track the saved attachment.
        • Table: "u_external_tracker" table.
        • Field Mappings: Maps data to the External Tracker table fields:
          • "u_external_attachment_id": "For Each - Attachment - ID."
          • "u_external_id": "Trigger - REST API Request Body - Issue - ID."
          • "u_internal_id": "Lookup Record - Story Record - Sys ID."
          • "u_api_name": "For Each - Attachment - File Name."
          • "u_endpoint": (Left blank in the example, but could be used to store the Jira API endpoint URL).
  • Output Parameter - "ServiceNow Attachment Sys ID": Defines an Output Parameter "ServiceNow Attachment Sys ID" (String type) in the "Save as Attachment" Action to return the sys_id of the newly created ServiceNow attachment record.
  • Testing Attachment Saving (Jira to ServiceNow): Demonstrates testing the attachment saving logic by:
    • Adding a new attachment to a Jira Issue.
    • Verifying that the Inbound REST Message Flow is triggered.
    • Checking the ServiceNow Story record to confirm that the Jira attachment has been successfully attached.
    • Checking the "External Tracker" table to verify that a new record has been created to track the saved attachment.
  • Preventing Duplicate Attachments: Highlights how the "Lookup Record" Action and "IF" condition prevent duplicate attachments from being saved in ServiceNow by checking the "External Tracker" table before saving.

Video 12: Data Stream for Pagination

This video focuses on Data Streams in Integration Hub, explaining their purpose for handling pagination and demonstrating their use for retrieving paginated data from an Okta API.

Key points covered:

  • Data Stream Definition: Data Streams are defined as a Flow Designer feature specifically designed for handling pagination when retrieving large datasets from APIs.
  • Pagination Explained: Explains the concept of pagination as a technique to retrieve large datasets in smaller, manageable chunks (pages) to avoid timeouts and improve performance.
    • SQL Example (LIMIT and OFFSET): Illustrates pagination using SQL LIMIT and OFFSET clauses.
    • API Example (LIMIT and PAGE): Shows an API example using limit and page query parameters for pagination.
    • Benefits of Pagination: Improved performance, reduced timeouts, efficient handling of large datasets.
  • Offset-Based Pagination vs. Cursor-Based Pagination: Briefly mentions two common pagination methods:
    • Offset-Based: Uses limit and offset (or page number) to specify the data range.
    • Cursor-Based: Uses a cursor or after parameter (like in the Okta API example) to retrieve the next page of data.
  • Okta API Pagination Example (Users API): Demonstrates Okta API pagination using the Users API (/api/v1/users) and the after parameter for cursor-based pagination.
    • Postman Setup: Shows Postman setup for testing Okta API pagination:
      • Method: "GET."
      • Endpoint URL: Okta Users API endpoint (https://[your-okta-domain]/api/v1/users).
      • Authorization: OAuth 2.0 authorization (using an Access Token obtained in previous videos).
      • Query Parameter - "limit=2": Adds a limit=2 query parameter to retrieve only two users per page.
      • Header - "Link": Explains that the Okta API returns pagination links in the "Link" header of the response, including an "after" cursor value for retrieving the next page.
      • Extracting "after" Cursor: Demonstrates how to extract the "after" cursor value from the "Link" header using string manipulation in Postman.
      • Using "after" Cursor for Next Page: Shows how to use the extracted "after" cursor value as a query parameter (after=[cursor_value]) in subsequent requests to retrieve the next page of users.
  • Creating Data Stream in Flow Designer - "Okta Paged Users (Custom)": Creates a Data Stream in Flow Designer named "Okta Paged Users (Custom)" to retrieve paginated user data from the Okta API.
    • Data Stream Properties: Sets the Data Stream Name and Application Scope.
    • Rest Step Action (Initial Request): Adds a "REST Step" Action to handle the initial API request to Okta Users API.
      • Connection Alias: "Define Connection Inline" -> "Credential" -> "Okta Custom."
      • Base URL: Okta Base URL.
      • Resource Path: /api/v1/users.
      • Query Parameter - "limit=2": Adds a query parameter limit=2 to limit the number of users per page.
    • Enable Pagination: Enables Pagination for the Data Stream in the "Request" tab.
    • Pagination Setup: Configures Pagination settings:
      • Variable - "after": Creates a Data Stream Variable named "after" (String type) to store the "after" cursor value for pagination.
      • Next Page Indicator Script: Adds a Script to dynamically determine if there are more pages to retrieve and extract the "after" cursor value from the "Link" header of the API response.
        • Script Code: JavaScript code to parse the "Link" header, extract the "after" cursor value from the "next" link, and set the "get_next" variable to true if a "next" link with "after" cursor is found, or false otherwise.
        • Output Variables:
          • get_next: Boolean type - Indicates whether there are more pages to retrieve.
          • after_index: String type - Stores the extracted "after" cursor value.
      • Variable Assignment - "after": Adds a "Variable Assignment" action to update the "after" Data Stream Variable with the extracted "after_index" value from the Pagination Script.
      • Request - Query Parameter - "after": Adds a Query Parameter "after" to the "REST Step" Action, mapping its value to the "after" Data Stream Variable. This dynamically passes the "after" cursor value in subsequent requests for pagination.
  • Split Step Action (JSON Parsing): Adds a "Split Step" Action to parse the JSON response body from the Okta API.
    • Source Item: "$." (Dollar sign to indicate the root of the JSON response array).
    • Target Object: "Object" (Defines the structure of each item in the JSON response array, including "first_name," "last_name," "status," and "id" Output Variables).
    • Mapping Script: Adds a Script to map data from the split JSON response to the "Object" Output Variables.
  • Testing Data Stream: Demonstrates testing the Data Stream by clicking "Test" and verifying:
    • Pagination Execution: Checking the Data Stream Execution logs to see multiple page requests being made (due to pagination).
    • Data Retrieval: Verifying that all 7 Okta users are retrieved across multiple pages (even though each page is limited to 2 users), confirming that pagination is working correctly.
    • Output Data: Examining the Data Stream output to see the retrieved user data (First Name, Last Name, Status, ID).
  • Pagination Logic Explanation: Provides a detailed explanation of the Pagination Logic within the Data Stream, walking through the script, variable assignments, and how the "after" cursor is extracted and used for subsequent page requests.

Video 13: Okta Service Account Integration

This video builds upon the previous Okta integration examples, focusing on setting up a dedicated Service Account for Okta API access and using Credential Aliases for secure credential management.

Key points covered:

  • Okta Service Account Integration: Focuses on best practices for Okta API integration, emphasizing the use of a dedicated Service Account for enhanced security and manageability.
  • Creating a Dedicated Okta Service Account: Recommends creating a dedicated Service Account user in Okta specifically for ServiceNow integration, rather than using personal user credentials. This improves security and auditability.
  • Creating an API Application in Okta for Service Account: Shows the steps to create an API Application in Okta specifically for the Service Account to grant it API access. This involves creating a new Application in Okta with the "Service Account" type and granting it necessary API permissions.
  • Benefits of Service Account: Highlights the benefits of using a Service Account:
    • Enhanced Security: Limits API access to a dedicated account, reducing security risks associated with using personal user credentials.
    • Improved Auditability: Makes it easier to track API activity and identify requests originating from the ServiceNow integration.
    • Centralized Credential Management: Credentials for the Service Account are managed centrally within Okta.
  • Credential Alias - "Okta Custom 2": Creates a new Credential Alias named "Okta Custom 2" in ServiceNow to store the Service Account's credentials.
    • Credential Type: "OAuth 2.0 Credentials."
    • Credential Profile: "Okta Custom" (Application Registry Profile created in previous videos).
  • Application Registry - "Okta Custom 2": Creates a new Application Registry Profile named "Okta Custom 2" to associate it with the "Okta Custom 2" Credential Alias.
    • Profile Type: "OAuth 2.0."
    • Client ID and Client Secret (Service Account App): Uses the Client ID and Client Secret from the newly created Service Account API Application in Okta.
    • Authorization URL and Token URL: Reuses the same Authorization URL and Token URL from the previous "Okta Custom" Application Registry Profile.
    • Scope: Reuses the same scope (okta.users.read) from the previous profile.
  • Updating Custom Action - "Okta Custom Get User": Updates the "Okta Custom Get User" Custom Action (from previous videos) to use the newly created "Okta Custom 2" Credential Alias.
    • REST Step - Connection Alias: Changes the Connection Alias in the "REST Step" Action to "Okta Custom 2."
  • Testing with Service Account Credentials: Demonstrates testing the "Okta Custom Get User" Custom Action again, now using the Service Account credentials configured in the "Okta Custom 2" Credential Alias. Verifies that the Action still successfully retrieves user data from Okta API, now authenticated using the dedicated Service Account.

Video 14: Data Stream - Pagination (Detailed Implementation)

This video provides a detailed walkthrough of implementing pagination in a Data Stream for the Okta Users API. Rohit explains the pagination logic, script, and configuration step-by-step.

Key points covered:

  • Data Stream Pagination Implementation (Detailed Walkthrough): Provides a detailed, step-by-step explanation of how to implement pagination in a Data Stream for the Okta Users API, building upon the Data Stream created in Video 12.
  • Recap of Pagination Concept: Briefly recaps the concept of pagination and cursor-based pagination used by the Okta API (using the "after" parameter and "Link" header).
  • Data Stream - "Okta Paged Users (Custom)" (Modified): Modifies the "Okta Paged Users (Custom)" Data Stream from Video 12 to implement full pagination logic.
  • Request Step - Query Parameter - "limit=2": Confirms the presence of the limit=2 Query Parameter in the "REST Step" Action to limit the number of users retrieved per page.
  • Pagination Setup (Detailed Explanation): Provides a detailed explanation of the Pagination Setup section in the Data Stream:
    • Variable - "after": Explains the purpose of the "after" Data Stream Variable (String type) to store the cursor value for pagination.
    • Next Page Indicator Script (Detailed Breakdown): Provides a line-by-line explanation of the JavaScript code used in the "Next Page Indicator Script" to:
      • Retrieve Headers: var headers = page_response.response.headers; - Retrieves all headers from the API response.
      • Get "Link" Header: var link_header = headers['link']; - Extracts the "Link" header value (containing pagination links).
      • Split "Link" Header: var link_split = link_header.split(','); - Splits the "Link" header string into an array of links using the comma as a delimiter.
      • Loop through Links: for (var i = 0; i < headers.length; i++) - Loops through each link in the link_split array.
      • Check for "after" Parameter: if (header.indexOf('after=') > -1) - Checks if the current link contains "after=" (indicating a "next" page link).
      • Extract "after" Cursor Value:
        • var after_index = header.split('after=')[1]; - Splits the link by "after=" and takes the right-hand side (index 1) to get the cursor value and remaining parameters.
        • after_index = after_index.split('&')[0]; - Further splits the cursor value string by "&" (to remove any additional query parameters after "after=") and takes the left-hand side (index 0) to isolate the cursor value.
      • Set "get_next" to True: get_next = true; - Sets the get_next variable to true to indicate that there are more pages to retrieve.
      • Return Cursor Value: return after_index; - Returns the extracted "after" cursor value.
      • Return Empty String if No "after" Parameter: return ''; - Returns an empty string if no "after=" parameter is found in the "Link" header.
    • Variable Assignment - "after": Explains how the "Variable Assignment" Action updates the "after" Data Stream Variable with the cursor value returned by the Pagination Script.
    • Request - Query Parameter - "after": Explains how the "after" Data Stream Variable is used as a Query Parameter (after=[variable_value]) in the "REST Step" Action, dynamically passing the cursor value in subsequent requests for pagination.
  • Split Step Action (JSON Parsing): Reiterates the configuration of the "Split Step" Action for parsing the JSON response from the Okta API, mapping data to Output Variables for "first_name," "last_name," "status," and "id."
  • Testing Data Stream with Pagination: Demonstrates testing the Data Stream with Pagination enabled and verifying:
    • Pagination Execution: Observing multiple Data Stream executions in the Logs, indicating pagination is working.
    • Page Count and Record Count: Verifying that the Data Stream Execution details show the correct Page Count and Record Count, confirming that all data is retrieved across multiple pages.
    • Output Data: Examining the Data Stream Output to see the retrieved user data, confirming that all 7 Okta users are retrieved through pagination.

These detailed notes provide a comprehensive understanding of Rohit's "Integration Hub" series, covering Integration Hub activation, custom and out-of-box Actions, Connection and Credential Aliases, Inbound REST Messages, Multipart Attachments, Data Streams for Pagination, and Okta Service Account integration. It's an excellent resource for learning Integration Hub and building various types of integrations in ServiceNow.

No Comments
Back to top