Skip to main content

Release v0.0.56

· 3 min read
vNext Team
vNext Team
Burgan Tech Engineering

Overview​

This release promotes SoapTask to a first-class task type (Type 16) for calling SOAP 1.1 / 1.2 web services directly from a workflow, closing the #647 investigation into whether SOAP integration could be handled by the existing HttpTask. The conclusion: a dedicated abstraction is warranted because SOAP envelopes need raw-XML body handling, a SOAPAction header, and the ability to treat HTTP 500 SOAP Faults as inspectable business responses.

Features​

SoapTask — dedicated SOAP 1.1 / 1.2 task type (Type 16)​

HttpTask could technically reach a SOAP endpoint, but it could not cleanly model the SOAP envelope, the SOAPAction header convention, or SOAP Fault responses that arrive over HTTP 500. SoapTask makes these first-class. Unlike HttpTask, the request body is stored as a raw XML string so SOAP envelope templates survive untouched.

Minimal definition:

{
  "key": "get-customer-soap",
  "version": "1.0.0",
  "domain": "core",
  "flow": "sys-tasks",
  "flowVersion": "1.0.0",
  "tags": ["soap"],
  "attributes": {
    "type": "16",
    "config": {
      "url": "https://api.example.com/services/CustomerService",
      "soapAction": "http://example.com/GetCustomer",
      "soapVersion": "1.1",
      "acceptedStatusCodes": ["500"]
    }
  }
}

Configuration fields:

FieldRequiredDefaultDescription
urlYes—Target SOAP endpoint URL
soapActionYes—SOAPAction value
soapVersionNo"1.1""1.1" or "1.2"
bodyNonullSOAP envelope template as a raw XML string
headersNonullAdditional HTTP headers
timeoutSecondsNo30Request timeout
validateSslNotrueServer SSL certificate validation
acceptedStatusCodesNo—HTTP error codes treated as success (e.g. ["500"] for SOAP Fault pass-through)

Why acceptedStatusCodes: ["500"] matters: SOAP services typically return a SOAP Fault over HTTP 500. Without this setting the task is considered failed and the error boundary fires; with it, the response reaches OutputHandler so the fault can be inspected and handled inside the mapping script.

Mapping API on SoapTask:

MethodDescription
SetUrl(string)Override the target URL
SetBody(string?)Set body from a raw XML string
SetBody(XmlDocument?)Set body from XmlDocument.OuterXml
SetSoapAction(string)Override the SOAPAction value
SetHeaders(Dictionary<string, string?>)Replace all headers
AddHeader(string, string?)Add or update a single header
RemoveHeader(string)Remove a single header

The task response Data field contains the raw XML string returned by the service. See the SOAP Task reference for the full contract.

Reference: issue #647, PR #685

Configuration Updates​

Configuration for v0.0.56:

{
  "runtimeVersion": "0.0.56",
  "schemaVersion": "0.0.42"
}

Note: Schema version 0.0.42 is unchanged from v0.0.54 / v0.0.55.

Container images: all services published at tag 0.0.56 under ghcr.io/burgan-tech/vnext/* (execution, orchestrator, init, inbox, outbox, db-migrator), signed with Cosign and shipped with SBOM + provenance.

Issues Referenced​

  • vnext #647 — Evaluate SOAP integration via HttpTask and add a dedicated SoapTask if needed → resolved by adding SoapTask (Type 16).

Summary​

  • SoapTask (Type 16) enables direct SOAP 1.1 / 1.2 web service integration without a separate adapter layer.
  • Request body is a raw XML string; soapAction and soapVersion model the SOAP envelope convention.
  • acceptedStatusCodes: ["500"] routes HTTP 500 SOAP Faults through OutputHandler for inspection in the mapping script.
  • Full mapping API (SetUrl, SetBody, SetSoapAction, AddHeader, …) is available on the SoapTask class.

vNext Runtime Platform Team
Released May 20, 2026