Showing posts with label asp.net mvc. Show all posts
Showing posts with label asp.net mvc. Show all posts

Friday, January 20, 2012

Task based workflow with NServiceBus and SignalR

Project365.4:  Conveyor Belt Sushi
Over the last six months our team has been working on breaking our system down into a whole lot of distinct, reusable components. Most of the work is completely automated, but there is always the case where we need some human input.

For each of these scenarios we've created very specific task based UI's, so we can taylor the screens to the exact need of the task. This has meant that we've been a lot more focused on solving a real business problem rather than just trying to jam as much information on the screen at once.

Up to this point, each task has been very distinct from the others, without too much consideration of the workflow that would really take place. There are a couple of options for how the tasks could be completed:

  • Task centric users who complete just one type of task, and who don't particularly worry about the work flowing from their action
  • Customer centric users who might need to call the customer to get some extra details, and are very interested in the way the rest of the work flows, as they want to be able to get all the information required to complete the whole transaction while on the phone. 
Our system currently supports task centric users, but we need a solution to customer centric solutions. For that, I had seen and heard a bit about SignalR:
Async signaling library for .NET to help build real-time, multi-user interactive web applications.

Along with listening to Hanselminutes, one of the posts that got me started was push notifications with nservicebus and signalr, which was right up my alley as we're using NServiceBus as our underlying infrastructure for messaging. The only difference in our project was using MVC3 for the web app, so I avoided the EventStream and created a class implementing SignalR's Hub - which was super easy.

I got a bit confused about how to get the Clients who are connected to my implementation of the Hub, but this stackoverflow answer from David Fowler helped me get the clients, so I could start notifying away!

Within a day I had a working notification system working! It definitely requires more refinement to make it more useful to our users, such as only notifying some people of the changes (trying to identify who 'owns' a transaction and wants to see further tasks) and some UI design to make things a bit friendlier, but it's definitely been really fund and easy to work with.

If you're working with task based UI's how do you create customer centric workflow?

Thursday, April 7, 2011

Raven DB & ASP.NET MVC routing

I've experimented a little with Raven DB, and have done some integration with ASP.NET MVC 3 (cause it's so easy to get things started).

The first problem I came up against was the default way that RavenDB stores the object keys :
profiles / 3074 (Profiles)
This presents a problem when you want to work with the MVC routing, which uses the '/' symbol in the routing - {controller}/{action}/{id}.
public ActionResult Edit(string id)
MVC interprets this as wanting to send the id (id e.g. 3074) to the action (object e.g. profiles). Instead, we want to pass the whole string (profiles/3074) as the id to the controller action (Edit).

To start, we need to change the type of id to string, as it defaults to int. Secondly, we need to change the format of the object key - there are other ways of attacking this problem, but I found changing the default separator from '/' to '-', this happens when you initialize the document store shown below
var documentStore = new DocumentStore { Url = "http://localhost:8080/" };
documentStore.Initialize();
documentStore.Conventions.IdentityPartsSeparator = "-";
We end up with documents in our store looking like this, and passing through to the correct controller!
profiles-6146 (Profiles)