Page 2 – OpsHub – Enterprise Application Integration & Migration Software Tool

How to Integrate IBM Rational DOORS Next Generation and Azure DevOps

IBM DOORS or IBM DOORS Next Generation and Azure DevOps integration provides end-to-end traceability within the application delivery ecosystem, ensuring the digital continuity required for a successful digital thread implementation. Discover how IBM DOORS NG and Azure DevOps integration seamlessly synchronizes system and software requirements. This bidirectional synchronization ensures real-time data availability, enabling teams to access the most current information no matter the platform.
OpsHub Integration Manager (OIM), an enterprise-grade integration tool, automates the flow of information across systems without manual intervention, ensuring continuous, uninterrupted work. With this integration in place, teams can focus on their tasks while the synchronization runs in the background.

Video Transcript

The video shows how software and system requirements created and linked in IBM DOORS NG synchronize seamlessly to Microsoft Azure DevOps Updates in Azure DevOps also sync bidirectionally to DOORS NG, ensuring full visibility in real-time.

In DOORS NG, a system requirement is created that will synchronize to Azure DevOps (ADO). For this requirement, a description and a comment are added. OpsHub Integration Manager (OIM) supports the synchronization of rich-text formatting, such as bold, underlined text, tables, and more. Additionally, the priority and status for the requirement are set. All the details associated with this requirement will synchronize in real-time.

Next, a second system requirement is created in DOORS NG, which will also synchronize to ADO. For this second requirement, a description is added, and the priority is set to “Low.” Then, a third system requirement is created in DOORS NG, which too will synchronize to ADO. Adding a description and a comment to this requirement ensures all the details are reflected in ADO post-synchronization.

Once all three system requirements are created in DOORS NG, ADO is refreshed to verify their visibility. All three system requirements, along with their associated details, have successfully synchronized from DOORS NG to ADO. This includes all titles and descriptions, formatted correctly, and even the remote entity link of each DOORS NG system requirement is visible in ADO. The comments have also synchronized successfully, with the “High” priority in DOORS NG mapped to “1” in ADO, ensuring consistency.

Back in DOORS NG, a software requirement is created, which will also sync to ADO. A description and a comment are added to this software requirement. OIM continues working in the background, fetching the requirements for synchronization. In ADO, the software requirement syncs successfully, and now a relationship is created between one of the system requirements and the software requirement.

To establish this relationship, the link type – “child” – is selected and the software requirement created in DOORS NG is linked. The parent-child relationship is created successfully. The description of the system requirement is then updated, and a comment is added. The newly created relationship, updated description, and comment bidirectionally sync to DOORS NG.

To verify this, the software requirement in ADO is opened and confirms that the system requirement is linked as a parent. The remote entity link and remote ID of the DOORS NG software requirement are also visible in ADO. The “Medium” priority in DOORS NG maps to “2” in ADO, reflecting accurately.

Returning to DOORS NG, the system requirement is opened to view the bidirectionally synced details. The updated description and newly added comment from ADO are automatically available in DOORS NG, demonstrating reverse synchronization. The parent-child relationship is also preserved, as the software rn of the software requirement in DOORS NG. Back in ADO, it is confirmed that the updated description has synchronized successfully, completing the workflow demonstration. equirement appears as a child in the system requirement.

Finally, changes are made to the description.

Entity Project and Issue Type Movement Feature

In OpsHub’s latest feature video, watch how to address challenges related to data inconsistency by keeping data in sync as entities are deleted or moved within projects. This prevents duplication or orphaned data. In this feature, if the host system prohibits movement, OpsHub Integration Manager labels the former entity as deprecated, providing an easy view and clarity of functions. Watch the video to learn how the feature works!

Video Transcript

Project restructuring or changing type of backlog have become common and frequent operations nowadays with expanding teams and flexible modern age ALM tools. The focus is now shifting from simply integrating to tools with simple fields like summary, description and status to a more holistic integration experience keeping both tools in the same state.

In this video, using the example of Jira and Digital ai Agility, we will demonstrate OpsHub’s latest feature, Entity, Project and Issue Type Movement, Restructuring and Replication to address issues of data inconsistency between systems. We will also change the backlog type in Jira and demonstrate how it is replicated in Agility and vice versa along with the replication of inline references and images between the systems.

On the right-hand side of the screen, we have created a project named Trinity J in Jira, and on the left, we can see the corresponding Trinity A project in Agility. We have pre- synchronized tense stories from Trinity J in Jira to Trinity A in Agility. Let’s first look at the project movement in Jira. Here, we have created another project named EDM J. We are now moving all the ten entities from Trinity J to EDM J.

