MID Server support for Data Stream actions

Release version: Australia

Updated March 12, 2026

2 minutes to read

Summarize

Summarized using AI

Summary of MID Server support for Data Stream actions

This feature enables ServiceNow customers to retrieve data using a MID Server when executing a Data Stream action. The MID Server collects data and sends each page to the ServiceNow instance as an attachment for processing. This setup facilitates data collection in environments where direct instance access is limited or not possible.

Show full answer Show less

Execution Environment Considerations

While running Data Stream actions within a flow, actions inside the For Each block always execute on the instance. However, the following steps can be run either on the MID Server or the instance:

Action Preprocessing Script
Request Script step
REST or SOAP step

It is important to avoid frequently switching the execution environment between the instance and the MID Server within the same process, as this can degrade performance. For example, running the Request Script on the MID Server but the REST step on the instance causes environment shifts for every data page.

Handling Size and Timeout Limits

If timeouts or size limits occur during data retrieval, the following adjustments can be made:

Increase REST transaction quota rule: Extend the REST Attachment API request timeout (default 60 seconds, max 300 seconds) to prevent timeouts due to slow MID Server-instance connections.
Increase instance timeout: Adjust the datastreamalternativeenvfetchpagetimeoutseconds system property to allow more time (default 600 seconds, max 7200 seconds) for the instance to retrieve a data page from the MID Server.
Increase attachment size: Raise the maximum allowed attachment size by modifying the com.glide.attachment.maxsize system property (default 1024 MB, no maximum) because each data page is sent as an attachment.

JDBC Operations and MID Server Timeouts

For JDBC data retrieval, it is recommended to run the Data Stream Action asynchronously and poll the Attachments [sysattachment] table for results. The MID Server executes the SQL statement, while the instance waits for payloads inserted as attachments to query subsequent records.

Timeouts related to JDBC operations can be adjusted using these system properties:

com.snc.processflow.datastream.payload.timeout.seconds: Time the instance waits for the MID Server payload (default 600 seconds, max 7200 seconds).
com.snc.processflow.datastream.asyncchild.timeout.seconds: Time allocated for executing a child plan on the MID Server (default 60 seconds, max 7200 seconds).

Practical Impact for Customers

By leveraging MID Server support for Data Stream actions, customers can efficiently retrieve large or remote data sets within their ServiceNow environment, with control over execution locations and timeout settings. Proper configuration of timeouts and attachment sizes helps to ensure reliable data transfer and processing without performance degradation.

Get data through a ServiceNow® MID Server when running a Data Stream action.

When selected, the MID Server retrieves the data and sends each page to the instance as an attachment to process.

Important:

When running the Data Stream action within flow, the actions in the For Each block always run on the instance.

These steps can run on either the MID Server or the instance:

Action Preprocessing Script
Request Script step
REST or SOAP step

Note:

Avoid shifting the execution environment between the instance and the MID Server multiple times. For example, you might configure the Request Script step to run on the MID Server, but the REST step to run on the instance. In this case, the system shifts environments between the instance and MID Server for every page of data, which may degrade performance.

To learn more about running a step on a MID Server, see Integration steps.

Size limits

If your system encounters a timeout or size limit issue, try making one of these adjustments:

Increase the REST transaction quota rule

If the connection between the instance and the MID Server slows down, you may encounter a timeout while waiting for a response from the REST step. Increase the default timeout by updating the REST Attachment API request timeout transaction quota rule.

Default: 60 seconds
Maximum: 300 seconds

Increase the instance timeout

By default, the instance waits for 600 seconds to retrieve a single page of data from a MID Server. If you encounter a timeout when running a Data Stream action through a MID Server, change this default by increasing the datastream_alternative_env_fetch_page_timeout_seconds system property.

Default: 600 seconds
Maximum: 7200 seconds

Increase attachment size

The MID Server sends each page of data to the instance as an attachment. If a page of data is large, it may exceed the allowed attachment size. Increase the allowed size by updating the com.glide.attachment.max_size system property.

Default: 1024 MB
Maximum: None

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.