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
Related
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.
I am writing a web application in ASP.NET 3.5 that takes care of some basic data entry scenarios. There is also a component to the application that needs to continuously poll some data and perform actions based on business logic.
What is the best way to implement the "polling" component? It needs to run and check the data every couple of minutes or so.
I have seen a couple of different options in the past:
The web application starts a background thread that will always run while the web application does. (The implementation I saw started the thread in the Application_Start event.)
Create a windows service that is always running
What are the benefits to either of these options? Are there additional options?
I am leaning toward a windows service because it is separated and can run on a different server (more scalable) as well as there is more control over when it is started/stopped, etc. However, I feel like the compactness of having the "background" logic running in the process of the web application might make the entire solution more understandable.
I'd go for the separate Windows service primarily for the reasons you give:
You can run it on a different server if necessary.
You can start and stop it independently of the web site.
I'd also add that it could well have some impact on the performance of the web site itself - something you want to avoid.
The buzz-word here is "separation of concerns". The web site is concerned with presenting the data to the user, the service with checking the integrity of the data.
You can also update the web site and service independently of each other should you need to.
I was going to suggest that you look at a scheduled task and let Windows control when the process runs, but I re-read your question and noted that you wanted the checks to run every couple of minutes. The overhead of starting the process might be too great in this case - though some experimentation would probably prove this one way or the other.
If you use a scheduled task there's also the possibility that you could start the next check before the current one has finished - something you can code for if you're in complete control.
Why not just use a console app that has no ui? Can do all that the windows service can and is much easier to debug and maintain. I would not do a windows service unless you absolutely have to.
You might find that the SQL Server job scheduler sufficient for what you want.
Console application does not do well in this case. I wrote a TAPI application which has to stay in the background and intercept incoming calls. But it did it only once because the tapi manager got GCed and was never available for the second incoming call.
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.
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.