Using receiveandsendreply activity templates and WorkflowServiceHost makes it easy to create a workflow service. It can communicate with other applications like a normal WCF service. Most of the configurations are also fairly straightforward. Select the receive activity and configure it similar to the sendreply activity. Most of the work is used in setting up OperationContract or ServiceContract.
What to do if there is an error
In fact, there is no property that can be used to specify the error returned.
Throw FaultException
When the workflow service throws a faultexception, it is expected to be processed in time. Exceptions can be sent to the client as a SOAP error, assuming that the client is also. NET, which can be captured as a faultexception.
Throw faultexception<t>
Typically, when you want to add additional information to an exception, you need to create an extra class and declare the service contract with the Faultcontract property to specify the returned error. In the client need to add service metadata, do a add service reference to create the desired type. However, for the workflow service, there is no service contract class for adding attributes. There is no attribute for us to use to achieve these goals. So how do we specify an exception contract that interacts with the workflow service?
Solution
The trick is to add a second sendreply to the related receive activity on the workflow. The second sendreply activity returns an error contract. Adding a second sendreply activity is easy, simply by right-clicking the receive activity and choosing to create the sendreply activity. Next, create a variable to save the error message.
The faultdetail I use is very simple, it sends all the data received back to the client.
1 using System.Runtime.Serialization;
2 namespace ServicesAndFaults{
3 [DataContract]
4 public class FaultDetail
5 {
6 [DataMember]
7 public int Data { get; set; }
8 }
9 }
10
For the second sendreply activity, create and throw a faultexception. The workflow flowchart looks like this: