The bot we have created uses DialogFlow as NLU Engine and uses MS BotFramework core as a dialog manager that creates dialogs as steps.
The preview version of Bot Composer looks powerful and intuitive way to create the Dialogs and manage them. But none of the documentation or Ignite Videos give a clear view whether it can be used for other NLU's(for obvious reasons, they wanted to promote LUIS).
So, curious to know if some integrated the composed with other NLU's apart from LUIS. If so, what are the caveats.
Though LUIS provides a builtin way of managing intents in Bot Framework Composer, you can still access external API's like any NLU endpoints you want to use by incorporating an HTTP step into your dialog.
Related
I am currently looking at using Microsoft Web Chat to interact with my existing Node Js application built on MS Bot Framework Core but uses DialogFlow as NLU.
Current implementation: Web Page -> Custom UI Widget -> Connects to Node.js app built on MS Botframework Core -> Queries DialogFlow NLU to identify Intent -> Node.js app constructs the Dialog -> Gives response to user.
Looking at the Web Chat component, I cannot find references using any other NLU except Azure Bot Service. Is it mandatory to use Azure Bot Service/LUIS NLU to integrate with Web Chat?
I have also looked at offline-directline npm module but the last dev on the module is more than 3 years ago.
Firstly, responding with a quick message about using offline-directline, you should feel reasonably comfortable with it. It is a few years old, but seems to stand the test of time with continued use and little in the way of issues that I have heard.
Another option would be to use a 'browser bot'. In this scenario, the bot is contained within the hosting page's html/scripts. So, there is no reliance on using Direct Line. I don't know your whole setup, so this may or may not align with your overall needs and architecture.
As for using Web Chat with something other than the Azure Bot Service, this would be an uphill battle. In theory, this is probably achievable to some degree. The issue is that Web Chat is heavily integrated with the BotFramework-DirectLineJS library. You might be able to cherry pick specific components from Web Chat, replace the Direct Line library with a make of your own, and modify the remaining code to work with your 'service'. But, I'm not certain the effort is worth it. That is something you would have to decide for yourself.
If you do go this direction, you will likely need to configure your 'service' to send messages that conform to the BotFramework schemas when communicating with Web Chat. Even without the dependency on Direct Line for connecting to the service, much of Web Chat is still oriented towards what an incoming message looks like (i.e. a BotFramework Activity) and handling it according to the properties it contains.
To start, here are a few areas you should review in order to correctly configure you service to handle inbound and outbound messages going to and coming from Web Chat:
BotFramework Activity schema
BotFramework Card schema
BotFramework Transcript schema
Web Chat's Activity, Card, Attachments, etc. Types - at present, these are loosely defined. I would expect that to change at some point in the future which may prove to be a changing break in your specific scenario.
This is not exhaustive and would require greater research as there are likely other considerations than the few I've listed above. But, again, this may not be necessary if you decide to utilize offline-directline.
I have a bot in C# working with botbuilder-dotnet using the slack-adapter with my workspace. Now I want to install the slack app in other workspaces.
How can I configure the adapter to work with multiple workspaces? I think it's around this options in the constructor but couldn't find any examples: https://github.com/microsoft/botbuilder-dotnet/blob/497cb6e5192c85a82478aca475f324dd3afde4cf/libraries/Adapters/Microsoft.Bot.Builder.Adapters.Slack/SlackClientWrapper.cs#L214
Currently, the Bot Framework does not support multiple workspaces as of 4/22/21.
You did the right thing by creating a feature request in the GitHub repo. For others who're searching for this issue and would like for it to gain traction, see link tracking the issue:
https://github.com/microsoft/botbuilder-dotnet/issues/5519
The Bot Framework team will look into and assign priority to, should they decide to implement the feature request
I need to build a single Chatbot instance using BotFramework v4 that can handle multiple endpoints, and thus multiple AppID/Secret. I have seen notes online and in BotFramework samples that it is possible to do but I cannot find any specific examples for BotFramework v4.
Can anyone provide a sample on who to handle such scenario. For example, I would need to have endpoints /messages/hr and /messages/payroll, and depending on which endpoint is used the right AppID/Secret is used and specific MainMenuHrDialog or MainMenuPayrollDialog is launched.
In general, is it recommended to handle bots for different domains in the same bot project, or is it better to have separate projects for different domains with a NuGet package shared for common tasks.
So if I understand correctly, your desire to use different appIDs and secrets is gonna require multiple web app instances of similar botframework template code which executes different functions using an extension to their already existing api/messages endpoint(the default chatbot messaging endpoint). I'd recommend setting up a couple of azure web app instances along with a couple of bot channels registrations for connecting channels to your bot logic. Here's a decent resource for that: https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-tutorial-deploy-basic-bot?view=azure-bot-service-4.0&tabs=csharp
Though this doesn't apply directly to your scenario, you might want to check out this sample repo here: https://github.com/microsoft/BotBuilder-Samples/tree/main/samples/typescript_nodejs/16.proactive-messages. It shows you how you could open up those extra endpoints of /api/messages/hr or /api/messages/payroll. Additionally, I'm not sure how necessary the extra appIDs and secrets are for you but if your requirement is to ensure authorization when accessing these endpoints, I'd recommend looking into this prebuilt sample as well: https://github.com/microsoft/BotBuilder-Samples/tree/main/samples/javascript_nodejs/18.bot-authentication. It possesses some info about authentication and how you might differentiate between users using a combination of conversation.activity.id and tokenResponses from AzureAD.
I'm looking at using the Bot Framework (https://docs.botframework.com) is it possible to register a bot programmatically e.g via service? I see there are Azure bots but still don't see a way to register via service?
At the moment you have to manually log into the portal to register the bot and obtain your keys. There has not been any indication from Microsoft that this will change in future.
from what I know about the goals of the dev team, since this is a highly requested feature, we will probably see this in action in future version of the bot framework.
But no kind of timeline yet for this feature.
I am looking to create a bot and have come across Microsoft Bot Framework (with LUIS or can use C# SDK provided by API.AI) and Howdy.ai Botkit (with Middleware support for LUIS & API.AI).
Can someone help me with comparison between these two?
I am looking for following things in my bot -
Support multiple channels including Email.
Have the bot act in both reactive (reply to some user message) and proactive (send out message to users once a day about something important to them or followups)
manners.
Save and later retrieve user provided data (manage state).
Rich message support.
Respond with delay.
Manage conversation history.
Are there things that are available in one but not in another?
I tried developing a bot in Botkit and MS Bot framework both. Ultimately I went with MS bot framework. Some of my reasons which could help with the comparison:
MSBotFramework has support for skype, slack, telegram, Facebook, and many other channels. BotKit, the last I checked, supported only Facebook and slack. I was targeting skype and telegram and that was a deal breaker.
Botkit currently is node.js only. On the other hand, MSBotFramework has .Net, Node.js and even a REST API (which basically means you can use it from any language you want). Also, there are python wrappers available which internally make use of the REST API.
Being a Microsoft product, MSBotFramework's integration with skype, azure, azure analytics, LUIS and other Microsoft services is very easy. This could be required for developing, deploying or integrating natural language support. Botkit supports LUIS integration, which is fairly easy( maybe as easy as MSBotFramework). The analytics (through botkit studio) (was) very basic and MSBotFramework wins hands down here.
I found the documentation for MSBotFramework more comprehensive than Botkit but both of them have an equal amount of resources and documentation.
Some of the other points you have asked about:
Proactive messages depend on the channel you are developing for. For eg. Facebook allows a time window of 24 hours from the user's last message in which you can reply. Whereas other platforms like skype and telegram allow you to send a message anytime you want.
State management will need to be handled on your end. Bot Framework provides some mechanism, but it is not robust enough to be used in production.msdoc
Rich messages are platform dependent, but bot framework does pretty well in catering to most of them. So, the way this works is, you send back the message to bot framework in its own rich message format. It converts to platform specific format. If you have only one or 2 platforms in mind, you can develop accordingly.
Respond with delay - You will have to implement it yourself, though bot framework has lots of examples of doing this.github
Managing conversation can be done easily if you are using C# and .Net platform in general. The documentation and number of examples are very impressive.github repo for samples
All in all, I would recommend MS bot framework.