The Seamless integration workbench – a primer

Over the past few months, we’ve dropped a few hints about the Seamless integration workbench. In this post we wanted to share some more details about the workbench.

Integration Workbench

What’s it good for?

The workbench is all about setting up an integration configuration. An integration configuration describes everything the core Seamless service needs to sync data between different systems. Within the workbench, a user can configure all the variables that make up an integration.

  • Specify the connector plugins that need to be used for this integration
  • Specify any properties the plugins require in order to process data (e.g. connection details for the systems being synced)
  • Specify where data in transit will be hosted (a service bus, a database, a local directory, etc.) and when it will be expired
  • Specify the data queries to retrieve data from the source system
  • Specify the data transforms required before posting data into the target system
  • Specify the timing of data sync from source to target and vice-versa


How does it work?

All aspects of an integration are ultimately saved into an XML file. These files can be loaded into the workbench (to continue working on a previous integration) and saved from the workbench (for subsequent deployment into Seamless).

The workbench can also run the integration locally (i.e. on the local machine). This is useful for troubleshooting and debugging integrations before they’re deployed into the cloud. Integrations are run by clicking play and all logging data is provided to the user for analysis.

What can it not do?

The workbench can not do the deployment of the config file to a live Seamless service. This was kept out of the workbench to enable separation of design and deployment.

The workbench can not run the integration on an ongoing basis. Options for running locally are limited to a handful of iteration cycles. In practice, you couldn’t use the workbench to run Seamless as a locally hosted integration service.

Who gets to use the workbench?

The workbench is provided to all Seamless delivery partners so that they can work on developing integrations. The workbench is also provided to clients who want to specify and build their own integrations – often as part of a broader software project.

Does every Seamless user need to use the workbench?

No. Only delivery partners and users who are specifying their own integrations need to use the workbench. Where you’re working with a delivery partner or directly with Recursyv, you won’t have any use for it.

How did it come to be called the workbench?

You’d think the term “workbench” was a pretty straightforward moniker for this piece of kit. In the early days, our engineering team creatively labelled this the “Seamless Integration Builder” – descriptive but not particularly exciting. After many, many minutes of discussing prospective names for it, David and Jon moved onto a more pressing conversation about why cycling is a better sport than running. In conversation some months later, one of our clients referred to the tooling as “the workbench” and the name has stuck. Also, the client prefers cycling.

Walking the walk

Walk the walkHow do you tell the difference between “walking the walk” and “talking the talk”? We’re delighted whenever we can meet a less typical client requirement that also enables us to demonstrate different aspects of the Seamless offering.

In this post, we’ve chosen to share the stories of 3 recent implementations that demonstrate different aspects of how Seamless offers flexibility when delivering application integration.

We’re not looking to integrate Microsoft apps

You’ll not be surprised to learn we’re big advocates of Microsoft, but they’re not the only app vendor out there. In a recent implementation, client is using Seamless to keep a pair of helpdesks in sync, one of which runs on BMC Remedy and the other on ManageEngine.

This implementation demonstrates how we can use Microsoft Azure to enable digital transformation outside of the Microsoft realm. Remedy and ManageEngine are both commercial applications from different vendors. We’re using Seamless, running in Azure, to keep them in sync.

We’re not just connecting two applications together

We have a client rolling out Dynamics 365 into an existing architecture which contains an Azure service bus for transporting data across the enterprise. Seamless has been setup to sync data to and from the service bus.

This demonstrates how the componentised nature of Seamless allows us to deploy into more complex contexts than simply syncing between System A & System B. In order to sync to/from a data bus, we only use half of a typical implementation. In turn, this means that we needed to setup some Seamless’ internal data transfer objects differently. The configurability of Seamless meant we were able to achieve this within a few days of joining the project team.

In this instance, we’ve deployed into the client’s Azure estate rather than our own. This enables the client to take advantage of their own existing security infrastructure within Azure, as well as their pre-existing preferential commercial terms from Microsoft.

We’d like to use some of our technical skills

Syncing contacts and accounts between Dynamics and Autotask is bread-and-butter stuff for Seamless, so why is it being mentioned here? In this example, our client, Verdant Services, a consulting and cloud services provider, is configuring their own integration.

Verdant are using the Seamless Integration Workbench to specify data mappings, update transformations and generally take ownership of their integration. As the project progresses, they’re also able to quickly change their integration to move data between various staging and live environments.

This demonstrates the power of the Seamless Integration Workbench. With a few hours training, our client has taken ownership of the integration inside their software delivery project. This enables them to be flexible and respond to the needs of the project as it progresses.