Question

Suppose there exists a workflow service A. WF A may have more than a single instance (using CanCreateInstance).
Now, suppose there exists WF B, which is different (in content), but with the same characteristics as WF A.
In order for WF A to finish, it has to call WF-B n (dynamically determined) times (each time with a different arguments, of course).

Pseudo workflow could be:

Instance of WF-A:
    // WF is instantiated 
    // do some activities
    parallel-foreach (product in Products)
        Send & Receive to a different instance of WF-B with parameter product
    // do some activities
    // WF-A is done

The only question is: How do you implement such a scheme?

Answer 1

There are couple of things to note;

There are two ways to call a service within a WF.

• One way is using Send-Receive activities style messaging, in which one needs to specify the address of the service (or configuration endpoint) as well as method name & arguments (including their names).
• The other way is to use a service reference. When using such a reference, visual studio will create a dedicated activity for each service method. That way seems to be a native way and uses a WF activity abstraction (use that way if possible!).

Note that the .XAMLX file, that declaratively represents the WF service, will point to the specific service reference activity, which is, eventually bundled in the dll of the project that XAMLX resides in.

Note also that the generated service-reference activity points to some WCF configuration client binding. Since WF-A is a client of WF-B.

Therefore, you could do the following:

1. Do whatever you want in WF-A – just use WF-B with by using the service reference activity.

2. The host of WF-A should have a reference to the assembly in which WF-A.XAMLX resides (which means that the host will have the WF-B activity from its service reference). Meaning the XamlX, by itself, is not enough for the host.

3. Add a service reference (with the same namespace as used in WF-A assembly) to WF-B in the host of WF-A, change the client configuration of the host by removing the leading namespaces in the client section in the contract name (IServiceB instead of ServiceReference.IServiceB)

The last step could be replaced with configuring the client bindings by yourself, but it’s much easier using a service reference (that you can also update)