MVC Storefront Part 19a: Windows Workflow Followup

Love the series. Where is the download link for this part.

We can't even see the code in this tiny silverlight video.

Please provide a download link...

Random: double click on the video player in the zone of the video and you will get full screen! Then the source code can be seen correclty!

This page crashes firefox for me, I guess it's silverlight. Vista 64 Ultimate FYI :) Love the series BTW !!

Rob, we love that series but your new video player sucks! I haven't got fulscreen i FF3.0. Please give us download link.

The url:

msbluelight-0.agappdom.net/.../video.wmv

Silverlight is still immature. Why don't you just embed the .wmv?

Rob,

Thanks for making WF interesting!

I second @ako74... Love the series... lose the video player.

Is this officially a Friday thing now?

So what about using Workflow to hold the state of the order. For example, I'd love to see you have WF send out an email when an order address is invalid and then let people edit the address, and have WF then move it to the next step. I'm fairly certain that's one of the great features of it and would love to see something like that implemented.

Totally agree with Brian. Please put something in there that we couldn't do easily in code. You said in your video "this took me just 10 minutes to orchestrate" and that's great, but I could've written that in a method in 5 minutes the way Ayende did on his blog - and I wouldn't have needed to spend the 15 minutes you said it took to create the WF actions since the services are already there. Using workflow for sequential "do this then do that" stuff really seems like overkill. What Brian's talking about though might actually be easier in WF and really show off some of its capabilities. Especially if you get some branching in your WF instead of a single path.

This is getting better and making more sense. I get what Rob's saying about this particular workflow not being the best place for user interaction due to the need for it to be asynchronous and "Good Faith Business". But I'd still contend that the checkout process is a good candidate for Workflow- even if it is a separate Workflow. (or, if it is not a good candidate, I don't understand why not =)

In this example, when address validation fails the user gets an email. I can just hear a client asking us to change this so that the user is notified immediately and given a chance to fix the address. Obviously, we could do this in code at the time of checkout, but suddenly the benefit of workflow is diminished because the one change I want to make isn't available in the workflow.

My only other suggestion would be to wrap that dictionary-value-passing wierdness in a class with properties or constructor parameters like nature intended =) Something to allow:

var workflow = new CreditCardSubmissionWorkflow();

workflow.PaymentServiceInterface = _paymentService;

workflow.OrderServiceInterface = _orderService;

...

workflow.Start(runtime);

Rob,

I agree with the rest of the tribe, your selected viewer for the Video doesn't allow us to go fullscreen thus most of the code is lost on us. If you're using Expression Encoder to put your video on silverlight, I've found that the quiksilver template is very nice...the control panel only shows when your mouse is over it and it has the zoom ability. It looks like you're using the corporate silver template which is nice and all but doesn't include a fullscreen button.

Otherwise keep up the great work.

Egads FF and Silverlight aren't good friends are they :). Forgot the download link (now added) - sorry...

>>>So what about using Workflow to hold the state of the order. For example, I'd love to see you have WF send out an email when an order address is invalid and then let people edit the address, and have WF then move it to the next step<<<

This isn't a valid thing to do - if they change the address you need to save the order - so you take two steps back. If you resume "after" validation then you've circumvented your process. In this case I think kicking off the pipeline again is a better choice.

However - to answer your point, this is achievable by using a StateMachine. I went over this with K Scott Allen in the previous episode. StateMachine is event-driven and will persist itself to SQL Server instead of sitting in runtime memory.

I don't need that here - this is a pretty simple process overall.

>>>but I could've written that in a method in 5 minutes the way Ayende did on his blog - and I wouldn't have needed to spend the 15 minutes you said it took to create the WF actions since the services are already there<<<

I think I might have failed again at getting the point across :). Jamie I'm sure that you could easily do this - my point isn't that WF is saving me time coding - what it is doing is:

1) Allowing for an asynch operation

2) Allowing folks who pick up the application to orchestrate the checkout process easily, without spelunking my code

3) Allowing for the sharing of activities

I know it may seem like overkill - but if you've ever tried to code a workflow process you know that it's really, really difficult when change comes in - and managing change is what I'm trying to do here.

I Was able to use the zoom feature in IE to zoom the page thus scaling the size of the video and make the code legible.

Unlike others I like it a lot that you are tinkering with the latest MS technologies. WF seems to make the order process faster to code, simpler to understand and more flexible to customize and reuse. Thank you for doing the beta testing for us!

