Developers interact with Haley through a variety of programming interfaces. Client APIs allow interacting with the Haley service from applications. The Bot API allows implementing Bots to interact with Haley users, services, and devices. The Bot API includes components to interact with databases, the dialog system, machine learning and predictive models, analytics, external web services, and other Bots.
Bot API: https://github.com/vital-ai/haley-bot-api
Client JVM (Groovy/Java) API: https://github.com/vital-ai/haley-client-groovy
The Bot API provides ways to process incoming and generate new messages. Haley provides access to databases, scripts, prediction models and other services via the Bot API, all of which can be used in message handling. The Bot API provides access to the Dialog System to track the state of the dialog in a channel./p>
AIMP provides a standard for defining messages to be exchanged across A.I. systems. AIMP messages may include payload data, such as a weather report message containing the weather data.
The Dialog System is part of the Bot API. The Dialog Systems tracks the state of the dialog with each Haley channel and user. As example, for the message "Send that in an email to John", the Dialog System tracks the history of messages to determine what "that" refers to.
Haley Console is a development tool to run Bots through tests or via interactive command line interface.
The Bot API makes available services including: a query interface to query databases, an interface to execute scripts on external servers (used to access remote webservices), and an interface to get recommendations and predictions from predictive models. Many machine learning algorithms are available for building the predictive models - including those from MLlib on Apache Spark.
Haley messaging occurs on a "channel" with participant users and devices. It's natural to visualize this as a chat stream, similar to Twitter or Slack. However, through the Haley dialog system, the messages exchanged could follow additional structure, such as an exchange of forms with values filled in. Thus, a user interface may provide a very unstructured messaging system or a very structured one, depending on the needs of the application. Many messages are "invisible" such as heartbeat messages providing device status or user presense.
An example of a user interface is in the screenshot to the right. The example displays an unstructured chat, with Haley providing a structured response to the request "show me the weather". The weather report is a "payload" in an AIMP message, providing the next few days weather predictions. This information is displayed in a "weather card" locally. The cards are determined by the "client" -- so different interfaces may display the information contained within an AIMP message differently. As example, for an integrated device like the Amazon Echo, replies are always spoken through the speaker, whereas in a web interface, they can be visually displayed.