Recently I saw a message on the WF4 Forum where someone was asking for help learning how to consume a WCF service from a Workflow.
In this post I’m going to walk through how you can consume a WCF service from a Workflow where both the service and the workflow live in the same web site. This should be simple, but unfortunately it is not as simple as it should be.
A standard WCF service reference was created but the generated client class is not an activity. You could create a CodeActivity (or better yet an AsyncCodeActivity) to use the generated class but really that is not the best solution.
The problem is that there are 2 implementations of Add Service Reference. The original one (let’s call it ASR-Code) which generates the typical code based client classes and then another one we call ASR-XAML which generates a XAML based WF client proxy.
How do we know which one to invoke when you right click and say Add Service Reference? We know by looking at the project type. If you start your project as an Activity Library or a WCF Workflow Service application then you get ASR-XAML, everything else gets ASR-Code which is why we got a code based proxy when we really wanted a XAML based proxy.
The workaround is to add a new Activity Library project to your solution and then add the service reference from there. But… once again it is not as easy as it should be.
Doh! Just when we thought he had this problem solved…
In this case there is a loophole we can exploit and is has to do with the order of operations. Try this.
Now your XAML activity can be used from the web app
If you don’t want to use these workarounds there are some options
If your business logic lives in the same web app, you might be able to invoke the business logic directly without sending a message through WCF. If you can do this it will result in better performance as well as avoid the problem all together.
If you do need to send a message, you can use the WCF generated code proxy async interface (you have to generate w/async support). I highly recommend async but you can also use a CodeActivity if you don’t want to do async but this will hurt your performance.
This will keep the boundaries clear and you can invoke your services in their own application. The downside is that you now have 2 web applications to manage.
Yes, we have an open bug on this and are considering options for making this better in the future. One option might be to simply let you choose if you want the XAML reference to be generated when you create a service reference. Don’t know how long it will be before this gets better but it probably will not be fixed until the next release of Visual Studio.
Hey speaking of "the next release of Visual Studio" what are we looking at, early or mid 2011? :)
Your presentation at PDC has me super exited for all the new bits.
Wish I could say when the next release is... let's just say... I can't say :-)
Nice explanation.. I tried the same things.
I have got few inputs or concerns-
1. In practical projects we would have seperate WCF services / Library. Hence, we wont face any issues related to 'Circular Reference'. (I tried it)
2. And seperate WF library as well. It will implement one more workflows depends on use case requirements. All WF 'activities' would remain inside WF project only.
3. If we invoke the workflow from web page then we should not bother about any internal or external service consumed by that workflow. However, we have to add contract, binding information of services inside web application configuration.
give your inputs on this!!