Here my suggestion:

Many websites require Automated Recurring Billing as part of their checkout process because they offer subscription based content.

You might want to show off the power of WF by implementing a sample that talks to the "Authorize.Net Merchant Web Services API for Automated Recurring Billing". www.authorize.net/.../ARB_guide.pdf

Some real world WF scenarios could be:

How to process delayed payments where we do not charge the user immediately and only want to schedule future recurring payments?

What if the credit card expires before its first scheduled payment?

How do you deal with cancellations?

What do you do when a user wishes to change their credit card associated with their subscription?

The above questions come from an article about how to "Integrate the Authorize.Net Recurring Billing API with PHP" www.merchant-account-services.org/.../1

Would be great to see this example in MVC/WF.

Your videos and explorations into unknown territory are fun to watch. Keep on following your instincts.

Philipp

Thanks Philipp :). Automated billing is indeed an interesting issue - the problem here is that I'm not going to provide functionality for saving a credit card. This isn't a Microsoft thing - it's a me thing :). I know it's necessary sometimes - I just don't want to do it.

That said - I know Auth.net will do this for you, so WF isn't really needed. PayPal too :).

In terms of delayed payment - same thing.

Cancellation would be it's own pipe :) - lots of "if's" and emails, refunds if paid, etc. I'll add that in as well.

Thanks for the thoughts...

Excellent work as always Rob - thanks for the work you put into these videos. =)

Hi Rob, first thanks for all your work you offer to the community. Just FYI www.asp.net has changed the location of mvc infos to www.asp.net/.../mvc-videos - so the link under "Index Of MVC Screencasts" points no longer to the right place.

OK, so this is a better post, I think this should of been really what the first post was, as you said - you spent a lot of time focusing on WCF and not why.. your first post really illustrated that you could 'design' a sequence of code that you could of done just the same in code..

Showing us the transact ability and exception / result handling, and how easy this can be to architect with the designer..

Still wondering if using WF inside an asp.net app is a good thing, I kind of think that the solution is being pushed all inside a web application, where the solution is really more suited to be multiple systems..

This really comes from component reasoning, the role of the web app should be to a catalog and portal to creating an order.. but not really that it handles processing that order.

Of course this all depends on the scale of the solution, but to me the way you are building this solution is more as a reusable infrastructure.. vs this actually just being a solution for a client as you were orignally suggesting..

another good screencast. ..and I'm finally caught up on this series. yeah!

@Stephen

I never got the impression that this was for a single client. Rob's major driving force for using WF for this is for ease of customization from user to user.

This is definitely interesting from a technical/coding perspective, but I have to say I don't really buy the premise that doing all that validation in the workflow represents "good faith business". Thinking as a user of an eCommerce app, I would much rather be told about validation issues (credit card, address, etc.) up front than to be told "Thank you, we got your order" - as if everything was fine - and then get an email later saying that something is wrong.

In fact, I can't really think of any sites I've used that work that way (at least as far as I know). If I place an order on a site and am told "Thanks - we got it" I expect that the order will be fulfilled. If I get up and walk out the door and don't check my email until tomorrow, and then find out that my credit card info was wrong, I'm going to be none-too-happy to have to go back to the site to correct it when I could have been told that up front and corrected it right away. Especially knowing I've now just lost a day in shipping time. And maybe the item is now out of stock. That smells of bad business practice to me, not "good faith business". Does anyone else feel that way or am I missing something here?

Hi Kevin - It does make good sense to be told up front, however (as we've mentioned above) it's a scaling nightmare. If your site has a small audience then it doesn't matter much as the hits to external validation services might be quite fast. If you start getting a lot of transactions a day (lucky you!) then you have an issue.

Many large sites do just this (most airlines, online suppliers like NewEgg and Dell...) and you'd be surprised how often it happens. I would guess that the reason you can't think of any is that you probably enter valid information most of the time :). Have you worked on a high-capacity site?

All of that said, I just added in a new Pipeline Engine called the "CodeEngine" that does all of this synchronously - so you can pick your poison :) and easily switch it when needed.

Hey Rob,

Just an idea, how about using the WCFServiceHost when using the WF, it makes the whole process of workflow very simple, since it hides out the whole workflow runtime stuff, all you need to do is create an interface for your workflow, and everything's done for you as a WCF service.

This also adds much better functionality such as durabiliy (coz of WCF (when you use MSMQ)