Release Notes CWM 2.1

This section contains the following topics:

CWM v2.1 Release Notes

Intro

This document provides information about changes in Cisco Crosswork Workflow Manager 2.1.

Version history

Release date Version Release notes
9/Jun/2023 Cisco Crosswork Workflow Manager 1.0 Cisco Crosswork Workflow Manager 1.0 Release Notes
29/Feb/2024 Cisco Crosswork Workflow Manager 1.1 Cisco Crosswork Workflow Manager 1.1 Release Notes
29/Jun/2024 Cisco Crosswork Workflow Manager 1.2 Cisco Crosswork Workflow Manager 1.2 Release Notes
26/May/2025 Cisco Crosswork Workflow Manager 2.0 Cisco Crosswork Workflow Manager 2.0 Release Notes
29/Jan/2026 Cisco Crosswork Workflow Manager 2.1 Current ones

What's new

Feature Description
Geo Redundancy Support

Crosswork Workflow Manager now supports active-standby deployments across geographically distributed sites. This enhancement provides higher availability, automatic failover in case of site outages, and improved business continuity. For details, refer to the Cisco Crosswork Network Controller 7.1 Installation Guide Geo Redundancy Overview
Workflow Design Studio

The enhanced Workflow Designer is a low-code visual environment for building and managing workflows using drag-and-drop interactions. It provides a graphical representation of workflows where states, activities, and subworkflows are arranged within a directed graph. The Designer enables the user to define sequencing, nesting, and error-handling directly inside the graph, without the need to write workflow code. Workflow definitions are created and modified through drag-and-drop operations, context menu actions, and keyboard interactions, reducing the need for manual configuration.

API Request Tracing with X-Correlation-ID

Crosswork Workflow Manager APIs support request correlation using the X-Correlation-ID HTTP header.

If a client includes this header in the request, the same value will be captured in logs and can be tracked consistently across Crosswork services and downstream calls. This makes it easier to trace specific workflows, analyze performance, and troubleshoot issues across multiple services.

Clients such as CWM-S may generate and propagate their own X-Correlation-ID values to enable end-to-end tracking of workflows.
Audit logging

Crosswork Workflow Manager now provides audit logging for all user-initiated and API-driven changes. Each modification is recorded with a timestamp and user ID, ensuring traceability and compliance with audit requirements.

Adapter signing

Adapters can now be digitally signed by their developers and CWM will verify the signature upon adapter deployment. This feature helps verify that the adapter comes from a trusted source and detect any unauthorized modifications to the adapter code.

Custom secrets

CWM 2.1 supports adapter-defined custom secrets, enabling secure, extensible handling of sensitive data required during adapter activity execution.

With custom secrets, adapters can define their own secret schemas using Protocol Buffers and control how secret data is validated, prepared, cached, and applied at runtime. Secrets are strongly typed, securely stored, and injected by CWM, while their interpretation and usage remain fully owned by the adapter.

Enhanced Event Correlation with Payload-Based Support

Event correlation is now extended to support payload-based correlations (available only in the API) in addition to existing event context attributes. Correlation rules can now reference event payload fields using JQ expressions. This enhancement is fully backward compatible and existing workflows using context-based correlation continue to work without change.

Support for MQTT Events

CWM 2.1 enables seamless integration with MQTT brokers. For the consume event kind, CWM connects to an MQTT broker and subscribes to specific topics. When an event matching a topic is received, event data is forwarded to the workflow. For the produce event kind, an executing workflow can generate one or multiple events that CWM delivers to the broker for publishing on the designated topic.

Adapter changes

Adapter XDK changes

OASX:

  • XDK can now generate headers in the created adapter if the OpenAPI file includes headers​.

  • XDK can now parse OAS schema for activity responses to construct specific response message in adapter .proto file, and build go code.

REST Response Headers Support

The XDK REST package now includes response headers in addition to status and payload.

Previously, REST responses only contained the status code and response body, limiting visibility into the full HTTP response. Users now have access to response headers, enabling better handling of metadata such as content types, authentication tokens, caching directives, and custom headers.

Resource structure refactoring

  • The Resource message structure has been refactored to separate connection management from protocol-specific configuration. The new structure introduces two distinct components: Connection manages network connectivity parameters, while Config handles protocol-specific settings for HTTP, SSH, and Telnet. The Resource message now contains both a connection field and an optional config field.

API changes

New API endpoints

