I have a web application that I am adding workflow functionality to using Windows Workflow Foundation. I have based my solution around K. Scott Allen's Orders Workflow example on OdeToCode. At the start I didn't realise the significance of the caveat "if you use Delay activities with and configure active timers for the manual scheduling service, these events will happen on a background thread that is not associated with an HTTP request". I now need to use Delay activities and it doesn't work as is with his solution architecture. Has anyone come across this and found a good solution to this? The example is linked to from a lot of places but I haven't seen anyone else come across this issue and it seems like a bit of a show stopper to me.
Edit: The problem is that the results from the workflow are returned to the the web application via HttpContext. I am using the ManualWorkflowSchedulerService with the useActiveTimers and this works fine for most situations because workflow events are fired from the web app and HttpContext still exists when the workflow results are returned and the web app can continue processing. When a delay activity is used processing happens on a background thread and when it tries to return results to the web app, there is no valid HttpContext (because there has been no Http Request), so further processing fails. That is, the webapp is trying to process the workflow results but there has been no http request.
I think I need to do all post Delay activity processing within the workflow rather than handing off to the web app.
Cheers.
You didn't describe the problem you are having. But maybe this is of some help.
You can use the ManualWorkflowSchedulerService with the useActiveTimers and the workflow will continue on another thread. Normally this is fine because your HTTP request has already finished and it doesn't really matter.
If however you need full control the workflow runtime will let you get a handle on all loaded workflows using the GetLoadedWorkflows() function. This will return acollection of WorkflowInstance objects. usign these you can can call the GetWorkflowNextTimerExpiration() to check which is expired. If one is you can manually resume it. In this case you want to use the ManualWorkflowSchedulerService with the useActiveTimers=false so you can control the last thread as well. However in most cases using useActiveTimers=true works perfectly well.
Related
I am going to use Laravel 4 queues and integrate them with Iron.io
All of that is pretty straight forward, and I dont think I am going to have problems with that.
Thing that interests me is what is the best way to get status once task is completed?
Iron.io is going to do return call to my server to trigger job, and once that job completes I need to notify user about that...
How could I store this responses, and still be aware of job its related to, because there will be number of different job types?
I would like to hear how did you implement this.
Thanks
As Joseph pointed out in the comments, you'll need to:
Hopefully have a job quick enough for it to be finished when a user is still in browser
Use some sort of way to PUSH data back to your web browser.
The popular methods are:
Websockets
Server-sent events
Long polling - with ajax
In the old days, when each request to a web application was handled by one thread, it was fairly easy to understand the logs. One could, for example, use a servlet filter to name the thread that was handling a request with some sort of request id. This request id then could be output in the logs. In this world, a simple grep was all it took to collect the log lines for a given request.
In my current position, I'm building web applications with Scala (we're using Scalatra but that isn't specifically relevant to my question). Each request creates a scala.concurrent.Future and is then parked until that future has completed. The important bit here is that the thread that actually handles the business logic is different from the thread that handled the request which is different (I think) from the thread that completes the request and so the context of that request is lost during processing. The business logic can log all it likes but it is hard to associate that logging with the specific request it relates to.
Now from the standpoint of supporting my web services in production, the old approach was great and I'd like to come up with something similar for my asynchronous services. I've been trying to come up with a way to do it but have come up empty. That is, I haven't come up with anything nearly as light weight as the old, name-the-thread model. Does the Stack Overflow crowd have any suggestions?
Thanks
As you have written, assign an id to each request, and pass that to the business logic function. You can also do this with implicit parameter, so your code won't be cluttered.
This should be possible with MDC logging available with SLF4j which uses Thread local storage to store the context of the each request.
Also you will have to create a MDC Context Propagating execution context, to move the context across threads.
This post describes it well:
http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
We have a main ruleflow which calls 8 more rule flows (Rule1.rf to Rule8.rf) through an AND splitter. One of the rule flows - say Rules4.rf - is fired sometimes and not fired sometimes.
This is for an online application and we use jBoss. When the server is started, everything works fine. After many hours, for some requests, Rules4.rf is not fired at all and for others, its fired properly.
We even posted the same request again and again and the issue happens some times only. There is no difference in the logs between the success & failure requests, except for the logs from the Rules4.rf which missing in failued requests.
We are using drools 5.1 and java 6.
Please help me. This is creating a very big issue.
It is very difficult to figure out what might be going on without being able to look at the actual code and log. Could you by any chance create a JIRA and attach the process and if possible (a part of) an audit log that shows the issue?
Kris
I have an iPad app that works both on and offline but when I am offline there are web service calls that will need to be made once online availability is an option again.
Example:
A new client is added to the app, this needs to be sent to the web service but since we are offline we dont want to slow the user down so we let them add locally and keep going but we need to remember that that call needs to be made to the web service when we can. Same thing for placing orders and such.
Is there some sort of queue that can be setup that will fire once we have connectivity?
I don't think the overhead of a heavyweight tool like MSMQ is needed for a simple action. You can use Core Data, persist managed objects with the data needed to call the web service, and only delete each managed object after a successful post. There might or might not be a way to capture an event when connectivity starts, but you can certainly create a repeating NSTimer when the first message is queued and stop it when there are no messages in the queue.
This library handles offline persistent message queueing for situations like you describe. It says alpha from a year ago, but I have confirmed it is used in production apps:
https://github.com/gcamp/IPOfflineQueue
I'm building an app that deals with customer queries, where I want to route the query through a decision tree showing appropriate views before taking some automated action against their query. Kind of like the game "20 questions"! Based on the answers at each stage, the path through the app will change.
I was thinking of using MVC, because there are only a few "types" of route and outcome - so I could build fewer pages that way, one to handle each type rather than one for each step. I was also thinking of using Workflow 4 to manage the page flow, because the flowchart model maps pretty nicely to what I'm trying to do.
Does anyone know any good reference apps that use Workflow for this kind of thing?
Thanks
Richard
There where a number of examples using WF3 doing this sort of thing but I haven't seen any for WF4. I suppose it is possible to do but it means running the workflow synchronously and checking the bookmarks as soon as it becomes idle to see which operations are enabled at the moment. That should be possible using a custom SynchronizationContext that does things synchronous and using the Idle callback on the WorklfowApplication to check the current bookmarks.
I actually went with a different option in the end - I wrote a "GetNextAction" function that returned an ActionResult object based on my flowchart logic and state of objects. The controller processes whatever form inputs it's received, updates the object, then calls GetNextAction and returns the result of that function. Seems to be working out ok!