Working on an application and developing chat integration bot. Note that contrary to some news bots or other tools, there is no central website or server that the bot gets its data from. The software installation comes with a repository, and that is where the bot connects to. Thus, every user, upon installing the software, will basically get their own copy of the bot, alongside with their own repository, etc.
Now, having done that for Telegram: You open the telegram client, initiate a chat with the botfather, get the token for your new bot with one or two commands, and then add that token to my application. Done. Easy for the user to follow, takes a few minutes at most and they have a working bot.
Trying to do the same with Skype, the users must:
Sign up for an Azure account
Provide credit card and phone number verification (that's probably where some users will stop right away)
Log on to the Azure Portal
Create a bot channel, through a myriad of different screens I have to guide the user through.
Have the user obtain the bot's password, again through a variety of different screens he needs to be guided through. (if the user hasn't given up yet, at this point he'll definitely get grumpy)
Enable the Skype channel, and enable the bot to be added to group chats.
Attempt to locate the bot via Skype and eventually add it in.
Now, if I wanted to document this properly, this will be a 10-15 page document with tons of screenshots and all. To do what Telegram does in two minutes or even less. There's so many opportunities in all of this for something to go wrong, that I can't even consider forcing my users to go through this.
Surely, I must be missing something? It can't be that you have to go through this horrible mess of an over-engineering spectacle that is second to none, just to get the most basic bot to function?
All I need is a means to say "this is the bots name, give me its token and API URL so that it can send messages using the REST API". But I can't seem to find this for Skype.
Related
I created an Azure Bot Service. When I test the service using "Test in Web Chat" it works as expected. When I add the Web Chat channel and use the Web Chat URL, it works as expected.
However, when I add the Microsoft Teams channel, it does not work as I expected. The Health Status shows "Healthy" (in "Channels (Preview)") and "Running" (in "Channels"). When I select "Open in Teams", I am redirected to Teams, but I do not see the bot as a user/bot I can chat with. I watched a video showing just that behavior as I was expecting, but the link only opens my Teams. I only have one other user in Teams and that user shows up. No sign of the bot. What am I missing?
I tried using the "Get bot embed codes". I put in the URL for the Mstreams href and instead of sending me to the bot user as I expected, I am redirected to the other user on the account (not the bot). What am I missing?
I've tried this using the "Channels" and the "Channels (Preview)" sections with the same results.
If relevant, I am still in the trial period with Azure and have not upgraded, but nothing says this should be an issue.
From all I can tell, I'm logging into the Azure portal and the Bot Framework portal with the same account as my Teams account. I'm using latest updated version of Chrome.
I don't think free account has anything to do with this. But the fact that the " bot embed codes" lead you to a different user, may be a configuration issue. Read Create a bot and Test and debug your Microsoft Teams bot in the Microsoft Teams documents for more information.
If you have successfully deployed to teams channel (teams channel registration), as per docs Copy the https part of the code that is shown in the Get bot embed code dialog.
For example, https://teams.microsoft.com/l/chat/0/0?users=28:b8a22302e-9303-4e54-b348-343232
In the browser, paste this address and then choose the Microsoft Teams app (client or web) that you use to add the bot to Teams. You should be able to see the bot listed as a contact that you can send messages to and receives messages from in Microsoft Teams.
Alternately, In-order to test them in teams you need to take the app id from the Configuration page of the bot.
Once you search with the app ID in teams you would be able to see this bot as a contact in Microsoft Teams.
Refer:
Create a Teams app package and upload your app to the Teams client for testing. Learn how
Publish your bot as a Line of Business app in your organization's Teams Tenant App Catalog. Learn how
Publish your bot as an app in the Teams App store. Learn how
I think I have found the answer, though I'm still trying to retrace my steps to make sure this is accurate. I will update here if I find anything more of value.
Despite little/no documentation to this effect, bots apparently do not work in the free version of Teams. You have to at least:
create a developer version of Microsoft O365 (E5 license) (and go through all the rigamarole to get it setup properly)
add at least one more user to the organization
then open Teams
Then, I used the embed URL to get the bot to show up. (Again, the same process did not work with my free Teams account even with another user added to it).
For the record, I didn't need to change any admin settings once the three items above were completed.
From my understanding, the OAuthPrompt requires a connection name. To create this, I need to make use of the Bot Channels Registration (as per the documentation). However, this seems to require me to create an Azure account and enter my payment card details. I would like to avoid entering my details if possible as I would not like to be charged for using any Azure services. Is there any way to avoid this?
If I must manually handle the OAuth process, I would like my sign-in to pop up in a small window like the "Allow" button triggers within the Who bot. I have tried SignIn cards which I have read just don't work in teams, and I have also tried OpenUrl type actions in a card which, when pressed, open the URL in my browser as opposed to a pop-up. How can I achieve this?
You can create a Bot Framework bot (only for Microsoft Teams) using the guidance here: https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/bots/bots-create. To summarize that article, you can use this endpoint to create a non-Azure bot: https://dev.botframework.com/bots/new
If you chose to use the Azure Bot Framework, you will not be charged for the Bot Framework if Microsoft Teams is your only channel (this does NOT include your web service if you chose to host your bot code on Azure, although you can chose a free tier to avoid any charges).
For authentication, see this section of the MS Teams documentation: https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/authentication/authentication. Depending on how you chose to implement your authentication, there are a few articles in that section that may apply. The OAuth card does work in Teams (not the free version, does not work with guest accounts, and only works for Azure bots).
For authentication, if you're redirecting to a different domain make sure you add it to the validDomains in your app manifest.
Question: How to have multiple bots supplying answers to the same Teams chat window a user has with an aggregator bot.
Description:
Several different teams have created bots that can answer questions related to their areas. Picture a services bot, a catalog bot, etc. All of these bots are maintained by their individual area owners, have their own sets of LUIS intents, etc. That works great, but you have to know where to look for each type of question.
Now we'd like to have a single bot for anyone to connect to, to get their questions answered no matter what area the question falls into. The idea is that this aggregator bot would then forward the questions to the appropriate area bot, which would then provide the answer. The scenario here is that someone troubleshooting an issue could ask questions crossing multiple areas in the same place without having to know about each individual area's bot.
The bots are currently hosted in Teams and are C#. So far, our solution has this flow:
Aggregator bot receives the question and asks each bot (through another endpoint specific to this flow) how confident it is that it can answer the question.
Aggregator bot decides which bot(s) to ask the question to, and sends the question off to the regular /api/messages endpoint for the bot.
[Broken] Area bot posts the answer/ auth prompt if needed/ or the start of a conversation to clarify the eventual answer.
We found the bot-to-bot handoff project, but in the readme.MD, it says:
Note: The main bot and each of the sub-bots share the same AppID and
AppPassword. This allows all the bots to share the same conversation
ID, Dialog
Stack,
and Bot State
Data.
This is not possible in Azure, because you can't create multiple bots with the same AppId.
Trying a hack based on that, we found that if we change the bot configuration to use the same MicrosoftAppId and MicrosoftAppPassword in the Application Settings in Azure for all the bots, then everything works fine through the aggregator bot. At that point, you can no longer connect directly to the individual bots anymore. While that is clearly a hack and not a solution, it implies that the problem is authentication based and not something that is implicitly impossible.
There are lots of pieces around that seem like they might help, but we haven't found the documentation to fit them together. This seems like something that should be a common scenario. Ideally we could specify some kind of bot trust at a higher level and not have to specify AppId and AppPassword directly, though we're willing to do that in this case since we're all the same company.
Things we've tried:
Using TrustServiceUrl to trust the aggregator bot from each area
bot, and all the area bots from the aggregator bot. The call was
made in Application_Start in Global.asax for each bot.
The hack described above
Specifying AppId and AppPassword in the BotAuthentication attribute
Number 3 actually solved the auth problem for letting the aggregator bot ask each bot for it's confidence in answering the question when we used it to tag those functions. Specifying the AppId and AppPassword for the aggregator bot in the specification for that endpoint in the individual area bots worked great. But it didn't fix the ability for the individual area bot to post back to the conversation owned by the aggregator bot. In that case, the aggregator bot itself is consuming the answer, and it is an answer and not a flow.
What do we try from here? Is there something we've missed, or is there something fundamentally wrong with the approach we've started with?
I really like Slack but my organization won't allow it if we cannot disable file sharing features. I'm trying to find out whether I can either disable uploads of certain file types or hide the file library all together. Their support says there's no way to do this natively but is this possible with the API?
No, not to my knowledge. The main focus of the API is not to configure your Slack team, but to enable bots and 3rd party apps to communicate with your Slack team and retrieve information. All core configuration for your Slack team has to be done in admin settings and apparently you have already learned from Slack support team that you can not deactivate file sharing in admin settings.
But I think I might have a solution for you. You can create a Slack bot that automatically blocks sharing of files in channels. (technically the bot would auto delete any message that is a file share form a user). Users would still be able to upload files, but they wont be able to share them. At least not in any public and known private channel. However there is a caveat: As I understand the bot would not be able to block users from sharing files in direct messaging channels though.
We are using a similar bot to block messages from unauthorized users in some private channels, which works nicely. Our bot is a simple Slack app with a bot user and using the Events API to receive all messages from all channels he is invited too. The bot then checks each new message and deletes the ones that does not fulfill some criteria. In our case if the message comes from a user that is not on the whitelist.
I have made a Parse-based app that allows the user to send a push notification to everyone who downloads the app. It's a kind of quick public address system for a congregation, school, club, etc.
Other leaders have expressed an interest in my app for their communities. But these people are not tech-savvy and have no interest in becoming Apple developers for $100 a year, so building custom apps for them is not an option. Even if I did it for them, I would be concerned that they would mess something up that would require a lot of time on my part to repair. They just want to use the app for their communities.
My question: Could I make custom apps for these groups, keep them on my iTunesConnect account, and simply make a new Parse account for each app? That way, the group leaders would only need to know how to log into Parse and send a push notification on the Parse website.
Thank you,
Eli
You could. It could be done with a single app that everyone downloads and then configures to connect it to their specific parse app.
It's possible that you could write the app so it doesn't know the parse account details and they need to be entered on the device. It's also possible that you could supply that detail with an invite e-mail that opens the app and has the details in the URL query.