Messaging Platform SDK Overview

Messaging Platform SDK (MPSDK) facilitates both agent and consumer interactions on LivePerson’s Messaging Platform (UMS) from Node.js and web applications.

Our goal is to make this a single point of integration with LP Messaging ecosystem, so that all connections to LP Messaging use this SDK.

Capabilities

• Can be used to create any type of application that integrates with LP Messaging Platform.
  • User Interfaces (Agent workspaces, Consumer windows)
  • Bots (singular or stateless / horizontally scaling)
  • Tests (system or E2E)
• Supports all user types
  • Consumer
  • Agent & Agent Manager
• Supports multiple connection protocols
  • Websocket
  • REST API
  • Webhooks
• Object oriented 
  • Instead of navigating a complex api and interpreting raw notifications, objects with functions and events will be presented to the consuming application.
• Connection maintenance is now completely handled by the SDK.
  • customers no longer need to write their own reconnection logic.
  • In the event of connection loss, the SDK will reconnect automatically and execute any requests that were made during the downtime.
  • It will also recreate subscriptions and update conversation objects with any changes the occurred.
• Browser support
  • This is mainly for helping developers write UIs, either consumer or agent. Developers can focus on writing UI specific code, rather than wrestling with the complexities of the API. There are two different ways that the SDK can be used in a browser:
  • A standalone .js is provided to drop into any existing browser based solution. See our example web application for a simple consumer UI.
  • The SDK can also be added as a library and compiled into any existing web app (those using (react or angular for example).

Benefits of Adoption

Elimination of Special Knowledge Requirement

The raw Messaging API is complex and hard to navigate. The SDK greatly simplifies interacting with these APIs by providing a software interface, reducing the knowledge required to make each call down to a bare minimum. It also provides documented classes and method calls, so that the requirements of each call are at hand when needed.

Even if the documentation on the request, response, and notifications were complete, applications still need to write integration code to manage state on the client side. This includes both connection and conversation state.

Authentication and Connection State Management

Establishing and maintaining a connection to Messaging Platform is a complex multi step process, involving calls to at least three services within the liveperson eco system. This includes calls to CSDS, Authentication, and finally establishing and maintaining a websocket connection to UMS. There are also calls that must be made after this in order to keep the authentication and connection alive. While we can share best practices customers wanting to interact directly with the UMS API, we believe it is far better to encapsulate those best practices into an SDK and make the process as simple as possible - changing an imperative process into a declarative one. Applications shouldn’t need to care HOW they connect to UMS, instead they should just be able to tell the sdk to connect and save their focus for writing application specific code.

Conversation State Management

Once the connection to  Messaging Platform has been established, request can be formulated and sent to UMS and in return it will send back responses and notifications that need to be interpreted. These messages contain encoded information on conversations, dialogs, messages, users, skills, and even the brand itself. Knowing the correct way to interpret these messages is difficult even for the developers of UMS, there are plenty of pitfalls and gotchas, and the documentation is very scarce and even non-existent in some cases.

The MPSDK does all of this work for the application, keeping track of conversation states and making appropriate calls to retrieve data when required. It will even automatically hide the concepts of subscriptions and dialogs from the end application by default. The end result is a series of objects with neatly designed functions and events that provide a simple interface to the application. These objects act as a true interface, so that if  Messaging Platform decides to change its protocol (moving from websocket to rest), or add extra requirements, the application merely needs to pull down a new version of the SDK and will not require any of their code to be rewritten.

Writing a web application

You can write a browser based application in one of two ways:

1. Use our pre-compiled stand alone js file. In the event that you just want to drop messaging into an existing web application, you can just make a reference to our precompiled stand alone JS file. See our simple consumer demo page for an example.
2. Compile our library into your webapp. If you are writing a web app that compiles using a tool like webpack, you can include our library in your project as you would any other.