Data Stream actions and pagination

  • Release version: Yokohama
  • Updated January 30, 2025
  • 10 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Data Stream actions and pagination

    Data Stream actions in ServiceNow's Workflow Studio enable customers to send REST, SOAP, or JDBC requests to APIs that return either large streams of response data (over 10 MB) or paginated results. These actions parse the streamed data into complex object outputs, allowing flow designers to use the extracted data pills in subsequent flow steps. Typical use cases include importing large datasets, such as employee records from third-party HR systems, directly into ServiceNow tables likesysuser.

    Show full answer Show less

    Note that Data Stream actions require an Integration Hub subscription.

    Key Features

    • Handling Large Data Streams: Supports parsing and formatting API responses larger than 10 MB.
    • Automated Pagination: Automatically sends multiple requests to handle paginated API results, continuing until all data pages are retrieved.
    • Reusable Actions: Allows creation of reusable Data Stream actions that can be incorporated into multiple flows using the same data source.
    • For Each Flow Logic Integration: When added to a flow, Data Stream actions are automatically wrapped within a For each flow logic block, enabling processing of each individual object in the data stream, such as creating individual records.
    • Flexible Execution: Can be run within flows or triggered via script using the executeDataStreamAction() method.
    • Configurable Action Outline: Data Stream actions follow a strict structure with defined steps for preprocessing, request handling, and parsing. Steps cannot be manually added outside this structure to ensure consistency.
    • Error Handling: Customizable error evaluation at each step allows defining error conditions, handling API error states, and specifying status codes and messages.
    • Action Preprocessing: Supports retrieving connection info and running preprocessing scripts to validate inputs or set defaults before sending API requests.
    • Request Configuration: Includes settings for pagination (e.g., Limit/Offset templates), scripts before each page request, and mandatory REST, SOAP, or JDBC request steps.
    • Parsing: Uses splitter and script parser steps to convert streamed XML/JSON data into complex objects. JDBC streams generate complex objects per record without needing pagination or parsing steps.
    • JDBC Specifics: JDBC Data Stream actions retrieve all data in a single request without pagination, require MID Server execution, and support transform scripts to map data to complex objects.
    • Execution Details and Reporting: Customers can view detailed runtime information per item and per page, with configurable system properties controlling the amount of execution history retained.
    • MID Server Support and Properties: JDBC operations require MID Server execution and support adjustable timeouts and record size limits to optimize performance and avoid timeouts.

    Practical Use and Design Considerations

    • Create reusable Data Stream actions tailored to your external APIs to efficiently process large or paginated data sources within flows.
    • Leverage the automatic For each flow logic integration to process individual records or objects in the data stream without complex custom coding.
    • Use the preprocessing scripts to validate and prepare inputs before API calls.
    • Configure pagination carefully to comply with your API’s requirements, and be mindful that each paginated request counts as a transaction for licensing purposes.
    • For JDBC data streams, run asynchronously via MID Server and monitor MID Server timeout properties to prevent execution delays.
    • Test Data Stream actions prior to adding them to flows to ensure correct behavior and data mapping.
    • View execution summaries and detailed page/item-level logs to monitor action performance and troubleshoot issues.

    What ServiceNow Customers Can Expect

    By using Data Stream actions, customers can efficiently import and process large datasets or paginated API results within their ServiceNow workflows, reducing the need for custom scripts or complex configurations. This capability extends Integration Hub functionality, allowing flow designers to seamlessly integrate external data sources, handle large volumes of data, and automate record creation or updates in ServiceNow tables. The structured design of these actions ensures error management, reusability, and clear visibility into execution details, supporting robust and maintainable integrations.

    Send REST, SOAP, or JDBC requests from Workflow Studio to APIs that return a stream of response data larger than 10 MB, or that return paginated results. Parse stream data into a series of complex object outputs and use the data pills in other actions in a flow.

    For example, create a Data Stream action to import a large quantity of employee data from a third-party HR site. The Data Stream action sends a REST request to the third-party site and processes the response to populate records in the User [sys_user] table.
    Note:
    Data Stream actions require an Integration Hub subscription. For more information, see Legal schedules - Integration Hub overview.

    Benefits

    Data Stream actions offer these benefits.

    • Parse and format a stream of response data larger than 10 MB.
    • Automatically send multiple requests to APIs that paginate results, if applicable.
    • Can be used in Integration Hub - Import and to create a data source.
    • Enable flow designers to process large requests without complex coding or configuration.
    • Enable flow designers to process each object within a data stream using For each flow logic. For example, you might create a Data Stream action that imports document data from a third-party site. When you add the action to a flow, Workflow Studio automatically adds the action to a For each flow logic block, enabling flow designers to easily create a record in ServiceNow for each object in the data stream. See Use a Data Stream action in a flow.
    • Enable flow designers to reuse Data Stream actions in multiple flows, using the same source of data in multiple ways.

    Running a Data Stream action

    There are two ways to run a Data Stream action.

    From a flow
    You can process each object within a data stream using For each flow logic. For example, you might create a Data Stream action that imports document data from a third-party site. When you add the action to a flow, Workflow Studio automatically adds the action to a For each flow logic block, enabling flow designers to easily create a record in ServiceNow for each object in the data stream. See Use a Data Stream action in a flow.
    From a script
    You can start a Data Stream using the executeDataStreamAction() method in the FlowAPI class. For more information, see FlowAPI.

    Action outline

    Data Stream actions follow a set structure. Follow prompts to add and remove steps from the action outline. You cannot manually add steps to a Data Stream action.

    Figure 1. REST and SOAP Data Stream actions
    REST and SOAP Data Stream action.
    Figure 2. JDBC Data Stream action
    JDBC Data Stream action
    Note:
    Clearing an option in a configuration page removes the step from the Data Stream outline and deletes all data associated with the step.

    Action error evaluation

    Use error evaluation to catch step errors and specify the error behavior of each step you add to a data stream action. You can also create your own error conditions by specifying when an action returns an error state as well as the status codes and messages they return.

    Action Preprocessing

    Use the Action Preprocessing category to retrieve connection and credential details or to run a preprocessing script.

    Select Retrieve connection info to retrieve connection and credential details to use in your action. Selecting this option adds the Get Connection Info step as the first step in the action preprocessing. For more information, see Get Connection Info step.

    Select Enable preprocessing script to run a preprocessing script before the action sends the initial API request. For example, validate action inputs or set default values. Selecting this option adds a script step to the Data Stream action. For more information, see Script step.

    Preprocessing executes once per action, before the first API request.

    This is an optional Data Stream action component that runs on either the instance or a MID Server.

    Request

    Use the Request category to configure how the action sends API requests. The Request section executes once per page of results. Request components provide these configuration options.

    Pagination Setup step

    Request results in batches. Once one page of data is processed, the Data Stream action runs the request section again to return the next set of results. Use the pagination setup step to set up pagination options required by the API. Configure the Pagination Setup step manually, or select a pre-built template to apply common configurations. For example, apply the Limit / Offset template to specify the number of items you want returned per page (limit), and the starting number for the first item (offset). After applying a template, update the values to ensure that the configuration complies with the API's requirements.

    Note:
    For licensing purposes, each request counts as one transaction, including each request for the next page of results.

    The value of the reserved, read-only getNextPage variable determines whether to request another page of results. As long as the getNextPage variable is true and the previous page contains data, the action continues to send requests for the next page.

    Note:
    You must explicitly set the value to true in the script or it will default to false.
    This is an optional Request component that only runs on the instance.
    Note:
    Pagination isn't applicable to the JDBC step.
    Script step

    Run a script before every request for the next page of results. Use this script for data validation and transformation when calling a paginated API. For example, generate a JSON payload for the next page request. Selecting this option adds a script step to the Data Stream action. For more information, see Script step.

    This is an optional Request component that runs on either the instance or a MID Server.

    REST or SOAP step

    Send a REST or SOAP request to a third-party API. Select a data format to add an associated step to the Data Stream action. For more information, see REST step and SOAP step.

    This is a mandatory Request component that runs on either the instance or a MID Server.

    JDBC step

    Send a JDBC request to a third-party API. Use transform script to format data and add an associated step to the Data Stream action. For more information, see JDBC step and Test JDBC step. All data is retrieved and pagination is not needed.

    This is a mandatory Request component that runs on a MID Server.

    Parsing in REST and SOAP steps

    Use the Parsing category to configure how the action separates data stream elements into complex data objects. Use the Splitter step to identify and separate items from an XML or JSON stream, and use the Script Parser step to transform each item into a complex object. The Parsing section executes once per item in the stream. You can access outputs from previous steps in your data stream action using the fd_data object, excluding:
    • REST or SOAP step Response Body, Stream, or Error Message outputs
    • Splitter step outputs

    Splitting and parsing a stream of user records.

    For more information about complex data, see Complex data. Parsing components provide these configuration options.

    Splitter step

    Identify the parent node in the response stream to map to a complex object. For example, identify a user element in an XML payload to create a complex object for each user in the response stream.

    Select a splitter type to identify and separate repeated items in an XML or JSON data stream.

    • JSON: Identifies objects from a stream of JSON data. Use a JSONPath expression to identify a JSON array containing repeated data.
    • XML: Identify objects from a stream of XML data. Use an XPath expression to identify an XML element containing repeated data.

    This is a mandatory Parsing component that only runs on the instance.

    Script Parser step

    Use JavaScript and ServiceNow APIs to map items in the response stream to a complex object output represented by the targetObject global object. For example, map incident record elements identified in the splitter step to a complex object containing incident fields. If the data stream includes siblings to the item identified in the splitter step that you do not want mapped to a complex object, include conditions to exclude those items. You can skip items in the stream by adding outputs.state = 'SKIP' wherever needed to the script section of the Script Parser step.

    This is a mandatory Parsing component that only runs on the instance.

    Figure 3. REST and SOAP Data Stream action overview
    Overview of the REST and SOAP Data Stream action.

    Transform script in JDBC step

    JDBC data stream action doesn't require pagination. Also, splitter and parser steps aren't required.

    The JDBC step generates a complex object for each of the retrieved record. Hence, action preprocessing and transform script in the JDBC data stream action are optional. When using the transform script, action designer must specify the internal name of the table columns in the transform script.
    Figure 4. JDBC Data Stream action overview
    Overview of the JDBC Data Stream action.

    JDBC operations and MID Server timeouts

    For JDBC operations, execute the Data Stream Action asynchronously and poll the Attachments [sys_attachment] table for results.

    The MID Server processes the SQL statement, while the instance/main thread waits for context payloads to be inserted into the attachment table to query the next record.

    You can adjust timeout values for JDBC operations with the following properties.

    com.snc.process_flow.datastream.payload.timeout.seconds
    The amount of time the instance waits for the payload to be available from the JDBC execution in the MID Server. A bounded property with a minimum value of 0 seconds and a maximum value of 7200 seconds. The default time is 600 seconds.
    com.snc.process_flow.datastream.async_child.timeout.seconds
    The amount of time allocated for the execution of a child plan in the MID Server.A bounded property with a minimum value of 0 seconds and a maximum value of 7200 seconds. The default time is 60 seconds.

    Data Stream outputs in SOAP and REST steps

    When designing a Data Stream action, you must create a single output of type Object or Dynamic Object. The Script Parser step maps items in the stream to this object using the targetObject global object.

    At runtime, the system splits and parses the stream of response data according to the Data Stream configuration. Each item in the stream maps to the complex object structure defined by the Script Parser step and the object output, resulting in a large series of complex objects. For more information about complex data, see Complex data.

    Data Stream outputs in JDBC step

    The output of JDBC steps is a complex object stream. Entire data is retrieved in one request only.
    Note:
    • You can only retrieve data and can't update or delete records using the JDBC data stream action.
    • The fields, Maximum Row and Maximum Payload Size (KB) that are available in JDBC step aren't available in the JDBC data stream action.

    Execution details in REST and SOAP steps

    View the configuration and runtime results for each item processed by a Data Stream action. Select a record number to see its configuration and runtime details. By default, the execution details include requests for the last 1000 items. To change the number of items in the execution details, update the com.snc.process_flow.reporting.datastream.item.lastn system property.

    Execution details for a Data Stream action.

    Data stream summary

    View an overview of the execution that includes this information.

    • Page count: Number of pages returned by a paginated API.
    • Total item count: Number of items in the response stream mapped to complex object outputs.
    • Error count: Number of errors encountered.
    Page details

    View runtime data for each step within the Data Stream action. Select a page to view runtime details for each request to a paginated API. By default, the execution details include requests for the last five pages. To change the number of requests in the execution details, update the com.snc.process_flow.page.reporting.lastn system property. Set the value to 0 to remove pages from the execution details and -1 to include all pages.

    Note:
    Including all pages can affect performance and is not recommended.

    Runtime details

    Execution details in JDBC step

    Construction of the output complex object schema isn't needed for the JDBC data stream action. You can test the query and see the query result. See Test JDBC step for more information. Configure the MID Server properties mid.jdbc.datastream.max.record.size and mid.jdbc.datastream.fail.when.attachement.limit.exceeded to retrieve data as per your requirement. See MID Server properties for more information.