CWM v1.2 Release Notes
Intro
This document provides information about Cisco Crosswork Workflow Manager 1.2, including new features, API changes, and a list of bug fixes and system requirements.
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 | Current ones |
What's new
Feature | Description |
---|---|
Human interaction in workflows | Workflows can now include decision points for human operators that are displayed as guided tasks in the CWM UI. A task could be something as simple as approving or rejecting a piece of configuration, verifying an action, displaying differences between configuration, capturing additional information required for an order to proceed, or asking a user what action to take.To implement a guided task, the workflow designer creates a form using a drag and drop editor in the CWM UI. Then, inside the workflow definition, he can refer to the created form and provide variables to be used inside the form when the task is prompted and use the callback state to define when and how the interaction should be conducted. When the workflow definition is being executed and the callback state is reached, the task will appear in CWM UI, asking the operator for input. |
Support for Callback state | The Callback state (as per Serverless workflow specification) can now be used as part of a workflow to handle human interaction for CWM 1.2. See a detailed description of the callback state in the Serverless Workflow Specification. |
Input schema validation | Added support for input schema validation for a workflow definition and for ensuring that when a new job is created, input data is validated against an dataInputSchema. If input data for a job is not valid, the API returns an error.Input schema forms a contract between workflows and the entities that interact with them. If data that is provided to a workflow does not conform to the input schema, this can potentially result in errors during execution. Validating this means the operator can be informed upfront and get immediate feedback and be able to rectify any potential issues due to invalid data input. |
Migration of CWM UI to Harbor library | Updated the Admin, Workflows and Job Manager views and UI elements (navigation, footer, header) using the Harbor UI library for better user experience and improved the functionality of the following views: Job execution logs, Job details, Adapter details, Secret details, Workflow details and Code view. |
Updated NxF platform to v2.1-317 | CWM 1.2 has been upgraded to the latest NxF version: 2.1-317 build. |
System-defined utilities | Added four pre-packaged system-defined utilities that expose activities to be used by workflow designer. Invoking them as actions inside a workflow helps fulfil basic tasks without the need to create custom adapters. The utilities include:FailJob - allows a workflow designer to explicitly fail a workflow with a code and message when certain conditions are met, which currently is not provided for in the Serverless workflow specification.system.function.@latest.common.FailJobGetResourceType - returns the resourceType for a given resource ID.system.function.@latest.resource.GetResourceTypeNoOp - the Callback state for human interaction mandates that an action be invoked before the callback state waits for an event. It is perfectly valid for a callback state not to execute an action, but just wait for an event which is capturing data from the user. The NoOp function will bypass the action and just wait for the defined event.system.function.@latest.common.NoOpWaitUntil - introduces a pause in workflow execution based on a user-provided timestamp.system.function.@latest.common.WaitUntil |
Expression functions | Added support for expression functions for workflows. They are used to evaluate specific conditions or manipulate workflow data during execution. Expression functions are defined within a workflow and can be referenced and executed as part of a state action, or used to act as filters in various workflow data operations. Read more about expression functions in the Serverless Workflow Specification. |
Subworkflow tags | Subworkflows (Child workflows) can now inherit tags from workflows that have spawned them. They can also have additional tags linked to them controlled by the subFlowTags field under the state metadata. The field should contain a list of JQ expressions that evaluate for a tag value. |
Workflow Error and Timeouts handling improvements | The onError can now refer to nested errors in the stack. E.g. NSO adapter can raise NSO error, caused by another service, caused by HTTP. On errors can refer to any of the error types to capture the error, and take relevant actions. Adapter errors have been extended with more detailed error types/codes which allows for differentiating between 4XX errors as well.We have also added support for Activity timeouts handling and few timeout types that can be caught:ActivityTimeoutErrorChildWorkflowTimeoutErrorProducedEventTimeoutErrorConsumedEventTimeoutErrorTimeoutError - generic timeout error which wraps the above errors.The above timeouts are retryable and could be caught using onError. |
API for Resource import/export | Added support to load resources list in CWM using new API endpoints. This enables users to load all resources in a single API call. |
Job execution logs decoded | The workflow data displayed in the Job execution details is now decrypted to simplify debugging and troubleshooting. |
Adapter changes
New adapters
Generic DB adapter - the Generic Database adapter provides the ability to interact with SQL databases. It allows for sharing user data between workflow executions by connecting to a persistent storage that is external to CWM. The adapter implements the SQL query and the SQL exec commands.
Adapter XDK changes
Support for JSON key specification in protobuf field annotations We have introduced support for specifying JSON keys in protobuf field annotations, enabling field names in generated activities to match the source specifications (YANG files or Open API Specification). This simplifies user experience by ensuring consistency between input field names and their corresponding JSON keys.
Support for NSO actions generation We have introduced support for auto-generating activities for NSO actions using YANG action definitions. Actions are the most common way to implement non-configuration automation in NSO. They represent a task or an operation that a user of the system can invoke on demand, such as downloading a file, resetting a device, or performing a test.
Adapter SDK changes
Updated JSON schema generation For Cisco NSO, Generic CLI, Generic Email and Generic REST adapters, we have updated the JSON schema generation so that it uses the https://github.com/pubg/protoc-gen-jsonschema plugin when executing the 'cwm-sdk create-installable' command. The plugin is now a prerequisite for creating a new installable files for the adapters.
Removed restriction to have both Resource and Secret in adapter proto We have removed the enforcement of the adapter configuration to require the Secret field whenever there is a Resource field present.
API changes
Table keys
-
✓ - indicates that an endpoint exists for given version.
-
x - indicates there is no such endpoint for given version.
-
/example/api/path - shows how existing endpoint path changed from version to version.
New API endpoints
Forms API
Endpoint | v1.1 | v1.2 path |
---|---|---|
GET/form | x | ✓ |
POST/form | x | ✓ |
GET/form/{formId} | x | ✓ |
DELETE/form/{formId} | x | ✓ |
PATCH/form/{formId} | x | ✓ |
Event API
Method | v1.1 | v1.2 path |
---|---|---|
POST | x | /event/http |
EventType API
Method | v1.1 | v1.2 path |
---|---|---|
POST | /eventType/{name}/{action} | /eventType/{type}/{action} |
GET | /eventType/{name} | /eventType/{type}/{kind} |
DELETE | /eventType/{name} | /eventType/{type}/{kind} |
PUT | /eventType/{name} | /eventType/{type}/{kind} |
Resources API
Method | v1.1 | v1.2 path |
---|---|---|
GET | x | /resourceExport |
POST | x | /resourceImport |
Bug fixes
Backend bug fixes
CDETS ID | Title | Description |
---|---|---|
N/A | Postgres backups stored in MinIo not cleaned up from disk space | We have updated the default backup configuration. Previously, full backups were done once a week, and a total of 10 backups were retained before older backups were cleaned. As a result, if the allocated disk space was not enough for 10 weeks of backups, the system would crash due to lack of disk space. New backup parameters are as follows:Full backup - weekly. Incremental backup - daily.Number of full backups to retain: 4. After 4 weeks, old backups would be removed. |
CSCwj17429 | Concurrent map writes error | We have resolved the issue where multiple activities (where parallel state or async activity execution may be used) are running in parallel and each activity is trying to update the workflow data. The issue caused the workflow worker pod to crash and restart. |
CSCwj44766 | ForEach state in parallel mode locks executions if at least one of the iterations times out. | We have fixed the way results from async calls are collected so that it’s not blocking the workflow execution. |
CSCwj75547 | Event listener not stopped automatically when deleting EventType | We have fixed a bug that caused event listener keep running even after deleting the event type associated with it. Now, when creating a new event type with the same name, there is no existing listener running and the user needs to start a new listener. |
CSCwj40378 | Workflow execution fails when event resource is unreachable | We have introduced better error handling in cases when resource created for an event is not available, instead of being forced to restart event manager and API service. |
CSCwj23736 | Possibility to delete resource used in an event type | We have fixed a bug where a resource linked to an event could be deleted. |
CSCwj23042 | Confusing error message when wrong version of child workflow is referenced from the parent workflow | We have improved the error message for specifying the wrong version of a child workflow to be invoked by parent workflow. |
Frontend bug fixes
CDETS ID | Title | Description |
---|---|---|
CSCwj38677 | Navigating away from produce' type event always triggers “Unsaved changes” dialog | Now, if the user tries to navigate to a different page from the details page of an event with the Produce type, the “Unsaved changes” dialog box is not shown if there are no changes. |
CSCwj34050 | UI starts lagging when loading more than 500 jobs | We have fixed the issue with the Job Manager becoming irresponsive as the number of jobs increase. |
CSCwj08097 | “Unsaved changes” dialog keeps appearing when leaving resource details page | We have fixed the incorrect behavior of the “Unsaved changes” dialog box appearing each time upon leaving the resource details page. |
CSCwj06430 | Start Listener disable/enable button not working as expected | We have corrected the behavior of the Start Listener button. When there is an unsaved change in event type details page, the Start Listener button is now enabled. |
CSCwk76145 | Stop listener button keeps showing after the listener is stopped | We have restored the expected behaviour of the Stop listener so that the button changes to Start listener each time the listener is stopped. |
CSCwj60679 | No possibility to show Job Event Log for consecutive jobs in the Job Manager | Using the 'back' button in the browser to get back to the previous view of the Job Manageris now possible. |
CSCwm08962 | Job Manager shows a maximum of 1000 jobs | We have improved the Job Manager pagination so that the maximum number of jobs that can be displayed in the CWM UI is 5000 jobs with 3 pagination sizes: 30, 50 and 100. |
Minimum system requirements
Component | Minimum value |
---|---|
CPU | 16 core |
RAM | 64 GB |
Storage | 100 GB |