Routing Microsoft LUIS Requests and Bot Framework - Preferably in an Enterprise Reference Application [closed]

Question

My colleagues and I are working on building a very large application using Microsoft bot framework and Microsoft LUIS. Essentially we are trying to create a bot where people from across the organization can message the bot (through slack) and receive pertinent information. Different types of requests pertain to different subject matter domains (sales, marketing, logistics and R&D). How does one chain together multiple LUIS models, entities and sub entities so that that a request does not query every entity before getting to the correct entity?

Right now, if a user asks “How much have we spent year to date on research?” it first queries the sales entity, then marketing entity, then the logistics entity and finally it queries the R&D entity before it gets a response. I’m trying to limit the number of API requests. I currently know of 3 possible solutions that deal with this routing issue and none of them appear to rely on LUIS for routing to the appropriate entity.

Solution 1 involves having the bot give a UI selector corresponding to each domain.

Solution 2 involves hooking up an NLP library to extract the subject from a sentence and then match the subject using a weighted dictionary library.

Solution 3 is involves setting up pure RegEx. This is my least favorite solution for obvious reasons.

A link to an enterprise grade reference application using Microsoft bot framework and Microsoft LUIS would be an ideal answer.

Answer 1

Here are are new set of samples, including some end to end demos like the ContosoFlowers, which should shed some light on how a real BOT project will be structured.

• The samples are task-focused ones, showing specific features of the framework.
• The end-to-end demos will be more aligned to what you are looking, since you will see concepts like dependency injection, the usage of the IScorable capabilities, how to separate components, how to build reusable bot assets and how the project is organized/architected.

Another public bot, is the Azure Bot where you will find some real implementation. An interesting refactoring is also taking place in the addextensibility branch; where you will also be able to see how the architecture is evolving

From the docs:

The AzureBot was created to improve the productivity of any developer, admin, or team working with Azure. It is currently publicly available and you can also follow our Developer Set Up to run it yourself and contribute.

This first implementation focuses on authenticating to the user's Azure subscription, selecting and switching subscriptions, starting and stopping RM-based virtual machines, and listing and starting Azure Automation runbooks.