What is the best way to get error messages from a WF4 workflow back to a hosting ASP.NET MVC application? I need the workflow to not terminate, but continue to be active, and then pass a message back to the hosting app regarding the error, so the user can take an alternative action, but I'm not sure how to do that.
In order to keep your workflow alive you need to catch the exception in your workflow. Add a TryCatch activity to you workflow and in a Catch block you can use either a Send or a custom activity to send the data to the host application.
The one exception is to use the WorkflowApplication.OnUnhandledException with persistence and specify abort. In that case the in memory state of the workflow is just removed and the workflow can be reloaded for the last persisted state. If you go this way you need to make sure, using the Perist activity, that your workflow is saved whenever something that cannot be redone.
TryCatch is not really enough when it comes to WF4. Also, handling the UnhandledException event from your workflow host doesn't really tell you much about which activity failed and why.
A suggested approapch is to use TryCatch and Activity tracking within WF4. A good summary of this can be found here: http://msmvps.com/blogs/theproblemsolver/archive/2009/11/27/trycatch-activity-in-wf4.aspx
You can extend your workflow host with Tracking participants and with a catch handler that encapsulates your activity that might fault, handle the exception and create a new TrackingRecord that can better illustrate what happened.
Related
I am relatively new to mule and Im wondering if there is a built in error notification if there an error on a mule flow or if this can be set up in the mmc to trigger an alert if something is wrong with the flow. Please advise.
Thanks and Have a good day!
You can do it in several ways.
The MMC can do log analysis send an email if matches a certain pattern.
You can simply had an exception handling in the flow like a Catch Exception and do the send of a mail there, I wrote a blog post having has sample this case
You can use mule notification system to create a java class that will manage this notification, maybe using log4j SMTP appender to easily send notification mails.
This are my opinion about the 3 methods
First method relies on the mmc being up, mmc creates load on your mule server anyway by making calls and in some production environnement it may be disabled depending on the internal policy of the company. Furthermore if for some reasons goes down you will not receive any notification so you also need to make sure your mmc stays high available. Not an option for me.
I find this method the most appropriate as is it similar to standard exception handling in programming. Manage your exception when you need to and never let them pass silently. When needed send some via mail.
This approach is not bad but not my favorite because lot of times you will see "fake exception" coming in that you need to filter. One example is when a client stops the connection to mule (closing the browser for example) you will get a socket exception that mule cannot write back, this is totally normal and I don't think you want to be spammed by this kind of mail. If you really want to use this system than keep in mind you will need to filter non critical exceptions.
Hope this helps
I am implementing an event store. I have defined a SaveEventsConsumer that handles the storage of events in the event store. If I understand correctly CQRS commands should have no response. Nevertheless, there can be concurrency problems when saving events to the event store. I use RabbitMQ. Should the client be notified so it can notify the user for example? How should it be implemented? Using RPC and an error format?
My first approach is:
Client use RPC like style. SaveEventsConsumer notifies the client (success or failure). If an failure occurs (e.g. concurrency) return the exception to the client.
Is this solution aligned to the CQRS pattern? Is a good approach? Is there any other approach? Is there any improvement? Should I use any AMQP header or property to indicate the error (mimicking HTTP error codes)?
Example, in a cluster:
Two instances of the same application modify the same aggregate. These intances should coordinate (externally to the event-store) or is the event-store which has to detect and notify the response?
While it is true you don't return values from a command, an exception can still occur. A concurrency exception is one example. This implies the exception is thrown as part of the processing of a command. This makes sense when you think about it. You don't ever want events published which have not yet been committed to the event store. It follows then that concurrency conflict checking needs to happen as part of the overall command process.
I have a post which may help. You can find it here.
I have a saga that does a bulk import by creating a bunch of commands (It keeps track of the # of commands sent) then listens to an event indicating the task succeeded. I would also like to be notified when the command fails (moves into error queue).
I want to take advantage of nservicebus's retry functionality so I don't want to simply wrap it in a try catch, I really only want to publish this event when it is moving to the error queue.
Is it possible to create another end point that handles the generated commands but listens to the error queue? Or is there another better way to accomplish this?
You can take control over how the exceptions are handled using a custom fault handler
I have a feature I'm attempting to implement using NServiceBus but not sure the pattern to use here. (I'm fairly new to NServiceBus)
I'll try to explain where my uncertainty comes from:
User interaction triggers MVC controller to send a command to perform a domain operation. This command raises an event to notify others that this occurred.
A handler that subscribes to this event determines whether or not another domain operation should occur.
This is where I'm unclear as to the proper pattern to follow. At this point should the event handler:
just make the changes required?
send a new command to do it? If so, send it back to the originating service/process?
another option?
Part of me is wondering if I should be using an in-proc domain event to handle this, but I don't think the first command should have to wait on the second one before it returns. In fact it could happen much later. That is why I went the route of using the bus to handle it async. Also, an email will need to be generated once the second operation finishes. Should that be triggered from yet another event/command?
Any and all guidance appreciated.
If there is no need to wait for the second action then yes, it should be done asynchronously so the processing of the first command should publish an NServiceBus event. The handler for that event would (likely) be hosted in a separate endpoint which would then just do the work - no need to send another command there.
To add to Udi's answer, I would only turn around and send a command back to the originating service if the service at the originating endpoint is really the one that should be responsible for the behavior of that command. Otherwise, the service (endpoint) receiving the event should just do what it needs to do in response to the event (which sounds like your case).
I have a WF4 service that emulates a sales funnel. It works by starting with a "Registration" receive call. After that, there are 10 similar stages (comprised of a 2 receives at each stage). You can't advance past a stage until after the current stage validates the data received. What I'm unsure about though is, even though my client app wouldn't allow for it, how can I make my workflow prevent anyone from calling the receive operations out of order? In my test console app, I let the user call any receive operation (just because I wanted to see what happens).
For example, if I call the Register first and then the "AddQualification" receive before the "AddProspect" receive, the test app returns with an exception like this:
Operation 'AddQualification|{http://tempuri.org/}IZSalesFunnelService' on service instance with identifier '1984c927-402b-4fbb-acd4-edfe4f0d8fa4' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees
2 things come from this that I don't know how to do:
First, how do I handle the Fault Exception to notify the client in a meaningful way and...
Second, because I'm using persistence (and property promotion), when I make the out of order call, the properties that are promoted unload. They are not promoted again after the client gets the exception.
Any thoughts?
Sorry, my server is playing up a little so the blog keeps going off the air temporarily.
With regard to your second question, you need to make sure that your workflow service is set to Abandon for unhandled exceptions. Here is the doco for AppFabric for this setting:
Abandon. The service host aborts the workflow service instance in memory. The state of the instance in the database remains “Active”. The Workflow Management Service recovers the abandoned workflow instance from last persistence point saved in the persistence database.
Abandon and suspend. The service host aborts the workflow service instance in memory and sets the state of the instance in the persistence database to “Suspended”. A suspended instance can be resumed or terminated later by using IIS Manager. These instances are not recovered by the Workflow Management Service automatically.
Terminate. The service host aborts the workflow service instance in memory, and sets the state of the instance in the persistence database to “Completed (Terminated)”. A terminated instance cannot be resumed later.
Cancel. The service host cancels the workflow service instance causing all the cancellation handlers to be invoked so that a workflow terminates in a graceful manner, and sets the state of the instance in the persistence database to “Completed (Cancelled)”.
Abandon is the only setting that will hold onto your workflow in the persistence store so that you can then call it again.
Hope this helps.
Regarding your first question I'd look at Rory Primroses post on how to shield Content Correlation Failures: Managing Content Correlation Failures. In here he translates an exception into a valid Business Exception.