Requirement: I need to enable bot to handle QnAs, talk to SharePoint list for dynamic form flows and return custom designed cards/actions, preconfigured troubleshooting services with common questions and integration of Service Now etc.
Question: Since the bot is doing more than one, should I consider designing individual LUIS models and use dispatcher service? or could I build it using multiple intends with single LUIS model?
Reference: https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-tutorial-dispatch?view=azure-bot-service-4.0&tabs=csharp
Related
If my company sole purpose is processing a specific payload, but there is lot of orchestration for it. Should the orchestration, be in a separate domain. Lets say, payment is what the company does, but there is a workflow service, for that payment payload? If that is in a seperate domain, how should the workflow service domain talk to payment service domain?
It's better to use Event Driven Design which powered by message services like RabitMQ (or Kafka, MSMQ, or ..). It's not recommended to speech microservice each other directly via APIs. On the other hand to aggregate, some information from multiple services you can use 2 techniques, first using a BFF (back end for frontend layer), Second use a materialized view to gather information from many services.
I have a Microsoft framework based cognitive BOT with LUIS and QnA cognitive service now due to some reason I have to switch to Amazon cloud service and due to that, I will end up with doing a fresh development from the scratch.
So I am looking for a framework/pattern through which I can do development and be able to switch across any cloud platforms like Google, IBM, etc in the future?
if you implement the conversational aspect yourself (i.e. without relying on a platform) then an option is to develop a generic chatbot which accepts incoming requests (text, events) and provide a response which you can abstract in your design.
interface Response
interface TextResponse extends Response
interface MultiOptionsResponse extends Response
You can then provide different Channel adaptors (MS Bot, Facebook, Telegram, etc..) which serialises your model above into the specific Channel json format.
You can integrate in your backend NLP functionality for example and still maintaining the same abstraction.
A more pragmatic way
My experience is that the advantage of building your Chatbot on a specific platform outweighs any other disadvantage. You can normally rely on features (NLP, multi-channels, metrics) that enables to ship much faster.
The real deal is to ensure you can decouple any logic/component/feature that must not be strictly embedded in the Chatbot, for example creating libraries (or services) for business logic (book a trip, perform a search), persistence (save the conversation, retrieve user last access) or even helpers (translation, entity recognition).
Hope this makes sense.
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.
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.
I have been studying microservices and serverless solutions and am playing with an angular frontend hosted on S3 and Lambda functions that talk to various DynamoDb tables via the API gateway on AWS.
Every example and video I read/watch uses a simple CRUD microservices as part of a simple 'todo' application or similar. My problem is where does the business logic sit? If I'm building a complex application I don't want all my business logic in my frontend Angular application. Or do I? I could build an Application API which in turn calls CRUD microservices but that feels like a monolithic approach.
I appreciate there may not be a definitive answer but can anybody advise a novice on best practice?
There are several best practices I follow in designing Serverless Microservices
Start with only few Microservices (Less the better up front, unless you know exactly how the service separation should be, delaying the decision to split)
Separate your business logic that goes to the API, and use the handler as a controller in MVC to invoke the business logic. (This will also helps to unit test logic without depending on Lambda).
Its not necessary to write only simple CRUD in your API. It depends on your domain and Business Logic required. (But don't build another monolith without separating the code in to different services. Several AWS Service limits will also give you some guide on how much endpoints should be there in a service & etc.)
Apply the design patterns available for Microservices (e.g If you want to sync data bases between each Microservice, use Pub-Sub pattern using SNS, DynamoDB Streams and Lambda)
Use the Angular App to put most of the presentation logic.
Use CloudFront as a proxy and a CDN to avoid CORs.
If you need more information you can refer the following articles I have written on this.
Deploying Angular/React Apps in AWS
Full Stack Serverless Web Apps with AWS
Note: You can use the CloudFormation in Deploying Angular/React Apps in AWS to automate the creation of S3 and CloudFront with best practices.