Project Movement is a common functionality used by companies to shift or reassign tasks to other teams or groups. Now, let’s refresh the page to see if the entities are visible under the EDM J project. All ten entities are now visible under the EDM J project in Jira. In this demo, we have mapped Trinity J in Jira to Trinity A in Agility, and similarly, EDM J in Jira to EDM A in Agility. Now, as part of a seamless synchronization process, we will see all the entities in Trinity A move to EDM A in Agility.

Let’s refresh the Agility page to see if all the entities have moved from Trinity A to EDM A. We can see all the entities are reflecting under the EDM A project. Let’s open a story in Jira to see if all the details under it are also visible in the story in Agility.

All the basic details like the description, status and priority, and the advanced details like the inline image column pointers are visible in the Agility story. The story in Agility is a replica of the story in Jira. All the complex data enriched text formatting like embedded images, attachments, tables, pointers, etc, will be preserved in the synchronization.

Now, let’s look at the feature entity type change in Jira. We will change the entity type from a story to a bug. Once the synchronization is complete, the same story will then change to a defect in Agility. In Agility, if we change the backlog type, it will delete the existing backlog, and then create a new backlog. Therefore, unlike Jeera where the same story was converted to a bug, here in Agility, we will see the existing story is deleted and in new defect is created. All the details under the original story will be replicated to the defect.

Upon refreshing the page, we can see this story has converted to a defect in Agility, and all the data under it has been preserved in Jira. We will now add a comment notifying that the issue type has been changed. The same comment will synchronize automatically to Agility under the defect. Navigating to Agility, we can see the original story is deleted, replacing the new defect, and the comment added in the Jira bug is visible under the same defect.

This completes the demo. Thank you for watching.

Verisium Manager (Formerly known as Cadence vManager) and Jama Connect Integration

For semiconductor and chip design companies, achieving comprehensive traceability throughout the pre-silicon phase—from planning, design, verification, simulation, testing, and redesign is crucial for minimizing errors and reducing costs. Discover how Verisium Manager and Jama integration empower requirements management and verification teams to collaborate seamlessly through real-time information exchange, eliminating manual intervention. This advanced integration fosters digital continuity, building a robust digital thread that drives digital transformation initiatives forward.
Powered by OpsHub Integration Manager (OIM), the Verisium Manager and Jama integration ensures seamless bidirectional data exchange with 100% accurate and reliable synchronization, even for complex entities.

Video Transcript

Let’s begin with the demo. Let’s assume that the product management team is using the requirement management tool Jama, and the verification team is using the verification tool Verisium Manager. The product manager has received a requirement related to wireless communication support via System-on-Chip (SoC); for the same, a couple of requirements are defined at the Jama side. For example, one could be wireless communication via Bluetooth Low Energy System-on-Chip.

Along with this requirement, the product manager has defined additional details such as the description, acceptance criteria, priority status, and so on. The product manager believes this requirement can be completed by performing two major verifications: power consumption verification and frequency band verification. For the same, sub-requirements related to power consumption verification and frequency band verification can be defined at the Jama side.

Now, we will go to Verisium Manager. Upon refreshing the Verisium Manager, we can see that there are no requirements listed. This means the verification engineer won’t know about these requirements unless they are explicitly defined in the tool. To synchronize the data between the requirement tool and the verification tool, we will use OpsHub Integration Manager.

Next, we go to OpsHub Integration Manager, where we activate the integration to synchronize data from Jama to Verisium Manager. It will take a couple of seconds to synchronize all the requirements. Meanwhile, we return to Verisium Manager, wait for a few seconds, and refresh it to see the synchronized data.

Once refreshed, the requirements from JAMA are synchronized as sections and subsections in Verisium Manager, preserving the same structure and details as defined in Jama. For example, the Bluetooth SoC requirement includes details such as severity, acceptance criteria, and status, identical to what is defined in Jama. Along with these, additional details such as the entity ID of the Jama requirement and a link to that requirement are also available. These details enable the verification engineer to trace the Jama requirement associated with a section, and the link allows navigation to the specific requirement.

With OpsHub Integration Manager, traceability between the two systems is achieved. Now, let’s assume the power consumption verification requirement is assigned to a verification engineer. The engineer updates the status of this section to “In Progress.” While working on the requirement, the engineer determines that verification can be performed based on different modes of Bluetooth, such as idle and active modes. Consequently, the engineer further breaks down this section into subsections: one for active mode with an “In Progress” status and another for idle mode, also with an “In Progress” status.

The verification engineer has now defined these subsections. Here, we observe that requirements updated by the sync tool have a flag raised on the icon label, whereas those created or updated by the verification engineer do not. This flag helps the engineer identify which requirements are updated by the sync tool. If the engineer approves these changes, the flag can be cleared using the “Clear All Flags” option in the UI. After clearing the flags, we observe that they disappear, but any subsequent updates made by the sync tool will raise the flag again. This allows the engineer to track the updated entities easily.

