I'm having really annoying problems getting my bot to work in MS Teams. I created it using Bot Framework v4 and deployed it to Azure. I deployed the bot using Direct Line from the "channels" blade and it's working ok. Then in the same blade I deployed it to MS Teams. And that caused issues.
People are telling me that the problem has to do with something about a manifest file and a "valid domains" setting I have to edit. I don't know what those are and I never had to do any of this when I told Azure to deploy it to MS Teams. It seems there's a whole different way to deploy the bot to teams, which is using App studio. I tried that way, and now I see another different issue.
So it doesn't work for me when I deploy with Azure or using App Studio. And I want to research and fix the issues, but first I need to know which method should I try to fix? Which am I supposed to use to deploy to MS Teams? Azure or App Studio?
Note: I'm not asking how to fix these issues. I want to know which method of deployment I am supposed to use. What's the difference?
Let's get the terminology straight first. You are building a bot. In Teams, a bot is just one of the possible capabilities of a Teams app. (The others are tabs, connectors, and messaging extensions.)
The definition of a Teams app is defined at a high level here.
Creating an app package (which is one of the things App Studio can do) is defined here - App Studio can also sideload/upload apps (see below).
Once you've created it, you need to make it available within Teams, first for yourself (and potentially others, if it's allowed in your tenant) via sideloading/uploading, or for your entire organization if you like. That's defined in Upload an app package, with in-depth discussion of the tenant app catalog here.
Related
I have used the Bot Builder Teams messaging extension sample and successfully debugged the project locally on my machine using ngrok. I then proceeded to follow the Azure deployment instructions, and successfully deployed my bot project to Azure.
However, I cannot find instructions regarding what values need to change within my project to now use the assets within Azure. I have enabled the Teams channel on the Bot Channel Registration resource that was provisioned, and I tried updating the botId value within my project's manifest file to match that of the newly provisioned app registration. But I'm still receiving an 'unable to reach app' message when sideloading the app in Teams.
Are there instructions regarding how/what to change within the project so it uses the Azure assets rather than my local ones?
To narrow down what's wrong, have you tried using the Web Chat to test the bot ? If this works, then the bot is working fine in Azure and the issue is for local teams to reach Azure.
Also verify that you are using the right AppID and Password.
Once you have verified that the bot is working in Azure, at the bottom of this page, you will see steps to get a url that you can paste to get the bot added in your local MS Teams instance. (quoting below for quick access)
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.
I did finally get my bot working, but found several missing steps within the deployment documentation. I have reported them in a GitHub issue, associated with the relevant documentation article.
I have a web app written in Node and hosted as an Azure web app. I have setup Application Insights web tests for other sites that do NOT require auth and these work fine. Now I need to test a route that requires authentication, but it is not obvious how to do this on the Azure Portal. Can this actually be done? I have seen some posts about doing this through Visual Studio but I really want to avoid that if at all possible.
As per the article here - https://learn.microsoft.com/en-us/azure/application-insights/app-insights-overview - if you don't want to touch code (and hence, redeploy) you cannot do what you are asking in the question.
Looks like diving deep into code is the only way
I started learning Microsoft bot and coming across different environments to build and test. I am trying to understand the exact purpose of all environments.
Bots can be developed using Visual Studio using c# or Node.js in our local machine after downloading the Bot Template. Also, It can be tested in our local development machine using the Bot Emulator. I am clear till this point.
In one article, I could see that Bots can be built using https://dev.botframework.com/bots. When should we go for this environment?
Also, Bot Service can be enabled in Azure (portal.Azure.com). How it differs from the previous dev.botframework.
Can someone clarify?
If you are developing a bot locally, the environment you described is perfect.
However, once you want to allow others to access your bot and from different channels (Facebook Messenger, Skype, etc), you will likely host it in a cloud platform, let's say, Azure. Once you do that, in order to allow the Bot Framework infrastructure to interact with your bot you will have to authenticate your bot against that infrastructure. For that to happen, you will have to register your bot in https://dev.botframework.com/bots whereyou will get your Microsoft AppId and your Microsoft AppSecret, that then you will use in your bot code (in C# in the Web.config, in Node.js usually in a .env file).
You can read more about this on the How the Bot Framework works documentation topic.
Regarding Azure Bot Service: it an integrated environment that is purpose-built for bot development, enabling you to build, connect, test, deploy, and manage intelligent bots, all from one place. You can write your bot in C# or Node.js directly in the browser using the Azure editor. Your bot is automatically deployed to Azure.
You can read more on https://azure.microsoft.com/en-us/services/bot-service/
A couple weeks back our Mobile App was migrated from the old portal to the new one and it hasn't behaved properly since.
Our main issues are:
We cannot access any logs files, the tab for Diagnostics logs stopped working entirely on Wednesday but even before that we never got any useful data out of this. When something goes wrong with our nodejs backend we can't find any clue as to what went wrong like we could in our old portal under the logs tab.
We are unable to access the FTP server entirely, it just won't let us login even though the credentials are correct and have been reset multiple times in attempts to get them working.
The server is throwing errors about not having enough disk space left even though we should have 53Gb to go (we're currently using 1.05Gb out of 55Gb)
Our deployments slots are not working at all, when we push our code to the deployment slot it just doesn't work, every request we make to the deployment slots tells us we're not allowed to do anything.
We are running a standard tier Mobile App server. The backend is in NodeJS, our CMS is in ASP.Net and our app itself is in Xamarin Forms.
The issues started after we migrated the server a couple weeks back from the manage.azure.com portal to portal.azure.com.
What can we do?
Edit:
We got through to Microsoft via the payed support plan which we're getting refunded because these are basic functionalities which don't work as advertised after the migration. I've got a call with them in about three hours to get things sorted, if I learn anything we can do ourselves I will update this post to share the knowledge.
This needs to be a support request to Microsoft.
If you can, open an incident with Microsoft Support. If you can't, post a question in the MSDN Community Forum. (We need to ask about particulars of your site and that isn't an appropriate topic for SO)
As the architecture of Mobile Apps is changed from Mobile Services, now the mobile apps migrate to Azure App Services.
Actually the Mobile Apps backend in Node.js is an expressjs project, and the mobile app sdk for node is a middleware of express. So the way for diagnostics and troubleshooting has changed from before we use Mobile Service. You can refer to https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-node-backend-how-to-use-server-sdk/#Debugging for details about Debugging and troubleshooting for mobile services.
Additionally, we can leverage the Visual Studio Team Services editor as the section How to: Edit code in Visual Studio Team Services shows in the link above, we can monitor the output of the Mobile Apps backend application. E.G:
About your FTP issue, please double check your deployment Username, when we login to FTP server on Azure, we need to input the full FTP user name which is "app\username":
You can refer to https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/#enabling-diagnostic-logs for details.
I'm in the process of evaluating App Service and in particular Api apps and logic apps. I want to be able to make use of git deploy for an Api app instance.
This article https://azure.microsoft.com/en-gb/documentation/articles/web-sites-publish-source-control/ mentions that even though it is based on web apps, you can apply the same processes to api apps, however, when I attempted to follow the tutorial using an api app instance, I was unable to see the "deployment" tile on the api app blade in the azure portal. I was able to complete the tutorial for the web app instance.
Does anyone know why I wouldn't be able to see the deployment tile for an api app blade?
I want to use the api app so I can make full use of swagger and the logic app service.
Edit
Thinking about it, do I even need to use an api app or could I get away with using a web app (with swagger meta data) for connecting to logic apps?
Update
Found it - see my own answer.
OK, I found it and it's not a bug. I was being (a bit) dumb. Following this article, I discovered that I needed to click on the Api app host section and then all settings then continuous deployment.
This is, imho, a poor UX decision here, given the blade looks exactly the same as others that do have the deployment tile, but at least I can set up git deploy for my api apps now.
#Simon
This may be a bug - I will poke the Azure Team for it asking that. Even though, WebApp, APIApp and MobileApp are EXACTLY the same service, only changing name. So, if you can see deployment tile for one of them, you should be able to see all others then.
BUT, there is a "invisible business link" around them that make all things working. When you work with Logic Apps, it will search for custom API Apps at - guess what! - you API App list. So, you can host a API application at WebApp, but probably the Logic App will not go for it by default.