I am wondering, very generally, about the feasibility of a WF solution in an application, where the business owners want extensive reporting capabilities on application state and data.
The main issue that I see is that WF tends to hide data, such as a recipient list, that is serialized inside the workflow instances, so it can't be reported on, in a way I'm aware of.
On the other hand, if the instance data is written out to an external resource such as a sql table, then haven't you just given up your ability to change that part of the workflow at will (taking away a major selling point for WF)?
In WF for .Net 3.5, I understand the SqlTrackingService can provide raw data about Workflow instance events, Activity events, and User events. But, I wonder about the scalability of logging a lot of instance data, in the activities, to User events. Also the schema I see that the SqlTrackingService uses looks like it would be hard to maintain a reporting solution on, especially if there are updates to the workflow over time. Am I wrong here?
So, has anyone out there successfully used WF when reporting was a major concern? If so, I'd like to hear about how it was done, if WF was isolated to only certain parts of the app (having data not applicable for reporting), and so on...
Perhaps, this is just a question about reporting in a BPM solution in general, as well...
EDIT:
I've accepted Maurice's answer because he took the time to answer it, but I'm still interested in any other opinions on this!
Using the SqlTrackingService in combination with tracking profiles is quite performant, specially when you enable transactional logging. Basically you want to use the tracking profile to only track events you are really interested in. You can also tell it to extract and log specific pieces of user data.
The main way to retrieve the data is not through SQL, although that is possible and for some queries like give all workflows executing a specific activity, but the SqlTrackingQuery class. This will also deserialize the additional user data.
Related
Our company has a new big project all about work flows. (like user registers a request then operator1 should check then send the request to operator2 and after that send a continue message to user and then users completes his own first request and then it continues 20 levels until it is finished.)
because these types of work flows are a lot in the project and all of them may change many times later so I have to use work flow technology to handle this complication easier.
2 ways I know I can make this work flow:
way 1) I can use Microsoft Workflow 4 technology and and add a workflow project to my solution and make the work flow there and its versioning and other stuff.
way 2) I can make my own Workflow thing. make a graphical user interface for it and store activities in db and then make the versioning thing and then my project works with my workflow.
And now my question is this:
making my own workflow sounds easier for me (although I have to make every thing from scratch my self, the GUI and the behind coding, versioning and other stuff) because I can control it easier.
but using Microsoft wf4 I don't know. I have red all about it for 2 weeks now but I haven't understand it quite well. I know how to make a costume Activity and Bookmarks and stuff with it but I think using it will be a burden because I think at the end I have to make every thing my self and store Bookmarks and user progress level in db my self.
Tell me this guys: Is it good to make my own workflow system? Can I make everything that Microsoft wf4 does? Suggest any thing. I just need Advice. Thank you very much.
WF4 is a bit tricky to learn.
I've used it and taught it for years and I find the best thing is to use it as a router to external classes.
Then you can take advantage of its strengths which are; persistence over long periods, versioning (easy if you load the xaml external files/database) and the design GUI.
Why reinvent something that already works.
Basically, I have a new desktop application my team and I are working on that will run on Windows 7 desktops on our manufacturing floor. This program will be used fairly heavily as it gets introduced and will need to interact with our manufacturing database. I would estimate there will (eventually) be around 100 - 200 machines running this application at the same time.
We're lucky here, we get to do everything from scratch, so we define the database, any web services, the program design, and any interaction between the aforementioned.
As it is right now, our legacy applications just have direct access to a database, which is icky. We want to not do that with the new application.
So my question is, how do I do this? Vague, I know, but basically I have a lot at my disposal here, and I'm not entirely sure what the right direction to go is.
My initial thought, based on what I've perceived others doing, is to basically wall off the database by using webservices. i.e. all database interactions from the floor MUST occur through the webservices, providing a layer of security by doing much of the database logic behind closed doors. Webservice calls are then secured to individual users via Active Directory.
As I've found though, that has some implications of its own... We have to abstract the data before it reaches the application. There's still potential for malicious abuse by using webservice calls repeatedly to ruin or spam data. We've looked at Entity Framework and really like what it provides, but as best I can tell, that's going to be unavailable by the time we're at the application level in this instance.
It just seems like I can't come to a conclusion on what is "right". So, what is right?
WebServices sounds like a right approach. Implementing a SOA-oriented layer on the webservices layer gives you a lot of control over what happens to the data at the database server.
I don't quite share your doubts about repeated calls doing any damage - first you can have an audit log of every single call so that detecting possible misuses is obvious. But you also could implement a role based security so that web service methods are exposed to users in roles, which means that not everyone will be able to call just any method.
You could even secure your webservices with forms authentication so that authentication is done against any datasource, not only the active directory.
And last thing, the application itself could be published as a ClickOnce application so that it is downloaded and executed from the web page and it automatically updates itself just as you publish new versions.
If you need some technical guidance, I've blogged on that years ago:
http://netpl.blogspot.com/2008/02/clickonce-webservice-and-shared-forms.html
My suggestion since you are greenfield is to use an API wrapper approach with Servicestack.
Check out: http://www.servicestack.net/ServiceStack.Northwind/
Doing that you can use servicestack authentication, abstract away your db layer (because you could move to a different DB provider, change its location, provide queues for work items etc...) and in time perhaps move your whole infrastructure to an internal intranet app.
Plus Servicestack is incredibly fast, interoperable with almost any protocol you through at it, and provides for running it through MONO, so you are not stuck with a MS backend that could be very expensive.
My two cents. :)
First of all this question is not appropiate for StackOverflow, you might get close-votes really quickly.
Second, You may want to have a look at WCF RIA Services for this.
These will allow you to create basic CRUD operations for all your entities, and stuff like that.
I never used this myself, no I'm not sure what the potential issues might be.
Otherwise, Just do what we did:
Create generic (<T>) interfaces and services and contracts and everything. This will allow you to adapt your CRUD functionality in your Services, DAOs, ViewModels and such to any entity type.
I'm looking for input on a direction to take for building an accounting application. The application needs to allow for high customization, sometimes entire processes will need to changed.
I want a way to make changes without re-compiling the entire application when a customer has a specific modification request. The back-end will be a SQL database of some sort. Most likely SQL Server Express for cost reasons. The front-end will be C#.
I'm thinking of an event-based system that will have events for when different types of actions, such as entries, are made. I would then have a plugin system that handles the event. I may need to have multiple processes apply in a specific order to the data before it is finally saved. It will need to trigger other processes as well.
I want to keep my base application the same, which works for most customers, but have a graceful way of loading the custom processes that other specific customers have.
I'm open to all suggestions. Even if they are thinking of completely different ways of approaching the problem. Our current in-house development talent is .NET and MS SQL Server. I'm not aware of a software pattern that may fit this situation.
Additional Info:
This isn't a completely blank slate system, it will have functionality that works for a large number of the customers. For various reasons, requirements change based on states and even at the region and town level where customization may be necessary.
I'd like to be able to plugin additional pre-compiled modules. When I started looking into possible options, I was imagining an empty handler that I could insert code into through a plugin. So say for example, a new entry is made to the general ledger that raises an event. The handler is called, but the handler's code is coming from a plugin, which may be my original process that fits 80% of the customers. If a customer wants a custom operation, I could add a plugin that completely replaces the original one or have it add an additional post processing step through another plugin after the original runs. Sort of a layering process I guess.
You could look at Managed Extensibility Framework
It provide rich composition layer features that allow you to build loosely-coupled plugin applications.
Update : sound like you need the pre-defined modules on different geographic areas and using chain of responsibility design patern might help you manage the principle of change.
Sorry no codes provided just throwing my thoughts
Windows Workflow Foundation (WF) (part of the .NET Framework) is a potential candidate for your requirements. It enables various actions, command-lets and script-lets to be composed dynamically so that you can more easily customize different workflows for different users/customers.
WF is used by Biztalk for large-scale systems integration and is hosted in-process by many other applications that require the ability to easily modify the orchestration of a number of smaller tasks and actions.
You might want to start with this tutorial on WF4.
HTH.
It's not just plugins or the way how do you technically resolve that plugin problem, use MEF (+1 #laptop) or something else, You got to put most effort in defining plugin "points" in your application, this is gone be most important eg. where you will put that empty "events" to put your code, or what parameters this events or plugins will have.
For example usable plugin would be in before save event, but you will have to have only one place in application that will save various types of business documents, so you can call plugins there and parameter would be abstract document object.
So you have to think real hard about your system architecture, to be abstract enough for various plugin points, and do that architecture completely, don't do just a part of the system and start coding on that.
I hope that you understood what I meant to say, because English is not my native language.
We are currently building an application that makes use of a non-simple approval process, which involves multiple levels of approval, returning, reviewing, notifications etc..
Because of the said requirement, we were asked to make use of a workflow framework also to facilitate process transparency.
On the prototype we have succesfully incorporated the workflow and it works fine. however, we cannot determine the actions that should be available to the user. For example, I have the following recieve operations: create(), managerApprove(), RAApprove(), ORMApprove().. now if I call them in order, using the correct user name then they will work. Obviously, if I don't call them in order, then it will throw a FaultException because its not in the correct state. Question is, how will I know which functions are available to expose in the UI - say, if its currently waiting for manager approval then just show an approval button for the manager...
As a workaround, I've created another WCF service that retrieves the same data from the database and then determines the correct UI state (which actions can be performed by the user). I think this is a duplication of logic, since that's supposed in the WF already.
Also, if the WF changes then it my seperate WCF service may potentially break. For example, if I switch the approval order in the workflow then I need to update the logic in the WCF service as well. Otherwise, it would show an invalid page state and clicking approve will invoke the wrong method and cause a FaultException.
Any help will be much appreciated... I'm really new to WF4.
UPDATE:
My colleague put my question this way:
What's the best design for a web app that adopts WF?
The main reasons why WF is being considered
- The workflows involved are long running
- Workflows are human workflows - they need to coordinate actions of real people
- Process Transparency
Also, how should the workflow integrate with the UI? - how will the UI know what state in should be in and what pages to show which users?
The workflow itself doesn't expose the information directly. It is there as each pending Receive is a named bookmark and the bookmark name contains the SOAP action it supports as well as the service contract and namespace. The easiest way of getting at this into is by adding the SqlWorkflowInstanceStore to the WorkflowServiceHost and checking the column with the pending bookmarks. It isn't perfect as this will give you the information as it was last persisted which is not necessarily the current state but it has worked for me in a number of applications. Just make sure to set the TimeToPersist to a pretty low value and add some Persist activities in strategic places.
A very simple approach would be simulating the workflow by managing the status of the approvals. Imagine that you have different buttons/pages for different users to approve different stages ("create", "manager approval", "RA approveal", etc) of the approval process. This is a very old school approach.
If you use this approach, you would need to distribute your workflow (logics/process) accross different places (pages). Obviously, this is a downside of this aproach, specially when your workflow changes a lot or your solutions needs to run different versions of a workflow.
If you want to use Workflow Foundation, the easiest way is what Maurice has suggested.
The other option is to use other tools which would scale more and are more flexible than WF. I have used WF (not the lastest release though), BizTalk, and SharePoint.
If your solution requires interacting with other applications, I would recommned using BizTalk.
I will be taking on the role of support for a complex application that is transitioning from the development team. This application is a sharepoint solution that connects to several (7) web services. The development team is rolling off almost immediately and will be available only for small questions.
I'm new to this role so I'm wondering what suggestions you have for me as I take on this large project. What are some considerations that should be made so that the transition to support is smooth and uninterupted?
I've been reading the documentation but I can already see some gaps that need to be filled. The applicaiton is very (perhaps overly) configurable and there is lots of injected code. Stepping through the code is about the only way I can gain an understanding of what is actually happening.
It sounds like you've already got your environment set up if you're able to debug the application, so that's the first thing I was going to suggest in a knowledge-transfer situation. Some general things that I would get from the developers before they depart:
A list of third-party components that the application uses, along with license information and website logins if applicable.
Access to every part of the environment that this thing runs on, both production and development. That means the source code management system, database server(s), etc. It sounds like you have some of these already but make sure you get access to absolutely everything.
If your development environment was given to you "as is" (i.e. you took it over from one of the departing developers, make sure you know how to rebuild it from scratch. They might have a document that describes the process of building a development box, but if not maybe you can get them to show you how to set up a fresh machine.
Three will go a long way towards this, but if setting up a server to run the application is different in any way from setting up a development environment, you'd want to know how so you can diagnose server configuration issues if they crop up, or even rebuild a server. Although this sort of thing may be someone else's responsibility depending on your organization.
Once you have those, you probably want to get some understanding of why the application does the things that it does. That will give you the context you need to understand support and enhancement requests when they come in.
Are the original developers the only source of this information, or are there business people who you will be working with after the developers leave? One of the first things I try to do when starting on an existing application that's new to me is to find someone who knows the business well and have them give me a high-level run-down of the application's purpose in life. From there you can go into more detail on individual components/features/whatever as needed. The business people may be a better source for this information than the developers are, so you may want to try them first.
Hopefully some of that helps.
If you're not the systems admin (as opposed to the SharePoint admin), develop an understanding with them of what tasks you are able to do and what you need of them.
This may include things like stopping and starting services (IIS, Timer Service, etc.) and filesystem and DB monitoring and maintenance. Getting this sorted out up front saves a lot of pain later.
If the sys admins don't have some understanding of SharePoint, educate them. They will need to know what the deal is with things like code deployments.
It's best not to feel my pain.