We Keep Coding

Call Azure webjob from appservice

Summary
I have an Azure Appservice; webapi, and when there are hundreds of requests received at the same moment the app service failed to pick them up quickly and the response time will be beyond 230 seconds, hence get server error. But this does not happen for like below 1xx requests.
Core functionality:
This app service logs the request to the blobstorage and sends the request body to a service bus.
My Question is:
I read web apps performance in Azure FAQ and it suggests to use webjob if the response was more than 230 seconds.
How could I send the appservice's request body to the webjob console application which expects string array as an input?
So that this webjob would do the blobstoring & sending to service bus(which was the appservice work.)

You can leverage Azure function for sending message to Azure Service bus.Azure Functions supports trigger and output bindings for Service Bus queues and topics. By running on Azure function that too on consumption tier also contribute to cost optimization.
Follow these which discuss about this :
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-service-bus
https://blogs.msdn.microsoft.com/benjaminperkins/2018/11/02/azure-function-service-bus/

What you actually need is a way to start a background process and then get the output once it's completed.
Here's what I would do:
Azure Functions + Durable Functions, triggered by a http request. In the response, you'll receive an URL to query for the status (Completed / Running).
More info: https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp
https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-create-first-csharp

communication solution between azure app service and external program

I am building a website using ASP.NET MVC which gonna be deployed as Azure app service and I got another program which will interact with the website backend in real time and sends live data which needs to be displayed on the website as live data and it is bi-directional. We used message queues (Azure service bus) before and these doesn't seem to be reliable (delays coming up on sending and receiving data).
Can anyone suggest me what is the best way to go with?
Websockets or database operations or anything else

Azure service bus or just Azure web app when using SignalR

I never used the Azure. Now, i with a problem.
I am going to do a Chat on Xamarin Forms using SignalR. So, the chat will have a 1:1 and a group 1:all . Its for a small group of 700 to 1.000 persons. Looking at the internet, i didnt understand if i have to pay for Azure App Service (standard) + Azure Bus Service, or just Azure Bus Service, or just Azure App Service.

Short answer: you only need to pay for Azure App Service to create a single Web App if you want to use SignalR.
The only reason you'll need Service Bus is if you decide to scale your Web App to multiple instances. To synchronize across multiple web apps, SignalR requires a messaging backplane. That's what Service Bus would be used for. Your other options for a SignalR messaging backplane are Redis (very fast), or Azure SQL (slower). I personally use Service Bus for my SignalR messaging backplane. But again, you do NOT need Service Bus if you're only using one instance for your web app.

If you have an MSDN account you get a certain amount of free credits to put towards it, but each type of Azure Service generally has a charge. Check out the pricing pages on azure and you'll be able to gauge which is your best option, alternatively if you aren't ties to Microsoft, then you can look at the RabbitMQ offerings of Amazon.
If you're unsure on the pricing, speak to a Microsoft Sales person, they've helped me out in the past and are quite good.

Implementing an Azure Service Bus listener application

I'm developing ASP.NET Web API services and placing these onto an Azure Service Bus queue to be processed. The Web API services are hosted on Azure.
I need to implement an application that listens for these messages and processes them when they are received.
I'd like this to be hosted on Azure but not sure of the best way to approach this.
Can you implement such a listener service and host it on Azure?
What is the best way to approach implementing such an application / service?

There are several things you can do.
You could use ASB's OnMessage API which allows you to register your callback and handle incoming messages with concurrency and auto-completion.
On Azure you have several options: Cloud Services (worker roles), Azure Web Jobs, Azure Functions (if your processing is fast, otherwise I'd not recommend it), Service Fabric (might be a bit of an overkill if system is small), and plain VMs if needs to be.
Warning about functions - if you do intense work, Functions are not ideal as you'll pay for time/memory you execute.

A couple options for workers that listen to a queue are:
Functions
Web Jobs
You can see an example of using a Function here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-create-an-event-processing-function.
An example of using Web Jobs is here: https://learn.microsoft.com/en-us/azure/app-service-web/websites-dotnet-webjobs-sdk-service-bus.
Both allow you to create background jobs that consume messages from a queue. Both support Storage and Service Bus queues. The main difference is that Web Jobs require an App Service Plan with some amount of instances, while Functions can run on a Dynamic plan, which scales completely automatically.
You should note that Functions are not meant for really long-running jobs (more than 5-15 minutes), though neither are Web Jobs.

Why not trying to run a linux process (daemon) in docker.

Azure service for distributed desktop and web application

I am trying to figure out which Azure service to use to create a distributed application. The application consists of
A desktop (Windows) application which is fetching, manipulating and storing data in Azure
A backend which stores data and does background processing.
A web front-end which allows me to view the data and trigger background processing in the backend
Any number of desktop application instances can connect to the backend and access the same data
The desktop application and the web application will send and receive data to the backend. Each message can be up to 100 MB (images etc).
The Azure universe is a bit overwhelming, and I'm trying to find out how to set this up.
My initial thought is to let the desktop application communicate with an Azure Cloud Service with WCF. The cloud service is set up with a WCF web role. A separate web application (web role?) is communicating with the same WCF web role.
The WCF role will also start worker roles to do more heavy, time-consuming processing.
Any ideas and insight is welcome! :)

For WCF service and web front-end you can use both Azure Cloud Service or App Services - it mostly depends if you need to install some 3rd party components on the machine (Azure Cloud Service allows you to do that).
For background processing use Web Job in App Services or worker role in the Cloud Service. You should also use some queue (I like more Service Bus then Azure Queue from storage account). Your worker role or Web Job should monitor this queue and when you put some message to it then some background processing should be triggered. Background processing could be done also in WCF process itself, but using worker roles or Web Jobs allows you to provide more availability.
For storing blobs (like images) definitely use Microsoft Storage (Blobs), for other data you can use Sql Database or something quite new: DocumentDB. Sql Database is simpler to use and easier to migrate data to other servers etc. but is more expensive.
And of course you can do the same on Virtual Machines, but I guess it wasn't something that you asked for :)