User-created integrations in DevOps Change Velocity
Summarize
Summary of User-created integrations in DevOps Change Velocity
User-created integrations in the DevOps Change Velocity application allow ServiceNow customers to connect additional planning, coding, testing, security, and orchestration tools not provided by default. This capability extends the native integrations with common tools by enabling customization through Workflow Studio subflows and configuration records, facilitating comprehensive DevOps toolchain connectivity within the platform.
Show less
Key Features
- Integration Objects and Actions: Integration relies on tool capability actions such as Connect, Discover, Import, Lookup, and Notification (webhook). These actions manage connection status, data discovery, data import (excluding historical data), artifact lookups, and event-driven notifications respectively.
- Integration Configuration Roles:
- Integration Developer: Creates tool integration records, Workflow Studio subflows for data transformation, tool capability mappings, and integration capability records specifying the actions supported by each tool type.
- DevOps Admin: Sets up tool records linking to the integration, configures credentials, and manages webhook configurations on source tools.
- Inbound Events: Serve as a staging area to handle notifications and reprocess failed payloads. Common errors in inbound events are addressed by verifying payload structure, repository tracking, subflow publication, execution timeouts, and matching capability mappings.
- Tool and Capability Mappings: Tools can be mapped to multiple capabilities (Plan, Code, Orchestration, Artifact, Test) and actions (Connect, Discover, Import, Lookup, Notification). This flexible mapping supports integration with a broad range of DevOps tools like Azure DevOps, GitHub, Jenkins, Jira, Rally, and GitLab.
- Test Tool Integration: Supports viewing test results (unit, functional, performance) from integrated tools such as Jenkins, Azure DevOps, GitHub, GitHub Enterprise, and GitLab.
- User-Created Security and Orchestration Integrations: Enables integration with additional security and orchestration tools beyond those supported out-of-the-box.
- Custom Fields and Subflows: Allows adding custom fields to planning tool integrations for enhanced configurability and business context, and requires creation of custom Workflow Studio subflows to handle data collection and transformation from source tools.
- DevOps Change Workspace: Provides an interface to create and manage tool integrations for orchestration, planning, and coding tools directly within the DevOps Change Velocity environment.
Practical Impact for ServiceNow Customers
By leveraging user-created integrations, ServiceNow customers can:
- Extend DevOps Change Velocity’s toolchain support to fit unique environments and toolsets.
- Customize data flows and transformations using Workflow Studio subflows tailored to specific tool APIs and payloads.
- Maintain consistent, automated synchronization of planning, coding, testing, and orchestration data through standardized integration patterns.
- Manage inbound event errors effectively to ensure reliable data ingestion and reprocessing capabilities.
- Enhance planning tools with custom fields to better reflect organizational processes and decision-making criteria.
This framework ensures your DevOps tool integrations are flexible, scalable, and aligned with your specific operational requirements while maintaining the integrity and usability of DevOps Change Velocity’s capabilities.
User-created integrations are for integrating additional planning, coding, and test tools that are not available by default in the DevOps Change Velocity application.
The DevOps Change Velocity application includes tool definitions for integrating some common planning, coding, and DevOps test tool integration, but you can also set up user-created integrations for additional tools in your DevOps environment.
Integration objects
DevOps tool integration consists of these objects.
Tool capability actions
- Connect action:
When connecting, the subflow for the specific tool is called and the connection state is updated. The connection status message is shown on the form.
See Connect capability subflow for more details.
- Discover action:
When discovering, an import request record is created and the subflow for the specific tool is called (as defined in the Integration Capability record). Detail and Status fields in the Import Request record are updated with the number of items discovered, updated, and failed.
The transformed payload consists of an array of objects as a JSON string. Elements vary depending on the tool type.
See Discover capability subflow for more details.
- Import action:
Import action does not support historical import functionality.
- Lookup action:
The Lookup main flow is provided to support artifact tool type in a subflow created by your integration developer.
- Notification (webhook) action:
The source tool is configured manually (by your integration developer) to send raw data to the ServiceNow instance. The raw payload is then transformed into a standard JSON object using a subflow.
See the Notification capability subflow and the DevOps - POST /devops/tool/{capability} endpoint of the DevOps API for more details.
Note:If a subflow is not specified, default handling of notifications occurs (original payload is automatically copied to transformed payload).This behavior is useful when the transactional data of the tool is supported by ServiceNow DevOps as is.
See the expected standard payloads in the Notification capability subflow for more details.
DevOps integration configuration overview
Tool integration configuration can be completed by your integration developer and your DevOps admin.
- Integration developer
- Create a tool integration record in DevOps to define the tool you are integrating (source tool).
- Create a Workflow Studio subflow to collect and transform data from the tool you are integrating (source tool).
- Create a tool capability mapping record in DevOps to map the tool
integration record to the tool type capability.Note:Notifications (webhook) capability is supported. Connect and discover capabilities are also supported.
- Create an integration capability record in DevOps to specify the action for the tool type capability.
- DevOps admin
- Create a (planning, coding, or test) tool record in DevOps to
connect to the tool you are integrating (source tool).Note:The tool integration record must be specified in the Tool field of the tool record.
- Configure the source tool with the webhook and credentials.
- Create a (planning, coding, or test) tool record in DevOps to
connect to the tool you are integrating (source tool).
Inbound events
An inbound event serves as a staging area for the notifications flow that supports reprocessing of failed payloads. Meaning, a record in an error state from a failed integration or transformation can be retried.
If an Inbound Event record is in the Error state, the flow was not able to insert the record successfully into the core DevOps tables.
Common errors can be resolved with these actions.
| Error | Action |
|---|---|
| Missing required fields | The transformed payload does not match the standard payload. Refer to the standard and JSON payloads provided. |
| Repository not marked for tracking | The commit cannot be inserted. The DevOps admin needs to track the repository. |
| [Subflow] has not been published within application scope [app_scope] | The subflow is created but not published yet. |
| Timeout exception | The subflow takes more time than the value set in the property: com.glide.hub.flow_api.default_execution_time See FlowAPI - executeSubflowQuick(String name, Map inputs, Number timeout) for more details. Note: The execution of the subflow exceeds the value set in the
Timeout field in the Integration Capability
record. |
| Did not find a matching subflow for notification capability and [tool_integration_sys_id] tool integration | The flow was not able to find the matching subflow. Verify the integration setup procedure. |
| Payload does not match the expected capability. | The Original payload (payload being sent) is a different Capability type than the tool type capability configured in your tool capability mapping. The payload type must match the tool type capability configured in your tool integration. |
- Source tool has not passed the tool ID as a query parameter.
- Source tool has passed on a tool ID, but there is no matching tool ID in the instance.
Tool mappings
A tool can be mapped to multiple capabilities.
| Tool Integration | Tool Type Capability | Tool Capability Mapping | |
|---|---|---|---|
|
|
Plan
Code
Orchestration
Test
|
|
A tool capability mapping can be mapped to multiple actions.
| Tool Capability Mapping | Tool Action | Integration Capability | |
|---|---|---|---|
|
|
Agile Development 2.0
Azure DevOps
Bitbucket
GitHub
GitHub Enterprise
GitLab
Jenkins
Jira
Rally
|
|
Multiple test types can be mapped to each tool integration.
| Test Type | Tool Integration | Test Type Mapping |
|---|---|---|
Unit: JUnit, XUnit, NUnit, Unit test Functional:
Performance: Load |
|
Azure DevOps
Jenkins
GitLab
GitHub and GitHub Enterprise
|