I am attempting to monitor my Power Automate cloud flows, using the build-in Monitor.
So when I go to make.powerautomate.com and sign in, go to Monitor in the left pane and the click Cloud flow activity, all I see is this screen below.
I then used Create from blank to create a new and very simple flow. And the ran it.
Now I would expect something to show up under All Activity. But the image remains unchanged.
Does anyone know what i am missing?
(yes I have refreshed the page)
I also have many flow already existing on this environment in solutions. And as you can see they do not show up here either.
Related
this time I'm stuck with my AutoIt program. It works quite well not running as a service, but as a service there are some problems, and I wonder if I can fix em.
To my program: It uses the Tooltip-function of AutoIt to show current temperature on screen. It requieres read / write permissions.
About the service:
The service is created by using svrany.exe as Host. It connects as a local administrator, so it has full write / read permissions as needed.
The only problem is: It cannot show any tooltip, but write it to a file. Is there any way to let the user at least decide if he wants to see that message? Like Windows asks, if you want to see what it shows, while using "local system"-account.
Have a look here. I guess there is no way without interacting with another process through the service.
https://www.autoitscript.com/forum/topic/80201-_service_udf-v4-build-your-own-service-with-autoit-code/
I have an app which build on Xcode objective-c, I have a code and I need that code to run even if the user press the home button.
Is it possible to do it?
Refer to the Background Execution chapter of the App Programming Guide for iOS.
There are three difference scenarios for background network requests:
The user initiates a simple request and expect the server to respond reasonably quickly, but want to make sure that if the user leaves the app before the request complete, that it really has a chance to finish gracefully in the background.
See the Executing Finite-Length Tasks section of the aforementioned guide for a discussion on how to request a little extra minutes after the user leaves the app, and that may be sufficient to finish the network request.
You are requesting large volumes of data (or uploading a lot of data), where it is anticipated to possibly require more than a few minutes to finish, especially on slow connection.
In this case, as Phillip Mills pointed out, you can use a background NSURLSession (as discussed in the Background Transfer Considerations section of the URL Loading System Programming Guide: Using NSURLSession guide.
You want to periodically make very quick calls to your web service to check to see if there is any new data, even if the user isn't using your app at the time.
In this case, you should look into "Background Fetch". See the Fetching Small Amounts of Content Opportunistically section of the App Programming Guide for iOS. You can't control precisely when it checks, but it is a way to initiate short network requests even when the app isn't currently running.
Note, if this opportunistic background fetch determines that there is a large volume of data to be downloaded, you can combine this pattern with the previous pattern (the background NSURLSession I discussed in point #2).
For more information on this, see the WWDC 2013 video, What's New with Multitasking.
First off, I know some proper ways of making a truly interactive Windows Service.
The situation is, I do have a tool that does not interact with the user as such. However, it does display non-blocking notifications both via popup windows and via the Windows Notification Area (aka System Tray). It also writes a logfile of the notifications it displays.
This tool is normally spawned by a main user application and as long as the main application is a normal application, these notifications do work as intended.
When this tool is spawned by a Windows Service, no notifications are displayed, naturally. (The Desktop Session for the service isn't visible.) But this would be OK, we have the logfile and these notifications are just - notifications, nothing the user absolutely must see under all circumstances.
The question now becomes: Is a process running in the context of a Service (the Service itself or any process it starts) "allowed" to make Windows API calls that display a visible GUI?
Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session of the service?
Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?
And yes, calling ::MessageBox is a bad idea because it will block. But I can handle these calls.
And yes, this could be designed better, but it's what I have at the moment and it would be nice if I hadn't to rip the whole tool apart to make sure no GUI related code is run in the service.
GUI elements from a Windows Service are shown on Session 0. On Windows XP & 2003, users were allowed to log in to Session 0 and interact normally with the windows created by a service, but Microsoft put a knife in the heart of interactive services in Vista (and beyond) by isolating Session 0.
So, to answer your specific questions:
Is a process running in the context of a Service (the Service itself
or any process it starts) "allowed" to make Windows API calls that
display a visible GUI?
Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session
of the service?
Yes, GUI calls are allowed and should succeed as normal. The only notable exceptions that I know of are those related to tray icons because the process providing the task bar (explorer.exe) is not running in the isolated Session 0.
Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?
That should not be necessary, though you should proceed cautiously with any GUI interaction from your service. Test thoroughly!
I would like to provide some info wrt. Raymonds Chen's comment to the other answer
You should avoid presenting UI in a service because you may trigger
the UI Detection Service which will switch the user to your service UI
temporarily. – Raymond Chen
I find these good articles:
What is Interactive Services Detection and Why is it Blinking at Me?
Inside Session 0 Isolation and the UI Detection Service, Part1, Part2
Where one can find explanation on what the UI detection service (UI0Detect) is and does and how it's supposed to work.
Interactive Services Detection (the blinking button on the taskbar) is
a mitigation for legacy applications that detects if a service is
trying to interact with the desktop. This is handled by the
Interactive Services Detection (UI0Detect) service.
However, one must note that this only can work if the service that is trying to view a GUI has the flag "Allow service to interact with desktop" set, because only then the service process will be running on WinSta0of Session0 even allowing it to show anything at all.
Alex Ionescu mentions this:
If UI0Detect.exe ...
the SCM has started it at the request of the Window Hook DLL. The
service will proceed ...
The service first does some
validation to make sure it’s running on the correct WinSta0\Default
windowstation and desktop and then notifies the SCM of success or
failure.
So, to come back to Raymond's comment: As far as I can see, as long as a service doesn't tick the type= interact option (see sc.exe), and normally you don't tick this, the UI0Detect service doesn't do anything and there shouldn't be any "danger" of triggering it.
Note: The information above is based on my limited research and tests on only a single Windows 7 PC.
I have run into a situation where I need to open a newly created quote at the end of a workflow. I have a feeling this is going to require me to create a a very simple custom workflow that uses "window.open", but I would like to avoid this if anyone has a better idea.
So I need to open a newly created quote as soon as it is created in a workflow. Anyone have any good ideas on how to do this?
Workflows are asynchronous; they run on the server (as opposed to the client) and do not run in realtime. eg a workflow that is triggered by creation of a record will run on the server sometime after the record is created (depending on system load etc - it could be a second or two, or could be half an hour later. If you have stopped the CRM Async service on the server, they might well never run.)
Because they run on the server the user has no interaction with them. As a result you can't open a window, as there's no user involved to open a window for...
What you probably want to do is make use of Dialogs (introduced in CRM 2011). You won't be able to use window.open() but as long as you've got a recent update rollup installed on the server you can present the user with a hyperlink to most CRM records.
Setup of Dialogs is much the same as Workflows, and they use the same mechanics under the hood. The difference is that they're syncronous (i.e. run in real-time) and they are client-side. There's some detail on Technet: http://technet.microsoft.com/en-us/library/gg334463.aspx
I am working on an application that is receiving XMPP notifications using the Matrix SDK. As well I am using async web service calls to receive an initial set of data from the server.
Now, I am aware that with Mango I can close the app or move it to the background and have a background task that is able to be run every 30 mins (or so) for 15sec max which obviosuly means the XMPP push isn't going to work in this scenario. Is there any way to get background apps to execute more frequently than this?
Failing that for the syncing process all I can do is every 30 mins use a web service call to get any updates and store into Isolated storage for my app to pick up when it's next run. But I believe I cannot use any UI from a background task so cannot tell the user of updates?
So, if I get an important message can I somehow override the slowness here and force my app to run and inform the user visibly that something has happened and he needs to look at it? Is this where push notifications come in?
You can use the ShellTile API to update the application's tile on the Start screen, or use the ShellToast API to show a toast to the user. Both of these can be configured to launch into a specific part of your application (deep-linking) when tapped.
If you need a constant monitoring/update/notification system for your application when it's not running, then using push notifications is probably the more appropriate approach.