our bots that let you talk with GitHub from Slack). Xatkit supports a number of platforms (and you can build your own!) so the next step is to declare what combinations of platforms your bot is going to be using (either calling actions on the platform or getting events from it). getting the user name and using it to answer her in a more personal way later on in the bot workflow). In a similar fashion, you can also define mapping entities and parameters to collect relevant data from the user utterance during the matching process (to be used later on in the response, e.g.
Java chatbot api how to#
We can easily create the intents the bot should recognize (in this example, the greetings and how the user is feeling right now) and the training sentences to be used to teach the bot how to understand them (these sentences will be used, for instance, when configuring the bot to use DialogFlow as Intent Recognition Provider).
Java chatbot api full#
You can find the full source bot code here, in the following I’ll just focus on a few core parts. We’ll be adding more documentation on the new Fluent Interface / DSL constructs soon but let me present to you the key ones in this GreetingsBot example, a simple bot that just says replies when it detects you’re greeting it. We have now released a new version of Xatkit and its runtime engine so that you can start using this new syntax in the creation of your bots. So, we are basically combining the benefits of having a specific chatbot DSL with the power of a general-purpose language. Use the full power of the Java language (and all the libraries) to create complex bots (if needed).Īll this while keeping well-defined and high-level semantics provided by our internal DSL / fluent interface.Benefit from all existing Java tools when creating, debugging and testing bots.No need to use any specific tool to build Xatkit bots, any Java IDE will do.
Therefore, we decided to keep the state machine semantics but change the language syntax by moving from an External DSL to an Internal DSL. Most of these issues had nothing to do with the semantics of the language but with the syntax and infrastructure. Dependency management was also a nightmare because of the multiple layers that needed to be configured. For instance, the execution language needed to integrate reusable functions/methods to support the complex bots we are working on. This DSL was definitely an improvement over our first attempt at creating a chatbot DSL, but we quickly noticed some issues, nice-to-have features, or cumbersome things we still had to deal with. Some time ago we explained our decision to move to a DSL (Domain-Specific Language) based on state machine semantics to help you create more powerful bots. At Xatkit, we continue our quest to find the optimal language for bot and chatbot development.
0 kommentar(er)
