I want my workflow to be able to respond to an activity generated from host.
I can use Receive activity to wait for external events, but Receive only works (as far as I understand) in a context of a workflow web service.
In Workflow 1.0 (AKA 3.5) there was a Listen activity that could listen for events from host.
I understand I can do woodoo with bookmarks, but is there a replacement for old Listen Activity? or do I just use old activity (form System.Workflow) namespace?
It's called Pick activity. http://msdn.microsoft.com/en-us/library/dd807389.aspx. This might be better source http://blogs.msdn.com/b/flow/archive/2009/12/31/event-driven-execution-in-net-4-0-with-the-pick-activity.aspx
Related
I'm investigating the best web framework for my purposes.
We'll develop several microservices, and we need to dispatch events on some microservices, that could be listened on other microservices.
Is there any support for that using FastAPI?
If not, is there a way to listen db event operations?
I saw the #app.on_event("shutdown|startup") from starlette, but can I dispatch more events?
Thank you in advance.
Currently there are no generalised event dispatching/listening features in FastAPI.
#app.on_event("shutdown|startup")
Are a subsection on the ASGI protocol. Implemented by Starlette and in turn available in FastAPI
https://asgi.readthedocs.io/en/latest/specs/lifespan.html
FastApi/Starlette are web frameworks only and limited to http and websocket events they don't provide pre-built event handlers for any specific database events.
While FastAPI doesn't support general event dispatching, there are libraries available to supplement this. The one I've been using is fastapi-events (Disclaimer: I'm the maintainer)
Events can be dispatched by using dispatch("event name", {"payload": "here"})
The handling of events can be done either within the code, or be forwarded to a remote queue.
I'm building an application that listens to the Asterisk AMI to see when a user gets a call or makes a call out. I have got the events for when a user gets a call and when they make a call out. But what event do I listen for when a call gets transferred to a user or the user picks up the call with a feature code? The events that I am using now are AgentCalled and Newchannel. I would appreciate any advice on this topic. Thanks.
For asterisk 1.8 you have check
Transfer
Masquerade
Bridge
Hangup
events.
For 11+ bridge replaced by "Link" event.
Just do transfer and dump all events you got, you will see needed events for your asterisk version. There are more then one method of transfer, events will be different.
Hi Is there a way to break the nginx module request handler into phases to simulate async behavior for third party library used in custom module?
Say I have a library that talks to another server and this library internally manages connections and request processing with backend server. nginx wont be able to generate events on the underlying connections. So approach I can think of is, the nginx handler creates a thread to run the blocking operation and at this point I want to return the control to nginx so it can proceed. Now when the library API call returns I want to post an event in nginx event loop so that it can resume the handler and send back the response to client.
I guess this should be possible? Any pointers on how?
Thanks in advance,
I'm implementing a Core Service "Facade" for some lazy programmers that don't want to change their coding style (me included), and wanted to implement object cache, which obviously leads to the grand question of "how long and how much should I cache".
The ideal answer is to cache forever except when data is changed.
Is there a way (via some WCF event perhaps) to implement a "listener" for data changes that could be used to remove items from their cache?
BTW, I am using .NET's native ObjectCache (MemoryCache) with a 1 minute sliding cache policy for now.
Thanks,
N
There is no such system built-into either WCF or Tridion that I know of.
You could of course roll your own, where you:
Listen for changes to the relevant data on the TCM server with Event Handlers
Have those event handlers forward the event to a central notification server
Have your WCF clients register with that notification server when they start up
Have notification server subsequently send the notifications on to the connected clients
This is essentially quite similar to how Tridion's Broker Object Cache works on the Content Delivery tier.
If you're interested in implementing such an approach, I'd suggest having a look at the Signalr project, which takes a lot of the hassle out of it.
Edit: it turns out WCF has something akin to what you're asking for called Callbacks. See this question and this blog post.
I am trying to construct a simple windows workflow to monitor a directory for inbound files and do some DB updates using Windows WF 4.0. Currently I am planning to build a 'WCF Workflow Service' and host it as a 'Windows service' running 24/7 (with a daily service shutdown and startup).
Further in the future I am planning to consume this service using an ASP.NET/WPF application to create a basic dashboard kind of stuff.
Considering the idea of directory polling for files with WF hosted on windows service, does it seems to be a good idea? What can be the cons of this?
Please advice if there are any drawbacks on this or can this achieved by better means?
I'm actually doing this, but it is a bit more complex than you think, and should be avoided if possible.
You should not be blocking from within an Activity; if it is expected to be a long running Activity that is waiting from input from the outside (FileSystemWatcher event, for instance), the workflow should idle itself and wait to be woken from the outside.
How I did this was I created a workflow extension that hosted the FileSystemWatcher. Once the Activity was ready to watch for a file, it created a bookmark and passed it to the extension.
The extension then started the FSW, holding onto the bookmark.
When a FSW event was fired, the extension resumed the bookmark, passing in an object that contained details about the event. The Activity did what was needed with the event, then re-scheduled itself.
Normally I wouldn't have done this, but I had some requirements that forced me to use WF4 to accomplish this goal. If I didn't have to use WF4, I would have just spun up the FSW within the service and consumed the events.
Unless you expect to have to be very flexible with your configuration detailing what you do with the FSW event, and expect this to change relatively often during deployment of the service, I'd skip WF4.