Skip to main content

Version 1.18.2.0

Release Date: September 14, 2026 Release Type: Stable Previously published as: 1.18.16 (image tag staging-1.18.16)

OData paged and delta reads with per-flow concurrency, back-pressure and bounded delivery retries, together with opt-in CSRF token handling, entity lookup from an uploaded EDMX document and a series of OData connector fixes.

Backend Server​

New Features​

  • OData paged reads: An OData start node can now read a large entity set page by page instead of in a single request. In server-driven mode the connector follows the next-page links the service returns (OData v2/v3 and v4); in client-driven mode it pages with $top/$skip, which requires a page size and a deterministic $orderby. Each page enters the flow as its own message, with MIP_ODATA_* headers carrying the run id, the page number and a last-page flag (MIP_ODATA_LAST_PAGE).
  • Safeguards for paged runs: An optional Max Pages value caps a single run, and a capped run does not flag any page as the last one. A failed page request is retried up to three times with authorization refreshed before each attempt, a run that is still reading is not overlapped by the next scheduled run, and a run that finds no records emits no message. An unrecognized OData version or paging mode, an invalid page size, or a response without the expected paging structure fails the run with a clear error instead of being treated as an empty result.
  • Delta reads with a stored watermark: With delta enabled, each run reads only the records changed since the last successful run by adding a filter on the configured delta field (datetime, datetimeoffset or ISO format). The watermark is stored per flow, advances only when a run completes successfully and never moves backwards. It is kept across undeploy and redeploy and removed when the flow is deleted; the first run has no lower bound and reads the full set.
  • Concurrent Consumers per flow: Each deployed OData flow now consumes its own pages with the number of concurrent consumers set on its start node, instead of one shared setting for all OData flows. With a single consumer, pages are processed strictly in order and the target sees one writer at a time; a higher value trades ordering for throughput. These subscriptions are rebuilt automatically after a backend restart.
  • The reader waits for its consumers: Before handing over a page, the reader checks how many pages of its flow are still waiting and pauses fetching once that number reaches ten times the flow's Concurrent Consumers value. A large read therefore proceeds at the speed the target accepts instead of piling up in the message broker.
  • Bounded delivery retries with Max Retry: For paged reads that use the After Flow commit strategy, a page that cannot be delivered is retried up to the configured Max Retry attempts, Retry Delay apart. When the limit is reached the page is marked ERROR with a message stating that the target is unreachable, and reading is paused so the remaining data stays at the source. Reading resumes automatically once a page is delivered again, including when the failed page is retriggered with Trigger Message in Message Monitoring, and the preserved window is then read again in full; redeploying the flow alone does not lift the pause. With Max Retry empty or zero, a page is kept and retried without limit until it is delivered.
  • Opt-in CSRF token fetch for OData writes: When the option is enabled on an OData node, the connector fetches a CSRF token and its session cookies from the service before POST, PUT, PATCH, MERGE and DELETE requests, as required by services that protect write operations with CSRF tokens. The option is off by default and adds no extra request when disabled.
  • Entities from an uploaded EDMX document: The entity list of an OData node can now be read from an uploaded $metadata (EDMX) document instead of the live service, which helps when the service cannot be reached at design time. The EDMX selection is saved with the flow.

Bug Fixes​

  • Authenticated OData polling works: An OData start node configured with Basic or OAuth2 authentication failed every poll with "Credential not found." before a request was sent. The credential selected on the node is now used.
  • MERGE and DELETE requests reach the service: MERGE operations (OData v2/v3) failed before the request was sent; they are now sent as POST with the X-HTTP-Method-Override header. DELETE requests no longer carry the body of the triggering message, which could make the service reject the request.
  • Atom content type is recognized: Flows configured with the Atom content type failed with "MIME type may not be blank". The content type is now resolved regardless of letter case.
  • "Get Entities and Fields" sends Message Headers and reports the real error: The metadata request made from the designer now includes the node's Message Headers (Constant and Expression rows), so services that protect $metadata with a header such as an API key can be read. When the request fails, the response states the actual cause, for example the HTTP status returned by the service, instead of an unrelated database error, and a node without authorization no longer causes an internal error.
  • OData Timeout bounds the whole call: The Timeout configured on an OData node previously limited only connection establishment, so a service that accepted the connection and never answered held the call open indefinitely. The Timeout now also applies to waiting for the response, on both the start node and the connector node, and such a call fails with a read timeout. Review your OData Timeout values before upgrading: a call that legitimately runs longer than the configured Timeout now fails where it used to wait.
  • Compressed OData responses are decoded: The connector now requests only gzip and deflate encodings and decompresses such responses, so payloads are read correctly in the flow and are readable in Message Monitoring. Previously a service answering with an unsupported compression could produce pages with no records while the run was reported as successful.
  • OData polling uses the configured message broker: The OData start node sent polled data to a broker address on the local host instead of the platform's configured broker connection, so polling could block in container deployments. It now uses the configured connection like the other connectors.
  • OData polling survives redeploy and restart: Redeploying an edited OData start flow could leave it with a stale schedule, so the flow never polled again. In addition, a backend restart removed the polling schedules of deployed OData flows until another deploy rebuilt them. Schedules are now recreated on redeploy and restored at startup.
  • Trigger Message works for OData polling records: Retriggering an OData polling record from Message Monitoring failed with an endpoint resolution error while scheduled runs succeeded. A retrigger now starts a clean new run, the same way the scheduler does.
  • $batch requests use a correctly separated URL: The batch URL is now built as .../EntitySet/$batch; previously the / separator before $batch was missing.
  • Scheduled jobs are cleaned up for late deploy events: When a deploy event arrived for a flow that was already undeployed, the flow's scheduled job was not removed. It is now deleted.

Frontend Server​

New Features​

  • OData paged-read, delta, retry and CSRF settings are stored with the flow: The new OData settings — paging mode, page size, max pages, delta field and type, commit strategy, Max Retry, the CSRF option and the EDMX selection — are saved with the flow and passed on to the backend.
  • Message Headers forwarded to the entity lookup: The "Get Entities and Fields" request now accepts the node's Message Headers and forwards them to the backend, so services that require a header to read $metadata can be queried. The parameter is optional; existing callers are unaffected.
  • EDMX resources: An uploaded EDMX document is handled as a flow resource and can be listed together with its content, the same way and with the same developer/admin access as WSDL resources. The metadata document is sent to the backend in the request body, so large documents are accepted.

1.18.2.0 is a stable release. Previous: 1.18.1.10