Cisco recently announced a recommendation for its partners to connect their ITSM tool to the Cisco Technical Assistance Centre (TAC) by Smart Bonding their system. Smart Bonding allows technical support agents to work within their own tools and not have to jump between tools to collaborate on technical support cases.

What Cisco offers out of the box is a set of APIs and instructions that Cisco partners can use to build an integration between their own tool and the Cisco TAC. What is not included is what actually consumes these APIs and ensures that your tickets are in sync at all times.

You read that right, before you gain any of the benefits of Smart Bonding, you will still need to build an integration. Let’s explore what your options are to build the integration and how ONEiO could take this burden away from you.

What do I need to consider?

In their guide, Cisco has outlined three roles required to successfully create the bonding. A project manager to manage timelines, risks and resources. A developer, who can actually understand how to work with the APIs of both your own ITSM tool as well as the Smart Bonding middleware. To supplement the technical understanding, you’ll need to add the incident manager or process owner to help set the requirements for when and how the information between the two systems will be transferred.

Project manager

The project manager’s role is to ensure that your organization has the right resources available to build the integration and has to make sure that the outcomes are delivered on time. This person will need to be capable of understanding the required skill level for each person in the project team. To understand the risks involved in the project, two main concerns arise. Knowing the resource constraints potentially affecting the delivery timelines and a sufficient understanding of what information can be transferred between the systems to mitigate any information security risks.

Developer

The developers involved in the project need to be able to create the mechanisms for pushing information towards Smart Bonding and be able to pull the information from the available APIs. It requires either knowledge of how to use an integration platform, or directly interact with the systems using code. The developers will need an understanding of how the organization’s ITSM system can send out information, or alternatively pull the information from the internal system. Cisco’s Smart Bonding does not send out information in a push manner, hence the developer will need to be able to develop the retrieval mechanism and interval in a way that satisfies the business needs.

Incident manager

The incident manager or process owner is the expert in the project and has full knowledge of the process. They are responsible for guiding the developers to develop a solution that matches the business requirements. Both in terms of what information is needed to be brought back into the organization’s ITSM system and how the ITSM system has been configured in terms of statuses and the process.

In addition to ensuring that the needed roles are filled, the project team will need to be able to determine how and when information is being transferred between the two tools. When setting up Smart Bonding, information needs to be pushed towards Smart Bonding from your ITSM tool and pulled from Smart Bonding towards your ITSM tool.

Pushing tickets to Smart Bonding

When setting up the pushing of tickets towards Smart Bonding, the main question to answer is in what situations this should happen and what triggers the push. This could be an assignment group, a tag or a certain status to name a few options. The incident manager needs to be aware of when in the process a ticket should be pushed and the developer needs to configure the pushing to occur when conditions to do so are met in the ITSM tool.

Pulling tickets from Smart Bonding

As Cisco’s Smart Bonding only makes information available through an API and doesn’t automatically send any information to your ITSM tool, you’re required to develop the methods for how to retrieve this information. Again, the incident manager will need to define the use case in a way that makes sure that this information is readily available depending on your organization’s need. For e.g. do you need to fetch the information multiple times a day, or even within an hour? The developer then needs to be able to develop this capability, either using an integration platform or by writing code to achieve this. Once retrieved, the information must be transformed to the correct format required by your ITSM tool. A key thing to note is also the order in which this information is relayed back into your ITSM tool. Updates to a ticket that arrives in the wrong order can lead to errors when statuses are not changed in the order set up in your tool. Sending comments and attachments in the wrong order can cause confusion among the technical support agents working in the systems.

How can I build the integration?

‍

Use your ITSM tool’s capabilities

Many ITSM tools offer ways to send out messages such as webhooks whenever a change has occurred in a ticket. In ServiceNow, you can build a REST message and attach a business rule to it to trigger an outgoing message whenever the rule is met. What you will need to be able to do is to structure the message to be in the correct format that Cisco’s APIs accept. 

With some configuration work, you can send out information to Cisco. How would you receive or retrieve the information back towards your tool? Cisco’s API allows you to pull data from the Smart Bonding middleware and advises you to do this periodically. Configuring this inside of your ITSM tool is a lot harder, as most tools do not offer this capability or have weak support for ways to transform the messages to the right format.

Write code and have scripts running periodically

