This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Integrations and Mashups Via the 'Un-API'
One of the core topics at Enterprise Connect 2017 was application programmer interfaces (APIs). In his session, "Communications APIs: What They Are, Why They're Hot," Mark Winther of IDC referenced "the rise of citizen developers."
In a communications context, the term "citizen developers" implies the democratization of communications and how communications can work for the benefit of individual users. It allows us to think in terms of mass customization for communications services. However, when most of us ordinary citizen communicators think about customizing our communications environment, we are either forced to rely on the limitations found in the application settings our communications tools provide or on the far more daunting task of programming using an API.
It seems like we are still a long way from this idea of citizen developers.
Yet, great progress toward that end is being made. I am highly encouraged by the availability of bots in some UC clients and the even greater availability of apps (sometimes called integrations or connectors) in many teaming tools. The major vendors of team workspace tools and their partners have done a lot of the heavy lifting when it comes to integrating, or "mashing up," with other tools that can provide significant value.
At the present time, Slack apparently has approximately 370 app and bot integrations. Cisco Spark has slightly more than 90 integrations, and Microsoft Teams has about 80 "connectors," with potential integration with 1,000 bots via the Microsoft Bot Framework (when they become available -- for some reason, I still can't add bots to my Teams chat channels).
None of these integrations or connectors referenced above, however, deal with call signaling. What this means is that if I want to have some triggers based on inbound or outbound calls, I really don't have any way to launch processes or have actions carried out on my behalf as part of my workflow.
This is why I found the Masergy partnership with Cloudpipes, announced at Enterprise Connect 2017, so interesting. Masergy has opened the kimono, so to speak, by allowing any of the 150 or so apps utilizing the Cloudpipes framework to use triggers based on call signaling (see related No Jitter post, "Opening Up About APIs").
Working on Masergy-Cloudpipes integration is intuitive and easy.
Cloudpipes provides a "process flow" development environment. In Cloudpipes, the applications on the right are called "Channels," and each channel has one or more "Pipes." A pipe is simply a trigger or an action. For example, a Masergy pipe might be a notification indicating that a user has received an inbound call. A salesforce pipe might be an action, such as a lookup, based on the caller ID of an inbound call.
By putting together a meaningful sequence of pipes consisting of triggers and actions, you could create a useful workflow, or pipeline in Cloudpipes parlance, based on the capabilities of the apps shown on the right.
A closer look at a Masergy inbound call pipe, illustrated above on the right, shows that a pipe can carry along with it a number of related variables. I referenced caller ID earlier, but variables such as start time, call duration, call state, and others are available as part of the Masergy pipe, as well. All variable values can be used as part of a trigger event or action.
The workflow, or pipeline, for this particular example goes as follows:
- Initial Triggers: 1) A call comes in, and 2) it gets answered
- Action: Based on the caller ID obtained from Masergy, do a Salesforce lookup to get customer information
- Send a "new call" text message, along with the Salesforce data, to a Slack account
- End the process
Cloudpipes workflows have a testing mechanism that allows the pipeline creator to follow the triggers and actions. See below for a snippet of the pipeline with a Masergy call notification trigger being executed.
One of the interesting possibilities is that apps that don't really integrate together may be able to interoperate in some limited fashion through these mashups. For example, a Masergy notification can cause a Salesforce lookup to occur. Data from Salesforce can then be sent to a Slack channel. Slack has an integration with Cisco Spark, so these Salesforce data can then be pushed from Slack into a Cisco Spark conversation. Hence, although Masergy and Spark don't integrate directly, they can mashup indirectly through this series of triggers and actions that are enabling applications to interface with one another.
Of course, one of the requirements is that the person developing the app (as well as any other potential users of the integration) has an account on all of these different cloud services and would be able to enable the integrations. And sometimes, the account has to be at the right level. For example, the free Spark account does not allow integrations.
We can see the beginnings of a real process illustrated in this short post based on call signaling, but done with no API coding or special development skills required. This example can quickly inspire ideas for what can be done when applications can integrate and pass information between them without any code being written. Cloudpipes has coined the phrase that it is "duct tape for the Internet." And, indeed it appears that applications with these kinds of microservices and micro-integrations will become more and more commonplace. The creation of complex communications workflows by citizen developers is becoming a reality!