MCP (Model Context Protocol) API

New API endpoints have been added to support Model Context Protocol (MCP) access to the CWM API using JSON-RPC 2.0. These endpoints allow clients to discover and invoke CWM APIs as MCP tools.

Method 2.1 path
GET /mcp
POST /mcp

Supported MCP methods

  • initialize

  • tools/list

  • tools/call

  • ping

  • notifications/initialized

  • logging/setLevel

Job API

New API endpoints are available for interacting with job runs, including streaming job history events and signaling running jobs.

Method 2.1 path
GET /job/{jobId}/runs/{runId}/history/stream
POST /job/{jobId}/runs/{runId}/signal

  • Job history streaming uses Server-Sent Events (SSE)

  • Job signaling allows custom payloads to be sent to a running workflow

Payload API

A new API endpoint has been added to retrieve stored payloads by key, with optional automatic decryption.

Method 2.1 path
GET /payload/{key}

  • Supports optional decrypt query parameter (default: true)

Public Key API

A new set of API endpoints has been added for public key management, used for adapter verification and security workflows. These endpoints allow you to list, create, update, and delete RSA public keys.

Method 2.1 path
GET /publicKey
POST /publicKey
GET /publicKey/{publicKeyName}
PATCH /publicKey/{publicKeyName}
DELETE /publicKey/{publicKeyName}

  • Supports filtering by author and enabled status

  • Supports RSA public keys in PKCS#1 and PKCS#8 formats

System Function API

A new API endpoint is available to list all built-in and system-provided functions and their activities.

Method 2.1 path
GET /systemFunction

  • Returns system functions grouped by package and category

  • Includes activity input/output schema definitions

Changes to existing endpoints

Task API

  • GET /task

  • Added optional query parameters:

    • jobId – filter tasks by workflow ID

    • runId – filter tasks by workflow run ID

Workflow API

  • DELETE /workflow/{workflowId}

  • Request body changed from stopRequest to deleteRequest

  • New options added:

    • force – force delete even if dependencies exist

    • forceStop – force stop running instances before delete

  • POST /workflowImport

  • Response status changed from 200 → 201 Created

  • Response body changed from a string UUID to a structured import result

  • Import now skips duplicate workflows instead of failing

    Adapter API

    • POST /adapter

    • Added force option to upload request

    • Allows forced adapter upload even when conflicts exist

    • GET adapter/{adapterId}

    • Adapter response now includes:

      • hashSum

      • verified

      • List of adapter activities with schemas

    Schema changesEvent API

    • correlationAttrs type changed:

    • Before: string[]

    • After: integer[] (attribute index based)

    • Added payloadAttrs field (map of string to string)

    Adapter and Catalog schemas

    • Added hashSum field to adapter and catalog adapter responses

    • Added verified field indicating adapter verification status

    • Added list of adapter activities to adapter responses

    System Defaults

    • Added new audit-related configuration fields:

    • auditIncludeData

    • auditMaxDataSize

    • These fields are supported in:

    • System defaults responses

    • Patch adapter requests

Breaking changes

The following changes may require client updates:

  • Event definition change

  • correlationAttrs now expects integer indices instead of strings

  • Workflow import response

  • Response code changed to 201

  • Response body structure changed from a string to a detailed object

  • Workflow delete request

  • Request body changed from stopRequest to deleteRequest

Bug fixes

Backend bug fixes

CDETS ID Description

CSCwq55674

Previously, performing a switchover to standby in CWM 2.0 with CNC 7.1.1 patches caused dynamic worker pods to double with each switchover. This was due to each Geo HA cluster recreating dynamic services with different names.

This issue has been resolved by using the same CNC service name across all Geo HA clusters, preventing unnecessary duplication of worker pods.

CSCwp06363

Fixed an issue where redeploying an adapter via the API, after it had been uploaded and deployed with createWorker=false, could fail with an internal server error. The system now handles adapter redeployment correctly when the adapter already exists.

Supported versions

Component Supported Version(s)
Hypervisor VMware vCenter Server 7.0 (U3p or later),

ESXi 7.0 (U3p or later)
Browsers Latest versions supported. Tested versions:

Chrome 135

Safari 18.4

Edge 135

Firefox 137
NSO Adapter Minimum supported NSO release: 6.2.2 (Validated with 6.4)
JSON Version 7
Kafka Version 3.3.2
CloudEvents Version 1.0.2
OpenAPI Version 2.0