Changes made in Verisium Manager are also reflected in Jama. By refreshing Jama, we can see the latest changes, including subsections created in Verisium Manager, now available as sub-requirements in Jama with the same details. For example, the status update performed in Verisium Manager is also reflected in Jama.

If the product manager updates the description of the active mode requirement, such as adding “low power consumption,” and saves it, the change will also be reflected in Verisium Manager. Refreshing the Verisium Manager will show the updated description in the active mode subsection. This ensures that any changes made by the product team are available to the verification team.

The verification engineer, having started work on this subsection, can define tasks related to it. For example, a task related to the active mode section could involve validating current and voltage levels.

Similarly, for the idle mode, the test case could be low-power state validation. Similarly, for the frequency band verification, the engineer has defined two different test cases: one could be 1.6 GHz frequency validation, and another could be 2.1 GHz frequency validation.

For the purpose of this demo, we assume that the verification engineer has already run the regression, and the golden regression results are available in the metrics. The engineer will now associate the relevant metrics with the corresponding metric ports. Once all the metric ports are associated with the relevant metrics of the golden regression, we notice that the details of the verification metrics are not available at the metric port level because, in Verisium Manager, the regression results have not persisted in the database.

To address this, we will run a script to copy the results from the verification metrics to the metric ports in Verisium Manager. After running the script, we refresh Verisium Manager and observe that the verification results are now copied to each metric port level. These results will also get synchronized to Jama. Additionally, at the Verisium Manager side, the results are rolled up at the sections and subsections level, and the same rolled-up results are also available in Jama at the requirement level.

Next, we go to Jama to view the latest changes from Verisium Manager. After refreshing JAMA, we can see that all the test cases defined in Verisium Manager are now also available in JAMA, along with the verification metrics from Verisium Manager. The rolled-up results are displayed at the requirement level, and we can see the cumulative results as well.

If the product manager, based on the requirement results related to the verification metrics, decides that a requirement cannot be passed because it lacks any passed runs, they can change the requirement status to “Draft.” This will prompt the verification engineer to rerun the regression for the sub-requirement. Conversely, if the product manager deems the requirement acceptable based on the verification metrics, they can update the status to “Published,” allowing the verification for this requirement to be closed.

These updated changes will also be reflected in Verisium Manager. We then revisit Verisium Manager to confirm the latest changes. Upon refreshing Verisium Manager, we observe that the product manager’s decision to reject a requirement and set its status to “Draft” is now reflected in Verisium Manager. Similarly, for the idle mode, the status has been updated to “Published,” indicating it was accepted by the product manager. These changes from the product manager are now available to the verification team.

This demonstrates how synchronization between the verification tool and the requirement tool can be performed seamlessly via OpsHub Integration Manager.

Thanks for watching the demo.

ServiceNow – Jira Service Management (JSM) and Jira Software Integration

In the software project delivery lifecycle, understanding customer requirements on time is paramount in ensuring the accurate delivery of solutions and support. Using disparate ITSM tools can pose challenges like loss of relevant information and delayed responses, impacting clients and businesses. The integration of ServiceNow with Jira Service Management (JSM) and Jira Software using OpsHub Integration Manager (OIM) seamlessly synchronizes tickets to easily track, manage and resolve requests without any delay thereby increasing cross-company and cross-team collaboration.

Video Transcript

In this demo, we showcase cross-team and cross-company collaboration for resolving customer tickets. Alpha, the vendor company, uses ServiceNow as its ticketing tool, while Beta, the service provider company, uses Jira Service Management (JSM) and Jira Software as its ticketing and development tools, respectively. Alpha has outsourced its customer service operations to Beta.

The process begins in ServiceNow, where the vendor company creates an incident ticket on behalf of a customer, adding details such as a short description, status, and other relevant information. The ticket is assigned to the Database Atlanta team and submitted. Another incident ticket is then created and assigned to the Database San Diego team, which belongs to the Beta service provider company.

In this demo, the requirement is to synchronize only the incident tickets assigned to the Database San Diego team. OpsHub Integration Manager (OIM) leverages criteria-based synchronization to ensure that only the relevant incident ticket is synced from ServiceNow to JSM. This near real-time synchronization prevents duplicate tickets across different tools, streamlining collaboration between the two companies.

In JSM, the support team refreshes the page to view the synchronized incident ticket, complete with details such as status, description (with inline images), and the remote ID of the ServiceNow incident. The reporter name is also visible, ensuring that all communication is directed to the correct person. After reviewing the incident, the support team adds a comment, which bidirectionally syncs back to ServiceNow.

