moustafak

Hi, christianlott,

I am glad you like WF and the demo and thanks for the feedback. Please note that the sample is for demonstration purposes only to show you how you can leverage WF rules to drive the business logic of a windows form application. WF recommends that you model your application to fit your business needs and if hardcoding the items' prices doesn't meet your needs then you can pursue other options. One option is to create or reuse an internal structure and the rules can lookup values from this structure and manipulate the UI controls accordingly. Hope this helps.

Thanks, --Moustafa

The workflow assemblies need to be discoverable by the process calling the SqlTrackingQuery APIs. In your case, and per the error message, please make sure that the HostingWorkflowRuntime assembly and its dependencies are either GAC'ed or in the same directory as the WorkflowMonitor.exe. Hope this helps.

--Moustafa

Yes, we save the data in the SqlTrackingService's database. We've done so in Beta1 as well. By default we will only track workflow events, activity execution status event and user track point. If you can change your default tracking profile (DefaultTrackingProfile table) or supply a profile for type (TrackingProfile table) and we'll save what you decided to track based on your tracking profile.

In Beta2 we plan to add Query APIs layer atop of the out of box SqlTrackingService. As you've seen in the screencast, you can use those APIs to find workflows by execution status, activities from within your workflow and their activity execution status history, and activity properties' values that you decided to track. There are other capabilities that are being finalized now. Certainly, if you have more needs that are not satisfied by this query layer, you can always go directly and query your database.

I am glad to see you excited about the technology

--Moustafa