I've been using WWF for a while as part of an internal call center application (ASP.NET), and while learning it was a good practice in understanding how a state machine based workflow system should work, I am definitely not in love with WWF itself. In my opinion it is:
Overly complex, especially for use within web apps (all that threaded runtime stuff)
Immature (ever worked with that horrible designer?)
Anemic in its current feature set
Does anyone have a suggestion for a better .NET based workflow framework? Specifically, I am looking for the following features:
State machine based (mapping states to available actions)
A focus on user permissions (controlling who has access to what actions)
The ability to run workflows as timed background tasks (for example, to send out reminders for items that have been sitting in a certain state for x days)
That's really all I need. I don't need to be able to "drag and drop" any activities or visually design the flow. I am perfectly comfortable writing actual code once a particular action is triggered.
You could try Simple State Machine. You would have to implement access control and background timers yourself, but that shouldn't be a big deal. SSM was also built out of frustration with WF. There are some other state machine implementations on Codeplex as well. If one of them doesn't fit he bill out of the box, they are open source and should get you close enough.
I wholeheartedly agree with you about state machines in WF - they aren't testable, are too complicated, the threading model is peculiar and hard to follow, and I'm not sure a visual designer could have been more poorly conceived for designing state machines graphically. I think this may be because the state machine concept feels tacked onto the WF runtime, which was designed for sequential state machines, something WF does a much better job with, in my opinion. The problem is that state machines are really not the same animal as a sequential work flow, and should have been given a first class implementation of their own, because the warping of WF to make it seem to support them turned out to be more or less unsupportable, if not actually unusable.
I would stay away from Drools.Net since it's last SVN commit was in September 2007. Looks nice but it seems a bit too risky to make such a big library part of your project when you know it doesn't get any attention anymore.
Try Drools.NET
Have a look at Workflow Engine. It is a lightweight workflow framework for .NET and Java solutions. It has an HTML5 visual designer, version control, a decent UI and supports a wide range of databases.
Do you have the option to consider BizTalk Server?
I quite enjoyed working with Oracle BPEL Process Manager. It's part of JDeveloper.
http://www.oracle.com/technology/bpel/index.html
http://gemsres.com/story/dec06/313602/jellema-fig1.jpg
You may want to take a look at Jazz - http://jazz.codeplex.com/
Try WF4.5. It was completely redesigned since .NET4.0.
First of all you should look for a engine supporting BPMN. BPMN is a standard in Workflow and Process management and well supported from a lot of projects.
Second you should think about the requirements to thus an engine.
When you look for a BPMN Engine, there are two different approaches:
Task-Orientated
These engines (e.g. JBoss BPM - jbpm) are designed to process an input data by a well defined process model. Each task in the model gives the control to a piece of code - either a standard or an individual implementation. The process ends when the process-token reaches the end of the process model (End-Event). This kind of processing takes milliseconds. The engine can be used for batch jobs or processing data with a complex process orientated flow.
Event-Driven
Human-Centric workflow engines are event driven (e.g. Imixs-Workflow). This is a kind of state machine but offers typically much more functionality. You can start a new processinstance by assigning your business object with the initial task (defined by the start event). Than the workflow engine allows you to trigger events assigned to each task, defined in your model. Each event (Intermediate CatchEvent) triggers the workflow engine to transfer the running processinstance to the next task (state). Until no new event is triggered, the processinstance 'waits' in the current task (state). An approval process is an typical example for this kind of human-centric workflow.
You can find a list of engines here.
Related
We currently have a system that handles translation jobs.
customer creates an order
the project manager hands it over to one or more translator
then it goes to a proofreader
language manager checks quality, if bad, job goes back to translator
project manager delivers it to client
Currently all the status can be assigned manually and/or overridden.
Meaning any step can be skipped or set back.
The app is a ASP.NET WebForms / MVC mix.
Now I would like to re-implement this with Windows Workflow Foundation. Would a State Machine make more sense than a Flowchart?
I'm not really getting the advantage of the State Machine...
Given the way you describe the job you are really switching between states. So using a state machine sounds the logical approach. However it would be perfectly possible to do this using a flow chart and that would certainly be easier to explain to business users.
Now the good thing is you can mix and match state machine and flow chart as needed/wanted.
I prefer StateMachine for most scenarios like this. It is definitely possible to do what you want to do. You should spend some time exploring it. You might want to start with Introduction to State Machine Hands On Lab
My team has been tasked with designing a web application that is workflow driven. I need some advice regarding the design.
The workflows need to be dynamic. Meaning, users can define the workflows through some interface and apply those workflows to a given scenario (The definitions will live in a SQL 2008 Database). The scenarios are defined by the business and will never change. So there may be only 2 types of scenarios a workflow can be defined for. The workflows are not necessarily linear. Some sort of state will drive the workflow. States will also be dynamic, but only exist in a workflow.
I have been looking at examples of workflows and state machines and my head is spinning. I am not sure I want o leverage Workflow Foundation or something we develop. I have seen this and think it may work, but I am not sure the state full implementation will work for us.
You can do this using WF4. I have never used Objectflow so I can't really comment on that but it appears to be an in memory solution and with an ASP.NET web site hosted in IIS that means you will occasionally lose state as IIS recycles and AppDomain. Usually not a big problem as it doesn't happen often but a WF4 InstanceStore will take care of that. It will also allow you to run on a web farm without sticky sessions and have the workflow migrate from machine to machine.
Another nice thing is the workflow designer. Its a WPF control you can rehost in your own app. Not in am ASP.NET or Silverlight app but you can provide a smart client to have users update the workflow definition using the sane designer as you use in VS2010.
The biggest problem with WF4 is the asynchronous execution nature. You will need to use a SynchronizationContext to execute the activities and wait for the workflow to go idle in the new state before you return the resulting HTML to the browser.
I know workfow engine is, but actually in our programming life, how can we get use of the workflow engine ?
How will workflow engine help us ?
Workflows like Windows WF allow you to work in a logical process. For instance, you can design a workflow process in Windows WF that drives the application. So the application can work in a logical process from start to end based on the workflow.
Workflows often drive some business model. FOr instance, an application may need to do these things in a logical order:
User submit an application
Notify a business user and automatically schedule a consultation with the applicant
User submits a follow-up application
User receives information packet
And so on... I made that process up, so it's not the most practical, but hopefully it gives you an idea. This is one type of workflow that can be done with Windows WF and other workflow engines, that can help your application utilize a workflow driven business process.
Workflows don't need a tool, but could be simply your process that the application uses to run through a series of screens or processes, so you don't actually need a tool to use workflow; the key component of workflows is the business process.
HTH.
you can write conditions or events in an xml and make it work on the fly. The parameters can be changed without changing the code.
No disrespect intended, but if your looking at using Windows WF, wait for the next iteration with .NET 4.0, the current version has been essentially re-written to alleviate a lot of the pain points.
In addition to what Brian's answer adding few more use cases.
Broadly we can classify workflows into two types: rule-based and cognitive.
This article can provide good insight about workflow automation.
Few example of Rule-based workflow automation engines are: Zapier, IFTTT, Power Automate, n8n etc.
It is very difficult to automate cognitive-based tasks for example: classify customer issue automatically, check documents for completeness, content moderation, visual claim processing, detection whether social distancing been followed or not, signature verification etc.
Cognitive task automation require AI models, automate the task where we need human intervention.
Few example of cognitive-based workflow automation engines are: Levity and Obsei.
Disclaimer: I am creator of Obsei: an open-source low-code AI powered automation tool.
If you're in my position you have a big WebForms applications which have escalated to this unmaintainable thing. Things break when you add new features and you need an inexpensive maintainable way to do some kind of automated testing.
Now, from my understanding, the right thing to do would be to try building an abstraction layout of the page and user control model present in ASP.NET WebForms however, seeing as it would require a major investment in an existing application it is not an option.
I'm trying and pushing for a REST-like development as much as possible because it has some nice properties. And while doing this I've written a simple spider bot that crawls all URLs it can find and tries, simply getting them.
This allowed my to quickly find bad data that was causing problems and avoid having my end-users clicking on broken things, however, this is of course not enough.
I continued work on my crawler and it's developed into a simple REST client that tries different input combination, looking for a probable bug or crash. It's more intelligent that just an exhaustive search (because it knows about the ASP.NET WebForms application layer) and my goal here is to basically explore the state of the web application, hoping to hit all the corner cases before our users.
Does anyone have any experience doing something similar?
Also, for you test gurus out there. Is this a complete waste of time, or will I be able to actually say something about the quality here? From my perspective it seems to hit a sweet spot in that it will try things a potential end user would though a browser.
As I said before, we're stuck in a bad place. And we need a simple way out of it, right now.
We've tried things like Selenium, but it mandates a lot of extra work and we change things all the time, it's just no possible to maintain multiple selenium test suits for 50 different applications.
Of all the types of testing to implement, unit testing is both the easiest and the most likely to yield results, in terms of less bugs and more maintainable code. Get that worked out before you deal with automated integration testing
Pick an IOC Container - I like Ninject for this personally
Find a convenient place to inject "service" classes into your Page (the consturctor of a base Page class or override the module that loads pages, whatever works for you)
Pick a unit test framework and if you don't have an automated build then set one up; include running a full suite of unit tests in that build
Every time you go near a piece of logic in an aspx.cs file, see if you can't isolate it in a service and wrap unit tests around it
Take a look at whether the MVP Pattern would be good for you - we found it decreased productivity as much as it increased testability (it did both a lot), but it works for some people
See about slowly migrating your app over to MVC, a page at a time if necessary
And remember, you are not going to fix this problem overnight, you don't have time. Just keep improving test coverage and you'll see the benefits over time.
What part of your application is breaking? The UI, or the business logic?
Business logic should be completely separated from the user interface, and should be tested separately. In particular, it's much easier to use automated unit testing tools against separated business logic than it is against UI.
If i am rigth you have a large web form and want to run some standard end user tests each time you do a new release.
I can recomend the Selenium IDE adon for firefox.
it will allow you to record your user actions, e.g filling in a form, and allow you to replay those actions at any time. an easy way to run some test over a form with differnt data.
For internal code testing write some Unit tests using NUnit
I am implementing a quite simple state-machine order processing application. It is a e-commerce application with a few twists. The users of the application will not be editing workflows by themselves.
Microsoft claims that asp.net and Windows Workflow is possible to combine. How hard is it to install and maintain a combination of asp.net and Windows Workflow? I would be keeping the workflow state in sql-server.
Is it easier for me to roll my own state machine code or is Windows Workflow the right tool for the job?
Asp.net and WF get along just fine, and WF doesn't add much maintenance overhead.
Whether or not this is the right design for you depends a lot on your needs. If you have a lot of event driven actions then WF might be worthwhile, otherwise the overhead of rolling your own tracking would probably add less complexity to the system.
WF is reasonably easy to work with so I'd suggest working up a prototype and experimenting with it.
Also, in my opinion, based on your requirements, I doubt WF would be the right solution for you.
It depends on your needs. How complex is the state machine? Where do you want the state machine to live (e.g. model vs. database)? WWF provides an event based state machine, which is good enough if your state machine is embedded in the model.
Personally I've implemented an e-commerce framework and other workflow based websites and I've have always had a lot of joy from implementing database based state machines. Always worked without a hitch.
On the other hand, some colleagues of mine prefer WWF.
In any case it works perfectly with ASP.NET.
If your state machine is very simple, then I would say that you should just roll your own. You have more control over everything. You can deal with persistence on your own terms and not worry about how they do it.
WF does look pretty cool though, but I think that it's power probably lies in the fact that it is easy to tie it into frameworks like CRM and Sharepoint. If you are going to use these in your application, then I would definitely consider using WF.
Full disclosure: I am definitely not a WF expert.