Wednesday, August 31, 2016

questionnaires are the ChatBot equivalent of forms, where user interaction is better served with simple UI elements such as buttons.
A questionnaire is a list of questions of various types that Eva will ask the end user. As a questionnaire is an interactive message it can only be the last in the list of returned messages and there can only be a single interactive message in the list.
To request asking the end user questions, return the following interactive message from any applicative webhook:

The "_type" of the message is always: "QuestionnaireEvent"

"questionnaireAnsweredHook" is an enumeration of the webhook to call when the questions have all been answered. "payload" is an object that will be added to the payload of the "questionnaireAnsweredHook".

"questionnaireAbortedHook" has the same structure of a "questionnaireAnsweredHook". A "questionnaireAbortedHook" will be called if the validation of an open "QuestionMessage" fails three times.
This key is optional.

Send 1 or more questions, of any of the supported types in the list of "questions".
In this example there are 3 questions.
Each question has a "name" which will be the key of the result in the payload to be delivered to the "questionnaireAnsweredHook".

The 1st question in the example is an EmailQuestion.
The open reply will be validated using a built-in regular expression for email addresses.

Eva will then send out an email to the designated address to make sure the submitted email is valid and owned by the end user!

The 2nd question in the example is a multiple choice question, typed "MultiChoiceQuestion" with 3 choices.

The 3rd question in the example is an open question for which you may request a validation regular expression.

As usual, this functionality works across all messaging platforms! Facebook Messenger, Telegram, Kik, Line, Skype etc.

Sunday, August 7, 2016

When a user starts a conversation with your business, you may want to identify her as a customer who already has an account with your business. To help with this, we have created a platform-agnostic secured protocol to link and unlink the messaging end-user identity with your business user identity.

OAuth-style LogIn allows you to invite users to log-in using your existing authentication flow thus to provide a more secure, personalized and relevant experience to users.

To request a Log In return a special message of type LoginOAuthEvent from any applicative webhook.
As this is an interactive message it can only be the last in the list of returned messages and there can only be a single interactive message in the list.

loginSuccessHook - a JSON object with either webhook - an enumeration of an existing webhook, or url

text - any text message - mandatory.

webLoginUrl - a URL to the web login page.

The end user will be presented with a log in request. Once she clicks on it she will be redirected outside the messaging platform and into the a web browser window with the business specific log in process.

The URL webLoginUrl will be extended with a query parameter called redirect_uri.
If the log in is successful, redirect the browser to the redirect_uri specified in your callback to complete the flow, and append a new authorization_code query parameter. Eva will add the contents of authorization_code to the subsequent
applicative webhook calls as a new key called privateId.

Tuesday, June 28, 2016

The Eva BotKit enables building a single AI assisted Bot for providing applicative Travel functionality across all messaging platforms with a bot platform API. BotKit bundles Eva’s Natural Language Understanding and nonlinear Dialog Management features with robust cloud based spelling correction. Furthermore, the Eva API reply is automatically parsed and dialog is handled by Eva. The backend application is only called upon to implement applicative directives, such as ShowBoardingPass or PerformFlightSearch. Applicative integration is done via fully customizable webhooks. Eva automatically reformats your applicative webhook replies to comply with all quirks of the different messaging platforms so you don’t have to integrate separately with each one.

It takes 5 minutes to get your new Bot to answer Hellos on Facebook Messenger, Telegram LINE or Kik!

Integration with all messaging platforms consists of the following steps:

Create a new Bot

Add a Chat Service Integrations

Implement applicative webhooks

The BotKit provides seamless integration with the following platforms:

Facebook Messenger

Telegram

LINE

Kik

WeChat (Beta)

Slack (Beta)

SMS (Beta)

Eva defines many webhook functions for applicative requests that may be queried by the end users. This is usually existing functionality in your backend servers that the developer needs to “wire” to the corresponding webhook post.
Here are some examples:

Perform a Flight Search

Perform a Hotel Search

Show a Boarding Pass

Show an Itinerary

You can simply ignore the applicative webhooks that are non-applicable to your backend. Eva will automatically reply to end users explicitly requesting these services with a “not supported” message.

Sunday, May 1, 2016

Return EvaResult from the applicative callbacks -This version allows returning a custom reply from the applicative callbacks, thus allowing the application to modify the text spoken or displayed by Eva. This allows for new types of integrations, for example - allowing the application to answer questions asked by the user.

Example App - the SDK is now bundled with a simple example app, featuring the different applicative interfaces and different return values.

We've also started using the jitpack.io artifact repository. This allows the developers to setup a specific version in the build.gradle file or use the latest version - and Gradle will handle fetching the needed dependencies.

To use it follow these two steps:

Add justpack.io repository: In your root build.gradle at the end of the allprojects repositories:maven { url "https://jitpack.io" }

To your app build.gradle dependencies add one of the following:compile 'com.github.evature:android:2.1.424'

// or for the latest backwards compatible version:compile 'com.github.evature:android:2.0.+'

// or for the latest and greatest version: compile 'com.github.evature:android:master-SNAPSHOT'

Note this version (2.1.+) is NOT backwards compatible.

However, it should be a very small effort to update the code to compile with the new version.

The non compatible changes include:

App interfaces are are now prefixed with "Eva" (eg. EvaHotelSearch instead of HotelSearch).Since Java does not allow import aliasing, this will eliminate the problem of having similar named classes in the app.

The different fields in the Eva classes are now consistently camel case (as per Java coding standards).

App search interface function parameters are slightly different - instead of passing many parameters to the search function, an "attributes" object is passed which contains different attributes. eg. instead of using the "minStars" parameter use "attributes.minStars".

The app interface functions now return an EvaResult class and are not void functions. Simply return null for the default behaviour.