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 enable ServiceNow customers to integrate additional planning, coding, testing, security, and orchestration tools that are not included by default. This extends the capabilities of the DevOps Change Velocity platform by allowing custom integrations with various tools in the DevOps toolchain, providing a unified view and management of DevOps activities.
Show less
Integration Objects and Actions
DevOps tool integration consists of several key actions and objects:
- Connect action: Establishes and updates the connection state with the external tool.
- Discover action: Imports and updates data from the tool by creating import request records with detailed status.
- Import action: Supports data import but does not handle historical imports.
- Lookup action: Supports artifact type tools via subflows created by integration developers.
- Notification (webhook) action: Allows the source tool to send raw data to ServiceNow, which is transformed into a standard JSON format for processing.
Subflows in Workflow Studio are essential to implementing these actions, transforming and mapping data from external tools into the DevOps Change Velocity system.
Configuration Roles and Process
Integration setup involves collaboration between integration developers and DevOps administrators:
- Integration Developer: Creates tool integration records, designs Workflow Studio subflows to collect and transform tool data, maps tool capabilities to integration actions, and defines integration capabilities.
- DevOps Admin: Creates DevOps tool records linking to tool integrations, configures connections and credentials, and manages webhook configurations on source tools.
Error Handling with Inbound Events
Inbound events act as staging areas for notifications and support reprocessing of failed payloads. Common errors include missing fields, untracked repositories, unpublished subflows, timeouts, and payload mismatches. Administrators can resolve these errors by ensuring correct payload formats, tracking repositories, publishing subflows, and verifying integration mappings.
Tool and Capability Mappings
Tools can be mapped to multiple capabilities—planning, coding, orchestration, artifact, and testing—and each capability supports various actions like connect, discover, import, lookup, and notification. This flexible mapping enables comprehensive integration of popular tools such as Azure DevOps, GitHub, GitLab, Jenkins, Jira, Rally, and Bitbucket within the DevOps Change Velocity environment.
DevOps Test and Security Tool Integration
The application supports integration of unit, functional, and performance tests from Jenkins, Azure DevOps, GitHub, GitHub Enterprise, and GitLab. Additionally, users can create custom integrations for security and orchestration tools not supported out-of-the-box.
Practical Implementation
To create a user-defined DevOps tool integration, integration developers configure tool settings and build Workflow Studio subflows to handle data collection and transformation. DevOps administrators then establish tool connections and credentials within the platform. Custom fields can be added to planning tool integrations for enhanced configurability and business-specific insights. Integrations can also be created directly from the DevOps Change Workspace to streamline setup.
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
|