João Cunha Lopes

Hi all.

I have two distinct WFs, WF A and WF B, that send messages to each other using Web Services.

When A calls a Web Service in B, B receives the SOAP request but it seems that B reply is asynchronous. B replies to A only when it finds suitable to do so.

A have a few questions about this:

1. What conditions B has to meet so it can send a reply to A Does it need to be idle

2. I really need synchronous web service calls. Is there a way to implement this How

3. Since WF A is waiting for a reply from B, what happens if B takes to long to reply (B does not meet the conditions that are necessary to send a reply to A) Is there a timeout that should be handled by A

Thank you for your time.

Any help is welcome.


Re: Windows Workflow Foundation Synchronous Web Service Calls

Joao Cunha Lopes


I know that the InvokeWebService Activity is synchronous. This means that, when using this activity, when WF A calls a Web Service in B, A will wait for a reply from B.

The "problem" seems to be that WF B receives the request sent by A but it does not reply right away. Actually I have seen B receive the request, then execute other code and only then send a reply to A.

4. So How can I prevent B from executing other code and send a reply to A immediately after receiving A's request :)


Re: Windows Workflow Foundation Synchronous Web Service Calls

Angel Azcarraga - MSFT

What does workflow B look like It should only send a reply when the outbound call (WebServiceOutput activity) is executed. It will not skip logic to make a reply.

Maybe I don't completely get your scenario/workflow, can you provide some detail


Re: Windows Workflow Foundation Synchronous Web Service Calls

Vignesh Kannappan - MSFT

If you want WF A to continue after sending a request to WF B, you should try to delegate the task of pushing the result message from B when it is done processing to an external service - a runtime service.

You could raise a method from WF A on the externaldataexchange service which in turn uses normal C# syntax for WebMethod invocation using a webproxy and register a callback for the results. WF A after firing this method can continue processing, while WF B sends the data back upon completion which could then be raised as an event into WF A. I haven't implemented this idea in code, so let me know if this works for you.



Re: Windows Workflow Foundation Synchronous Web Service Calls

Joao Cunha Lopes

Hi Angel,

thanks for the reply and sorry for taking so much time to get back to this.

Here is a description of WF B:

1. It's a state machine WF with code separation.

2. It has the following states:

Inital State

A State

B State

C State

Final State

3. On the Initial State it has an Event Driven activity. Inside this activity it has a WebServiceInput activity, followed by a code activity and then by a WebServiceOutput activity.

4. States A, B and C are doing the same thing. They only have StateInitialization activities. Each one of this Init activities has a block of code (just a


)  followed by a SetState activity (the order is Initial to A, then to B, then to C then to Final).

5. The Final State is a Finalization State, so the WF Instance is removed from the Database.


So you see, this is really quite simple.

Again, the problem is that I would like WF B to send an imediate SOAP reply to WF A. This is not the case. As things are now, WF B only replies to WF A when it reaches the final state.

Simple math with lead you to this: WF A has to wait at least 15 seconds (5 seconds in state A, 5 in state B and 5 in state C) for a reply from WF B.

This is a problem because the time a Web Service takes to receive a reply is dependent on the time a WF takes to idle. I think the reply should be sent as soon as B reached the WebServiceOutput activity that is present on WF B Inital State.

Any help is welcome.


Re: Windows Workflow Foundation Synchronous Web Service Calls

Joao Cunha Lopes

Hi Vignesh,

thank you for your reply.

Actually what I want is for WF B to reply when it reaches the WebServiceOutput activity (it's inside the Inital State; please see my reply to Angel). Past this point, further code execution in WF B can greatly delay a reply to WF A.

Also, in WF A, I can't proceed past the waiting reply point. If I don't receive a reply from WF B further processing is impossible.