To retrieve the information from Cisco’s tool, you can attempt to write scripts to utilize the APIs. The code to retrieve the information can be simple to set up as it only needs to call the API to push and pull information. Transforming the data received can also be a straightforward task. However, lots of challenges can arise from setting up the needed architecture for these scripts to be run periodically. Error handling in cases when the Cisco API or your ITSM tool doesn’t respond, setting up retries to recover from these errors, and finally alerting the right people when it cannot perform its tasks all require a high level of sophistication and expertise from the developer. Ensuring that messages are queued and delivered in the correct order will need an in-depth understanding of message queuing protocols and how to distribute across multiple queues to avoid any build-ups of messages in the queues.

Use an iPaaS

Generally, iPaaS platforms offer a vast toolkit of different ways for developing an integration with a lower need for coding. They, however, often do not come with ready-made workflows to achieve the end result. The same error handling and queuing mechanisms need to be configured in the iPaaS platform as they do not come out of the box in most integration platforms. It will again require an integration developer experienced in developing integrations that can ensure the correct order of message delivery to be able to achieve this in an iPaaS. 

Configure in ONEiO

ONEiO is an Integration Automation Platform built for the needs of enterprise use. The abovementioned error handling, queueing, as well as 24/7 monitoring are built into the platform. There won’t be a need to develop the integration or set up any infrastructure, but simply configure the business logic for what and when information should be transferred. Messages transferred through ONEiO are contained in a conversation, a way for the integration to maintain context whenever statuses change, when additional comments are added, and to always ensure that messages appear in both systems in the correct order. This significantly reduces the time required and the complexity involved in reaching the outcome of a working integration.

What if I decide to buy instead of build?

There’s always the option to buy an integration instead of taking the responsibility for building the integration and setting up the needed infrastructure to continuously run the integration. Your responsibility is then to select the correct vendor for your integration. To be able to make the right choice you should consider the following questions.

How experienced is the integration vendor in developing integrations involving tickets?

Ticket integrations and integrations with ITSM systems are notoriously difficult. The need to maintain the correct order and the velocity at which the information needs to be available in both systems can be a challenge if your chosen vendor only has experience in for example bulk transfer of information in batches. Select a vendor that has proven experience in these integrations and your ITSM tool.

How responsive is the integration vendor to future changes?

Your processes will continue to evolve. You shouldn’t treat the integration as a one-off project, but as an ongoing relationship with your vendor. If they aren’t able to respond and adjust the integration whenever your process is adjusted, your ITSM tool is updated or Cisco’s APIs change, you may end up facing interruptions to your service. Select a vendor who is responsive and who ideally allows your organization to make adjustments as self-service.

Does the technology used by the vendor scale according to your needs?

Depending on your ticket volumes towards Cisco, you should consider whether your vendor can provide you with the needed capacity at all times. With increasing volumes, it can lead to increased costs in terms of the infrastructure required to process all of the integration messages. Remember to check that your vendor can handle spikes in message volumes and scale accordingly. Select a vendor that either offers uncapped capacity or is flexible in scaling the resources and cost so that you are not paying for more than you need.

How much maintenance work is required to keep your integrations running and is monitoring included?

Technical maintenance work is required to keep your integrations running if they are built with code or using an iPaaS. Whether it’s upgrades to the underlying infrastructure or to the tools your vendor is using, it may not be included in the project cost. Monitoring the integrations to ensure they are functioning as expected also comes with an additional price tag. Again, don’t treat this as a one-off project, but as an ongoing service. Select a vendor that ensures a sufficient service level and also will take care of the monitoring of the integration.

How can ONEiO help you to integrate with Cisco Smart Bonding?

ONEiO is an Integration Service Provider with years of experience working with a wide range of ITSM tools. Our promise to our customers is to keep your integrations running at all times and with pricing that is always predictable and transparent. As our SaaS platform is already processing millions of messages per month, we ensure that technology is never the limiting factor. Our integration experts are also there to assist in the configuration of the integration between your ITSM tool and Cisco. 

‍

To set up your Cisco Smart Bonding integration with ONEiO, you will only need an incident manager or process owner. Our implementation includes project management and development work so that you’ll be up and running in no time.

Reach out to us to get your Cisco Smart Bonding set up, or simply book a time to chat with an integration expert below – we'd love to help.

Want to share this with your colleagues?
Download this article as a PDF.