The vendor company in ServiceNow opens the incident to check its progress and sees the remote ID of the JSM ticket along with the recently added comment. This provides end-to-end visibility into the incident’s resolution process. Based on the nature of the incident, the support team in JSM decides to involve the engineering team, which uses Jira Software. A problem ticket associated with the incident is created in JSM.

The problem ticket is synchronized to the Jira Software development project for further action. In Jira Software, the engineering team refreshes the page to view the problem ticket, complete with all synchronized details, including the remote ID and remote link of the JSM problem ticket. Similarly, in JSM, the problem ticket reflects the remote ID and link of the Jira Software ticket.

Upon completing the work, the engineering team in Jira Software adds a comment for the support team and updates the status of the problem ticket to “Approved.” These updates automatically sync back to JSM, enabling seamless collaboration across teams. In JSM, the support team sees the updated status and comment, reflecting the completion of the problem ticket.

The support team then navigates to the incident ticket, adds a comment informing the vendor company of the resolution, and updates the status to “Resolved.” They also add close notes indicating the completion of work. Back in ServiceNow, the vendor company views the synchronized status, close notes, and comments from JSM. Satisfied with the resolution, the vendor company marks the incident as “Closed,” signaling that no further assistance is needed.

The support team in JSM refreshes the page to view the updated status, which now reflects “Closed.” Following this, they close the problem ticket, and this status change is synchronized back to the Jira Software development project, where the corresponding problem ticket is also marked as closed.

This completes the demo. Thank you for watching!

OpsHub Connector SDK: Build Custom Integrations with Ease

Businesses limited by restricted integration capabilities or incompatible systems fail to innovate faster due to increased complexity, multiple tools and fragmented data. To unlock the full potential of innovation at scale, it is crucial for data, tools, and applications to work in seamless harmony. That’s why we have launched the OpsHub Connector SDK. This API-managed solution automatically transforms your data to derive maximum business value, while ensuring complete traceability and compliance effortlessly. Find out more about OpsHub Connector SDK from this video.

Video Transcript

We live in times of rapid innovation. Being efficient is simply not enough. To stay ahead, you need to innovate faster than your competition. But increased complexity, multiple tools and fragmented data can be huge deterrent to the pace of innovation. Innovation is key, but it can be challenging when your data tools and applications don’t work together effectively. This leads to poor collaboration, siloed data, compromised decision making, and slower release cycles.

That’s why we introduced OpsHub Connector SDK. It’s a purpose-built solution by OpsHub that gives enterprises the freedom to seamlessly integrate any system or application in their own unique way. This powerful SDK is an API managed platform with a range of features.

OpsHub Connector SDK goes beyond simple integration. It automatically manipulates and transforms your data to derive maximum business value while ensuring complete traceability and compliance effortlessly. It also provides reliable assistance for failure recovery, ensuring uninterrupted business continuity. But that’s not all.

With OpsHub Connector SDK, you can convert, sync, and migrate data hassle free. It allows you to move and synchronize your valuable information seamlessly. Additionally, you can collaborate like never before with interactive features such as comments, attachments, relationships, and inline content synchronizations.

With OpsHub’s Connector SDK, you’re no longer limited by incompatible systems or restricted integration capabilities. You can now unlock seamless integration, scale, innovation and drive maximum business value.

Azure DevOps Migration Tool for VSTS Migration

OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) is a tool used to migrate Azure DevOps projects across organizations and environments with zero downtime. OM4ADO simplifies consolidation efforts across various Azure DevOps organizations, eliminating challenges such as high maintenance costs, reduced productivity, and insufficient reporting. It seamlessly migrates work items, test entities and more enhancing business agility. Developed in collaboration with Microsoft, OM4ADO helps in comprehensive transfer of data with full context within the Microsoft landscape whether it is a TFS to Azure DevOps (VSTS) migration or an Azure DevOps to Azure DevOps migration or any other combination of the two instances. OpsHub Migrator for Microsoft Azure DevOps(OM4ADO) also allows you to efficiently bulk edit work items, transfer data between organizations and collections. The delta sync feature enables incremental Azure DevOps migration by synchronizing only changes between source and target, allowing uninterrupted use of the source system during validation. Watch this video to learn how OM4ADO migrates data from VSTS to VSTS hassle-free!

Video Transcript

In this video, we will show how OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) migrates data from ADO Cloud to ADO Cloud. Here, we have the ADO source instance on the left and the ADIO target instance on the right. Currently, the target instance is empty. OM4ADO will seamlessly migrate the project from the source to the target instance with zero downtime and no data loss. Here, you can see, we have created a source instance by the name, “OpsHubDemoMigration” and several projects under this organization. You can find more information regarding the source incidents from the Organization settings option.

To create a project in cloud-to-cloud migrations, we first need to create a process template. OM4ADO will support the migration of all process templates. The “Web Development Project” is created under this custom process template, “AgileInherited”. Based on these process templates, we will create the projects in the target. Let’s go back to the web development project, which we will migrate from source to target. By clicking on the Project, you can view details added under the same as the description and members associated with it under project settings. In the Team section, you can view the list of teams created. You can create as many teams as you need. You can also assign members to the teams. This, too, can be customized as per your requirement.

Under the Project configuration option, we have created a hierarchy of iterations. Under Iterations, we have created several sprints, and under this sprint, we have created a child. Under the Areas configuration, we can see multiple parent-child hierarchies created. You can click on the Team configuration option to view iterations and areas.

Now let’s take a look at the project configurations. Under the Wiki section, we can see two kinds of options, Project wiki and Code wikis. Under the project wiki, we have created the “Web-Development wiki”. We have configured the web-development wiki with different configurations like meta links, hyperlinks, a table which includes the link reference and user mention, and inline image and screenshot. Let’s take a quick look at the Code wikis.

Moving to the work items to be migrated, we can see a list of work items which have been created by different teams. These are the work item types. OM4ADO will migrate all the data under the work items like the title, description in rich text formatting, inline image, links, attachments etc. In near to real-time, under Boards, we can see the Web Development Board and the UI Dev Board have been configured with settings related to boards like custom stream lanes, color-coded card rules and columns.

These other advanced settings in both, OM4ADO will migrate boards with all the configured settings from source to target. Under Sprints, we can see the capacity assigned to members of different teams. Under the Backend Dev team, all four members have been assigned per day capacity. Under the Repository option, we have created two repositories, pointing to the web development project with the name, Web Development and Backend Data. As of now, we will migrate only the Web Development repository to target. Here is the data regarding this web development repository.

Navigating to commits, the information regarding the commits will be reflected in this Commit tab. Under the Branches tab, you can see two branches that have been created. Under the web development repository, you can create custom branches as per requirement. OpsHub will migrate all repositories along with branches to the target. Under Pull Request, you can view information regarding the same.

We have also created a CI / CD pipeline in the source by the name Web Development CI under the Web Development project. By clicking on the edit button, you can see the information related to the Web Development CI pipeline like the name agent specification, agent job, etc. We can also create a custom variable related to the pipeline. Information regarding triggers is available under the Trigger section. You can customise the schedule trigger as per need. OM4ADO’s migration will migrate all the data from source to target without any loss of context or downtime with full traceability. This completes part one of the demo where we showed all the information in the source system which will migrate to the target system using OpsHub Migrator for Microsoft Azure DevOps.

OM4ADO migrates data in 5 simple steps on the OM4ADO homepage. The first step is to provide the source end point and destination endpoint details. In the second step, you need to provide the migration details. Here, you can select the boxes, the data for which you want to migrate. In the third step, you need to select the projects which you want to migrate from source to target. Here, we will select the Web development project which was created in the source as shown in part one of the demo. You can select multiple projects at a time but make sure to have the same project name and template at both endpoints.

In the fourth step, you need to provide users for mapping. OM4ADO will map the users automatically where the display names are the same between the two systems. You can map the default user in the source with any user in the destination as per your project requirement. By clicking Next, you will navigate to the fifth step to view the migration validation summary and start the migration. The OM4ADO tool will validate the difference between the source and target process templates.

In the migration summary, we can see the project web development has been found in the target, and therefore, we can successfully migrate the data. Once the validation is complete, we will click on finish and the tool will automatically create the configuration. The configuration may take some time. Once the configuration is complete, we will click on Yes on the pop up to begin the migration.

The migration for meta entities is done, and therefore, the status is reflected as completed. The work items have started to migrate from source to target. You can see the status is running and the number of work items which have migrated successfully. The entire migration may take a few minutes. Finally, we can see the migration process has been completed in all the stages.

Now, let’s move to the target instance to verify the migrated data. With the source instance, we can see the web development project created in the source has migrated to the target. Let’s see if the custom process template created in the source has migrated to target. In the Organization setting under Process, we can see the Agile inherited process template in the source and target. The web development project under the custom process template has also migrated to target. We saw the recently migrated web development project.

Now, let’s check if all the details added under it have also been successfully migrated. We can see the exact description has migrated to target and so have the members assigned to the project. Under the wiki section, we can see both the wikis created in source have migrated to target.

The Web development Wiki created under the Project Wiki is successfully reflected in the target with the same details as the source. Here, we can see the migrated meta links, tables with link reference and user mention as well as the inline image, and screenshot. Similarly, we can see the code wiki has migrated from source to target with all its details.

