I'm currently working on a project where we want to implement a WF4 state machine as a workflowservice. The fundamentals seem to make sense as we've used WF 3.5 in the past. However one issue we've come across is that we'd like to be able to create an instance of the workflow at any of states (or at least more than just one of them). Selecting the CanCreateInstance property on more than one Receive activity throws an exception.
I've played around with Maurice's suggestions on correlation from his blog but haven't been able to figure out how to apply that to a state machine.
We have a sample that might help you Windows Workflow Foundation (WF4) - Silverlight / State Machine Workflow Service
Related
I don't usually program in the .NET framework however I've needed to use it to create a simple exe application that logs data from some measurement equipment. I want this application to have an automation interface with a couple of methods. I've done this before using Delphi/Pascal and it was very straightforward, and I can create a Class Library in Visual Studio that registers itself and the methods and can easily be interfaced with but adding a ComClass to the windows form application doesn't work, can anyone point me in the right direction?
This started as a comment but just kept growing, hopefully i am not off track ...
You can only register a dll. So the short answer would be to add a class library to your project and put the com class in there. This would allow you to share the functionality of the class, but not the same instance of that class.
I think your problem is that you are trying to establish Interprocess Communications. My immediate suggestion is not to do that, at least at first.
For a start you could have your com app interface with a .net class library which would log data. You could then have another project with a .net executable that displays the log, and updates periodically. Now you have .net code on both sides of the fence and can start investigating ways to get them to talk to each other.
The hard part is invoking methods and returning values. If you really need a responsive system you can investigate named pipes inter-process communication, or using a WCF service with callbacks between the two systems. The problem is that in either case you are hamstrung by the class library not being hosted by .net so you have limited functionality (no config file etc). If you can put up with a time lag I would suggest simply starting with writing messages to a local datastore and then polling from each client, every 30 seconds or so. For example the app would create a message saying "give me measurement A" and then start polling every second. The DLL would have a timer and within 30 seconds would read that message and write its own message with the measurement, which the EXE would read and then display. Once you get that system up and running you can decide whether you need to tackle inter-process communication, which is really just a different interface.
I've been digging into the technical details and implementation of Windows Workflow 4.5 as a beginner and having decent results. My question is more of a "why and when" vs. a "how to" question so bear with me.
I've taken a familiar concept to us all and abstracted the business logic into WF, namely the universal log on process. What I wanted to accomplish is having reusable logic that I can call from an MVC website, a Windows Forms application, etc. and have everything run through the same workflow and I have achieved that.
Now I have 2 conceptual questions as to "when" to apply WF and when to use code.
1 - Take simple validation as an example. I'm trying to login but I've passed an empty user name or password string. Obviously, I want to send a message back to the end-user "UserName Required" and "Password Required", which I've done. Now, the way that I did that is I have a validation class (FluentValidation NuGet package if it matters) but the important thing is I'm doing this in code. So, in WF I call my validation code via an ExecuteMethod and everything works just fine. My question is: Is this the wrong approach with a WF mindset? Should I be doing inline WF "If" Actions/Decisions and building up the validation messages inside of WF directly versus calling out to some chunk of code? I'm asking not just for validation but as a concept we can all relate to but more generally should I be attempting to put anything and everything I can into WF itself or is it better to call custom code? I'm looking more for best practice with reasoning from seasoned Software Architects with WF experience versus someone's opinion if possible.
2 - Picking up a workflow on another machine. So, part of the same login workflow activity requires a service method call. I've written the code and workflow in such a way that the workflow receives an In parameter of ILogOnService which has an interface method "AuthenticateUser". The concrete implementation I'm passing in calls out to an MVC4 Web Api post method, in async, to do a standard Asp.Net membership ValidateUser. Again, should I be calling this Web Api PostAsync from inside the WF workflow? If so, doesn't that tightly-couple my workflow to Asp.Net Membership and my particular service choice. It seems there are ways to get the workflow to a certain point and then resume the process on another machine, e.g. where a service is running, and continue the process but I'm not able to find good examples of attempting that.
Just looking for some guidelines and ideas from the pros at this technology but I will pick the most informative answer.
There is nothing wrong with using C# code to implement details of a workflow. In fact I always tell people that if they are using WF4 with just the standard out of the box activities they are probably doing things wrong. You really need to be creating, or have someone else do it for your, custom activities that model business activities for your business. Now if that means creating an activity that validates a login using the FluentValidation that is perfectly fine. Another time you might build a higher level business activity out of lower level WF4 activities, just combine them as works best in your case.
Calling a service with something like PostAsync can work well if you know the action is short lived and is normally available. However when you get into SOA styles you really want to start using temporal decoupling so one service is not dependent on another service being available right away. And when you get into temporal decoupling you really want to be using queues, maybe MSMQ or maybe another similar technology. So in that cas you really want to send a one way message with a response queue and have to workflow go idle and wait for the response message to arrive. This would reload the workfloe, possibly on another machine. Now that might not always be appropriate, for example in your login it would not be much use to grant the login a day later because the membership service was unavailable, but can result in very scalable and fault tolerant systems. Of course there is no free lunch as these systems are very hard to design properly.
I have a Silverlight 5 app. This app has been in development for 18 months. This app calls back to a WCF service. I just had a support request.
Before today, the service would return ObservableCollection<T> results. However, now all of the sudden, out-of-the-middle of nowhere, it starts returning T[] results after I updated the service reference in the Silverlight app.
My question is, what could have happened that would cause this change? This has caused approximately 70 errors due to type conflicts. Am I overlooking a basic setting?
Thank you!
If you're using a service reference to communicate with the service, make sure the Data Type hasn't been changed. Right click on the service in the Service References folder, select Configure Service Reference..., and look at the Data Type - Collection type:. If it's System.Array, then this may be your problem. Change it to ObservableCollection and see if that helps.
I am working a project where i need to create a state machine work flow in 4.0. I have installed .net framework 4 platform updates and i am able to get state machine and states in toolbox to work with.
I have created a WCF workflow service application. I have currently 3 states in this.
State1 which executes a extenal process.
State2 which updates a database.
State3 populates some entity class.
Each state will be having a receiveandsend activity. I need to trigger each states individually from client. Cancreateinstance of each receive activity is made true.
I have to call this from a silverlight application. So i have added the service referance to this workflow in silverlight application.
when i execute the first state, its works fine and external process is executed.
But when i try to execute the next state by calling the next receive activity from client, its showing error as below.
"Operation 'ExecuteExternal|{http://tempuri.org/}IService' on service instance with identifier '4732d197-32c0-4591-87bc-fa0adb7ec43a' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees."
I think the WF is not waiting after first state is finished. Can anyone help me to solve this?
Your state machine is not waiting for the message that you are sending. The best way to troubleshoot this is with tracking. I've added a behavior that will help you to Microsoft.Activities. See my blog post Using Workflow Services and Silverlight Together
Working with Correlation handle helped me to solve this issue.
Please find the answer in the below post
http://social.msdn.microsoft.com/Forums/en-US/wfprerelease/thread/6a7d9069-d5a7-4410-b5dd-16325d0d8dc9
In the app I'm currently working on we are using a couple of WCF services with a lot of methods. Until now, all methods are very short running, often just getting some data. I've just added a method that takes a way longer time to run.
I do not want to raise the timeout in the config, because 1 minute is long enough for all other methods on the service.
What is the best way to deal with 1 longer running method? And how do I provide feedback that it is still running?
A long running task should really be farmed off as an asynchronous call, that could then be polled for status (or an event through a duplex connection). For a really long running task, you might even want to push it into something like Windows Workflow.
Combining WCF with WF (Workflow Foundation) seems like the best option here. Workflow Foundation gives you lots of goodies, including long-term persistence over the lifetime of your long-running process.
In .NET 3.5, it's possible to do so, but clumsy and a lot of work.
Here are a few links for this topic:
http://channel9.msdn.com/posts/mwink/Introduction-to-Workflow-Services-building-WCF-Services-with-WF/
http://code.msdn.microsoft.com/WorkflowServices
http://msdn.microsoft.com/en-us/magazine/cc164251.aspx
With .NET 4.0, these "WorkflowServices" will be a big part of the new WF/WCF 4.0 package. You should basically be able to expose an interface for any workflow as a WCF service. Sounds very promising, haven't had a chance to try it myself.
Some links for the new stuff:
WCF / WF 4.0 and "Dublin"
http://blogs.msdn.com/murrayg/archive/2009/06/23/windows-azure-s-net-workflow-service-to-support-net-4-0-workflows.aspx
http://channel9.msdn.com/shows/10-4/10-4-Episode-24-Monitoring-Workflow-Services/
http://channel9.msdn.com/shows/10-4/10-4-Episode-16-Windows-Workflow-4/
Marc