I have built a webapp for an security company. They monitor burglar alarms using contact-id.
I would like to send the signals appearing on the central monitoring server (using listener light), to a panel in my humhub webapp. The information online is minimal. What could help, is that listener uses a sql database. Something that might work as a hack, would be to send the monitoring pc's screen to a iframe in the app.
Is there a way to have a screen broadcast privately to a iframe, or even a web based remote access of said screen?
Related
Is there a way to know when/if the whole website was down? And even better, the reason that it was down. I don't have access to the servers, only have access to Kentico admin with global admin privileges. Thanks!
Down as in the user trying to visit the site is getting a 503 Error?
If it goes down because of an error in Kentico, you would be able to check the event log, but if it is a server error you would need to check the server event logs.
There are a bunch of services online that will notify you when your site isn't responding like Uptimer Robot
One of the options is integrate your Kentico App with Azure Application Insights.
You can configure
.Net Performance monitoring via usage analytics (server
resources like http response time)
Status monitor to diagnose IIS
issues on live running web sites (without re-deploying)
Usage
analytics for pages of the website (client side like Google
Analytics)
Automated stress testing System availability and health
monitoring (think uptime / downtime tracking)
Crash reporting for
apps and devices
http://www.mcbeev.com/Blog/April-2016/Application-Insights-for-Kentico
Given an Azure hosted Web Role with a highly-available WebAPI (say 99.95%, as per https://azure.microsoft.com/en-us/documentation/articles/resiliency-disaster-recovery-high-availability-azure-applications/) application that has ~1000 clients. Client is a ReactJS application. The WebAPI application will push notifications tailored to specific client groups (e.g. not all client users are interested in all events, but >1 user may be interested in the same event).
From reading the SignalR documentation and playing with some samples it feels like SignalR Groups will help us flow the right events to the right ReactJS application instances. Additionally we would use one of the SignalR scale out providers to make sure that the we push to the clients from the right WebAPI server instance.
Question: How do applications recover when the "right WebAPI" instance becomes unavailable?
I can imagine a server-side active/passive scheme with some complexity around making sure there is at least one 'server' for each Hub Client...but can a Server connect (in an unsolicited way) to a Hub Client? Would we have each Hub Client connect (when registering for a Group) to >1 Server?
How have applications solved this issue with SignalR?
I think I missed the obvious point that the scale-out providers and the back plane provide the very protection that clients need against servers that go-away. Clients don't connect to a specific server, but to a load-balanced name.
I just want to know from which device logged in our website and where from (Location)
I'm currently working on azure mobile service API
Per my understanding, Azure mobile service APIs provided functions to approach resources on Azure but collect devices information.
If you want to detect device on website, I think How to detect mobile device and get user agent info send and save that information to database on server, only once maybe the similar thread on SO.
And to get the location of mobile devices on Web apps, I think How web apps ask location of mobile device will be the similar thread.
If you are creating a mobile application, and a Azure Mobile Apps with node.js as a backend for your application. We can create a custom API, and hit the API to send device information and location when your user login the app. For different platform, there are built-in functions in their SDKs to collect devices information and location.
I'm planning an application that has a mobile app as a front end (and perhaps a web front end also that performs a different purpose). Something like Runkeeper, or Runtastic, if you're familiar with those apps. The mobile device is the primary method of user interaction, and the web site has stats and dashboards that the users can view afterwards.
I would like the main application to reside in Windows Azure. I'm confused about how to architect the application though - should the business logic reside in a web role, or a worker role? If the main user interface is a mobile app, does it connect to the worker role to persist or retrieve data, or to a web role, or neither? I understand a typical scenario where a web role provides a user interface which can persist data directly to storage or pass data to queues or tables to be picked up by worker roles, but the presence of the mobile app throws me off.
Any help? Thanks!
Andy's answer is great, but let me add a different flavor. The only difference between a web role and a worker role is that the web role automatically has IIS turned on and configured. A good rule of thumb is that if you want IIS, use a web role. If you don't want IIS, use a worker role.
For hosting a server component for mobile apps to connect to, I think the simplest thing that would work would be a web role hosting an ASP.NET web application. Web applications can be used for services as well as web front end (HTML) web sites.
ASP.NET MVC and Web API make setting up web services really easy, and it's easy to work with non-HTML data formats, such as JSON or XML. Your mobile app could communicate with the web app using a REST JSON API, or you could use XML/SOAP if you wanted to, or whatever format you want. REST APIs with JSON as the transfer format is probably the most popular at the moment. One way to think about a web app is that it's just a way to send and recieve data from clients. If the client is a web browser, you can serve up your content as HTML pages, or if your client is a mobile app, you can serve up your data as JSON and let the client display it however it needs to. Basically, your web app can be both your web site (HTML), and your "API" for non-web-browser clients.
You can think of worker roles sort of like Windows Services. They are primarily used for doing back-end processing, and things like that. A worker role might provide some capability to host a public facing API, but you would have to manage connections, message pipelines, recycling, and all that yourself; whereas, a web role would have a web server (IIS) provided for you to manage connections, etc. If you are going to introduce things like message queues, it would make sense to have the public facing API be a web role, and the message processing component a worker role. The web app could receive the message from the client via a REST JSON API, and then pass the message off to a queue, where the worker role picks it up. Introducing queues and worker roles makes sense if you have heavy-duty server-side business logic that can be processed in the background without impacting the client.
I have 2 web applications running in a web role and I only run single instance in the azure cloud. I would like to send and receive notifications between these 2 applications and any outsider should not have access to them.
That means, web service in both of them are out unless there is a
way to block outsiders from accessing a web service and only a
request from same system would succeed (May be vip and request ip
comparison would do, anything beyond that?).
File system watchers. Create a LocalStorage and use it in both
web apps and watch for files webappA and webappB in each other.
Use Azure Storage Queues.
MSMQ - not interested as its not supported in azure.
Could you please list other options available for me in azure web role
? Thanks in advance.
Note: Please avoid suggesting Internal Endpoint as I am running only a single instance with 2 web applications running in it.
You can set up "private" web services to listen on Internal endpoints. These are not accessible via the outside world. You could have a WebAppOne endpoint and WebAppTwo endpoint, both marked Internal. You then just query the role environment to discover the assigned port for each, and fire up your ServiceHost.
Or... you could use a queue to pass information, as long as:
You're ok with it being asynchronous
You're ok with messages being looked at "at least" once
You're ok with messages possibly being looked at out of order
Or... your apps could write information to an Azure table. No need to expose the table to the outside world.