Navigating to the work items which have migrated, the list of work items with the respective teams is available in the target. All the formatting and additions made to the work items in the source including the title, description in rich text formatting like bold and italics, inline image link, an attachment has migrated successfully.

Under Boards, we can see the UI Development Board with configured settings like custom stream lanes, color-coded card rules and columns have migrated from sourced to target under sprints. The capacity assigned to the backend dev team in the source is successfully reflected here in the target under the repository section. The web development repository has migrated with all the data added under it.

The information regarding the comments is also visible in the target. All the branches created in the source have also migrated successfully navigating to pipelines. The web development CI pipeline created in the source has migrated to target and so has all the configured information related to it like the name, agent specification, agent job, etc. The custom variables added to the pipeline in the source are also visible in the target. The information regarding triggers has also migrated to the target from the source.

The advanced configurations which have migrated from source to target are also visible under the Options tab under Project Settings in the Team section. The list of teams created in the source are visible now in the target post the migration under the team configuration option, we can see the migrated hierarchy of iterations and the area.

This completes the migration from Azure DevOps Services to Services using OpsHub Migrator for Microsoft Azure DevOps. OM4ADO also provides a flexible cutover by allowing users to sync additional delta to target after the migration is complete.

Thank you for watching this video.

Jira – GitHub Migration & Integration

Managing data from disparate sources requires strong collaboration and prompt communication between teams. Without this, organizations end up with inaccurate or outdated data and duplication of data. Migrating and integrating Jira and GitHub allows cross-functional departments to streamline their workflows and improve teamwork. In this video, watch a no-downtime, high-fidelity migration from Jira to GitHub with full historical context and seamless bidirectional integration between the two systems synchronizing data in near to real-time.

Video Transcript

In this demo, we will start by migrating the 5 stories displayed on the screen from Jira to GitHub. Currently, no open issues are visible in GitHub. The OpsHub admin has started the migration in the background, and we will see all 5 stories migrate from Jira to GitHub without any downtime. Let’s refresh the page to see if the migration in progress is successful. We can see that the stories have started to appear in GitHub. The comments associated with the stories are also getting migrated. All 5 stories have successfully migrated to GitHub as issues.

The OpsHub admin keeps the migration running in the background to sync all the updates. Once, all the work items are migrated, the developer opens them to check if all the details have synchronized successfully or not. All details including the heading, labels, and descriptions with the rich text field like bullets, bold, date and table have synchronized from Jira to GitHub.

In this demo, we have made customized configurations to show the Remote ID field in GitHub for Jira stories since GitHub does not have a custom field option to choose the Remote ID. In Jira, we can see the Remote ID and link of the GitHub issues. By clicking on the links, you can access the Jira story from GitHub and the GitHub issue from Jira. The comments under the Jira stories are also visible in the GitHub issue with the RTF formatting. This completes the migration from Jira to GitHub.

Now, let us create an issue at GitHub and synchronize the information to Jira. The developer in GitHub adds a new issue, adds a title and description in RTF. All details along with the label added in GitHub will in near to real-time synchronize to Jira. Navigating to Jira, the engineer refreshes the page to view the issue from GitHub which has synchronized to Jira as a story.

All details, including the description in bold and bullet and the label have successfully synced. Here, we can see the Remote Link and Remote ID of the GitHub issue. Continuing in Jira, the engineer adds a comment for the developer in GitHub. These two, with all its formatting will bidirectionally synchronize back to GitHub. Back in GitHub we can see that the comment from Jira is visible here. The developer now adds a response for the engineer in Jira. This comment too will sync back in near to real-time. Refreshing the page in Jira, the comment added in GitHub is visible here.

Going back to GitHub, the developer changes the status of the issue to closed, indicating completion of the work. One last time, in Jira, the engineer refreshes the page of the story to find the status has synced from GitHub, and therefore, the integration between Jira and GitHub reflects “done”.

That completes the demo. Thank you for watching.

IBM Rational DOORS and Jira Integration

Poor traceability and siloed teamwork in the ALM (Application Lifecycle Management) environment can result in a lack of visibility, quality issues, and delivery delays. IBM Rational DOORS and Jira integration addresses these challenges by providing a comprehensive solution for effective requirements management. Get complete traceability and a unified project view, improving decision-making and speeding time-to-market. This integration ensures development teams access requirement changes without switching tools, enabling faster implementation. Similarly, bugs in Jira can be traced back to DOORS requirements, reducing errors.

The IBM Rational DOORS and Jira integration, powered by OpsHub Integration Manager (OIM), seamlessly synchronizes rich text, comments, attachments, links, and OLE objects without requiring additional configuration or manual intervention. By ensuring smooth, real-time data exchange, OIM facilitates collaboration across teams, eliminating manual effort and ensuring 100% data accuracy.

