Wf4.0: workflow service Exception Handling

Using the receiveandsendreply activity template and workflowservicehost can easily create a workflow service. It can be used with other applications like a common WCF ServiceProgramCommunication. Most of the configurations are quite simple. Select and configure the receive activity, which is similar to the sendreply activity. Most of the work is used to set operationcontract or servicecontract.

What should I do if an error occurs?

In fact, no attribute can be used to specify the returned error.

Throw faultexception

When the workflow service throws a faultexception, it is expected to be processed in a timely manner. Exceptions can be sent to the client as soap errors. If the client is also. net, it can be captured as a faultexception.

Throw faultexception<T>

Generally, when you want to add additional information to an exception, you need to create an additional class and declare the service contract with the faultcontract attribute to specify the returned error. Add service metadata on the client and add a service reference to create the required type. However, for workflow services, there is no service contract class for adding attributes. There is no attribute for us to use for these purposes. Then, how do we specify an abnormal contract for interaction with the workflow service?

Solution

The trick is to add the second sendreply to the receive activity related to the workflow. The second sendreply activity returns an error contract. Adding the second sendreply activity is simple. You only need to right-click the receive activity and choose create sendreply activity. Next, create a variable to save the error message.

The faultdetail I use is very simple. It sends all received data 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

Creates and throws a faultexception for the second sendreply activity. The workflow flow chart is as follows:

The following expression is used to initialize error exceptions.

The following sendreply activity returns an error and is configured as follows:

With this setting, you can add a service reference on the client and use the followingCodeExpected results

1 Static   Void Main ( String [] ARGs)
2 {
3 VaR proxy =   New Serviceclient ();
4 Try
5 {
6 Console. writeline (proxy. getdata ( 42 ));
7 }
8 Catch (Faultexception < Faultdetail > Ex)
9 {
10 Console. writeline ( " Faultexception <faultdetail> with {0} " , Ex. Detail. data );
11 }
12 Catch (Faultexception ex)
13 {
14 Console. writeline (Ex );
15 }
16 Console. Readline ();
17 }

 

The workflow output in the service console application is as follows. Note that "the workflow finishing" does not appear in the last message. Don't be surprised. An exception is not captured, and the workflow is terminated.

But you want to keep the workflow running!

Sometimes the above processing method is good, but sometimes it is not. For example, if you have been working on an order for one month, will you terminate all work due to an exception? Of course not.

The second method returns an error to the called client, except that the faultexception or faultexception customized in the sendreply activity <t>. The client will not know the difference, but the workflow will continue to run. Therefore, what I need to do is to remove the throw and let the second sendreply activity implement its work.

This time, the service console application output is as follows:

Original article: workflow 4 and soap faults

Code:/files/zhuqil/8424.servicesandfaults_05f3442d.zip

PS: Welcome to the wf4.0 technical discussion group 51262864