OIM’s bidirectional synchronization supports seamless cross-functional collaboration, enabling digital continuity and reinforcing the digital thread throughout your product lifecycle.

Video Transcript

The business analyst in IBM Rational DOORS starts by creating a requirement of type Heading, under the requirement as a title under Description with a Rich Text field. DOORS will automatically synchronize rich text formatting (RTF) like bullet points, bold, underline, italics, subscript, superscript, and others. The business analyst here also adds an Excel sheet under the section Object Text. Once saved, all details, including the description in RTF and the Excel sheet, will automatically synchronize to Jira.

Navigating to Jira, we can see the requirement has synchronized as a task along with all its details. The description with the rich text formatting and the associated excel sheet have saved. The excel is also available as an attachment. Here in Jira, we can view the remote link and remote ID of the DOORS requirement. The engineer in Jira now changes the status of the task to In Progress and adds a comment for the business analyst in DOORS. Both the status change and the comment will bidirectionally synchronize to DOORS.

Back in DOORS, we can see the status has synced and therefore reflects “In Progress”. Under the Discussion section, we can see the comment added in Jira is also visible. Continuing in DOORS, the business analyst inserts a picture object in a new requirement of type Heading, accesses Title and Description under it, and saves it. Once the picture requirement is saved, the business analyst creates a new requirement of type Feature, associating it with the first requirement of type Heading as a child. Let’s see if this parent-child relation created in DOORS is synced and preserved in Jira.

Back in Jira, we can see the requirement of type Feature has synced as a subtask. We can see the subtask is associated with the task. By navigating to the task, we can find the parent-child relationship preserved here, which was created in DOORS. The image that was added in DOORS has also synchronized. We can find the image as an attachment and also in the description field in Jira.

The engineer in Jira now changes the status of the task and the subtask to “Done”, marking the completion of the work. Both the status changes made in Jira will, in near real-time, sync back to DOORS. In DOORS, first navigating to the parent requirement, we can see the status has synced from Jira and therefore reflects “Done”. Now navigating to the subtask, here too, we can see that the status has synchronized successfully and therefore reflects “Done”.

That completes the demo. Thank you for watching.

ServiceNow – Salesforce Integration

Are you struggling to handle customer interactions efficiently? Learn how integrating Salesforce and ServiceNow CRM platforms can provide you with complete visibility of customer issues and enable quicker resolutions. With a seamless flow of information facilitated by a bidirectional integration using OpsHub Integration Manager (OIM), teams can leverage real-time data to enhance their decision-making capabilities. Improve your team’s collaboration and streamline daily operations by watching this video on Salesforce and ServiceNow integration. 

Video Transcript

This is an integration between two CRM systems, Salesforce and ServiceNow. The support engineer starts by creating an incident in ServiceNow, adds a short and long description, and submits it. This incident will synchronize to Salesforce as a case. In Salesforce, let’s refresh the page to see if the sync is successful. The incident created in ServiceNow has synced to Salesforce as a case. We can see the short and long descriptions reflecting here, along with the Remote Link and Remote ID for the ServiceNow incident.

The sales engineer in Salesforce now changes the status of the case from new to working and also changes the case origin. All updates made to the case in Salesforce will reflect on the incident created in ServiceNow. Navigating to ServiceNow, the status of the incident has synced and therefore has changed to active. Similar to the remote ID and entity links we saw in Salesforce for the ServiceNow incident, here in ServiceNow, we can see the Remote ID and Remote Entity Link for the Salesforce case.

The support engineer now adds a comment notifying the sales engineer in Salesforce of the progress of the work. The comment will sync back to Salesforce in near-to-real time. In the meantime, the support engineer adds an attachment in ServiceNow. This, too, will sync back to Salesforce. Refreshing the page in Salesforce, we can see the comment has synchronized and so has the attachment.

In Salesforce, the sales engineer adds a private comment as a response to the support engineer in ServiceNow and also changes the priority from low to high. In this demo, priority in Salesforce is mapped with severity in ServiceNow. Therefore, we will see the severity updated because of the priority change in Salesforce. Refreshing the page in ServiceNow, we can see the comment has synced and the severity has changed to high.

So far, we saw how an incident created in ServiceNow seamlessly synchronizes to Salesforce with all the comments and attachments. Now, in Salesforce, the sales engineer creates an enhancement, which will also bidirectionally sync back to ServiceNow; gives it a title and description and saves it. The enhancement request is created in Salesforce. Now, let’s check in ServiceNow if the same enhancement has synchronized. The enhancement request has synchronized to ServiceNow. All details, including the Remote ID and Remote Link of the Salesforce enhancement request, are available in the ServiceNow enhancement request.

The support engineer in ServiceNow starts work on the enhancement request, inserts an attachment, changes the severity to high, and adds a public comment. Navigating to Salesforce, the Remote ID and Remote Link for the ServiceNow enhancement request are visible here. So are the recently synchronized priority, attachment, and comment as type – note.

In Salesforce, the sales engineer changes the status of the enhancement request from new to delivered, notifying the support engineer in ServiceNow of the completion of the work. We can see the status has synced from Salesforce to ServiceNow. Continuing in ServiceNow, the support engineer navigates to the incident, which was created earlier in the demo, and changes the status to resolved. One last time, navigating to the case in Salesforce, we can see the status has updated due to the change made in ServiceNow and therefore reflects done.

Azure DevOps – Jira Integration

In many organizations, an agile ALM environment is a key driver of modernization. Cross-functional teams working with disconnected tools and delayed communication can slow down this transformation. Integrating best-of-breed tools such as Azure DevOps and Jira using OpsHub Integration Manager (OIM) ensures there is no scope for miscommunication between the development and project management teams and they can work faster towards an agile, innovation-first ecosystem. Watch this video to find out more!

Video Transcript

Change-driven businesses realize the importance of an agile ALM environment. However, staying competitive in today’s innovation economy is challenging when teams struggle with disconnected tools and hampered communication. Integrating Azure DevOps (ADO) with Jira bridges this gap, enabling digital teams to gain real-time visibility across the software delivery value stream, collaborate without communication gaps, and deliver seamless customer experiences.

This integration empowers development and project management teams to work together more effectively toward a truly agile, innovation-first ecosystem.

In Jira, the product team starts by creating an epic, adding details such as the name, summary, and description, and clicking “create.” The epic automatically synchronizes to ADO with all its details. Navigating to Azure DevOps, we can see the epic and its details reflecting there.

The product team in Jira adds a comment and changes the priority from low to highest. These changes sync back to ADO, where the priority updates to 1, signifying the highest level, and the comment appears as well. The engineering team starts work on the epic, adds a comment in ADO, and this bi-directionally synchronizes to Jira.

The engineering team in ADO creates a requirement, filling in the title, description, and an inline image. All details, including attachments, bi-directionally sync back to Jira. The requirement is also linked to the original epic created in Jira.

Returning to Jira, the requirement created in ADO appears with all details, including the inline image as an attachment. The remote entity ID and remote entity link are visible in Jira, allowing users to navigate directly to the corresponding requirement in ADO. The link between the epic and the requirement is also preserved in Jira.

The engineering team adds a comment to the ADO requirement to notify the Jira product team. This comment syncs in near-real time to Jira, where the product team responds with a comment, which in turn syncs back to ADO. Similarly, in ADO, the Jira requirement’s remote ID and link are visible, ensuring traceability.

The engineering team then updates the status of the ADO requirement to mark it as complete. In Jira, the requirement’s status updates automatically to reflect the same. Finally, the product team changes the epic status in Jira from In Progress to Done, and this status seamlessly syncs back to ADO, completing the work.

How to Integrate IBM Rational DOORS Next Generation and Azure DevOps

Experience seamless integration & eliminate data silos with OIM

Video Transcript

Experience seamless integration & eliminate data silos with OIM

Entity Project and Issue Type Movement Feature

Experience seamless integration & eliminate data silos with OIM

Video Transcript

Experience seamless integration & eliminate data silos with OIM

Verisium Manager (Formerly known as Cadence vManager) and Jama Connect Integration

Experience seamless integration & eliminate data silos with OIM

Video Transcript

Experience seamless integration & eliminate data silos with OIM

ServiceNow – Jira Service Management (JSM) and Jira Software Integration

Experience seamless integration & eliminate data silos with OIM

Video Transcript

Experience seamless integration & eliminate data silos with OIM

OpsHub Connector SDK: Build Custom Integrations with Ease

Experience seamless integration & eliminate data silos with OIM

Video Transcript

Experience seamless integration & eliminate data silos with OIM

Azure DevOps Migration Tool for VSTS Migration

Experience scalable, non-disruptive migration with OMM

Video Transcript

Experience scalable, non-disruptive migration with OMM

Jira – GitHub Migration & Integration

Experience scalable, non-disruptive migration with OMM

Video Transcript

Experience scalable, non-disruptive migration with OMM

IBM Rational DOORS and Jira Integration

Experience seamless integration & eliminate data silos with OIM

Video Transcript

Experience seamless integration & eliminate data silos with OIM

ServiceNow – Salesforce Integration

Experience seamless integration & eliminate data silos with OIM

Video Transcript

Experience seamless integration & eliminate data silos with OIM

Azure DevOps – Jira Integration

Experience seamless integration & eliminate data silos with OIM

Video Transcript

Experience seamless integration & eliminate data silos with OIM