none
Workflow service with runtime activity definition RRS feed

  • Question

  • Hi,

    I have rehosted the workflow designer, I can create and save a xaml definition which can be executed in a separate application using the WorkflowInvoker.

    I would like to do the same thing but by hosting the workflow as a service thereby having a service that can execute user-defined workflows - is something like this possible?

    Friday, February 1, 2013 12:48 PM

Answers

  • For simple pulling solution please have a look at How To Build Workflow Services with a Database Repository.

    Of course you could code everything, but you will need to solve the same problems that are already solved in AppFabric. Also I don't see any benefits of having one service to execute workflows. When every workflow is a service you could leverage some cool features of AppFabric as Monitoring, Persistence, Recovery. In addition this is more scalable solution.

    In our solution we are using "push" approach. Let me highlight some key points:

    • workflow definitions (xamlx) are stored in the central Repository (in our case in database)
    • users are able to create new or edit existing workflows using Rehosted Workflow Designer. At that point users work with Repository only and it has no influence on execution environment.
    • when workflow is ready, user is able to publish it to execution environment. Pleases note that versioning should be considered, because it should not be possible to change existing workflows.
    • workflows are published as a xamlx. No compilation required
    • every workflow exposes "generic" endpoint that is used to start or resume workflows
    • client application activates workflows by name using generic interface. Client API uses discovery service to find corresponding endpoint by name.

    • Marked as answer by albra Tuesday, February 5, 2013 10:00 AM
    Monday, February 4, 2013 11:15 AM

All replies

  • It's possible to host non-service workflows in Windows Server AppFabric. It could be achieved by implementing custom WorkflowHostingEndpoint. As result every workflow could expose a generic activation interface like following:

        [ServiceContract(Name = "IWorkflowCreation")]
        public interface IWorkflowCreation
        {
            [OperationContract(Name = "Start")]
            Guid Start(IDictionary<string, object> inputs);
    
            [OperationContract(Name = "Resume", IsOneWay = true)]
            void Resume(Guid instanceId, IDictionary<string, object> inputs);
        }
    For details, see How to: Host a non-service workflow in IIS

     
    Friday, February 1, 2013 2:27 PM
  • Thanks Alex, I am not sure App Fabric is where I should look at though. I was thinking about having one service which is generic and serves multiple user-defined (at runtime) workflows. I want to be able to add or edit workflows without visual studio and have one endpoint (service) that can handle the execution of all these workflows.

    I am starting to think that perhaps a 'workflows service application' project is not the right way and I should maybe be looking at a raw wcf service wherein I would code all the multi-threading and loading of xaml workflow files and persisting myself - it's just that all of this is already taken care of in a workflow service app, I just don't know how to pull in xaml defined workflows on the fly.

    Monday, February 4, 2013 7:39 AM
  • For simple pulling solution please have a look at How To Build Workflow Services with a Database Repository.

    Of course you could code everything, but you will need to solve the same problems that are already solved in AppFabric. Also I don't see any benefits of having one service to execute workflows. When every workflow is a service you could leverage some cool features of AppFabric as Monitoring, Persistence, Recovery. In addition this is more scalable solution.

    In our solution we are using "push" approach. Let me highlight some key points:

    • workflow definitions (xamlx) are stored in the central Repository (in our case in database)
    • users are able to create new or edit existing workflows using Rehosted Workflow Designer. At that point users work with Repository only and it has no influence on execution environment.
    • when workflow is ready, user is able to publish it to execution environment. Pleases note that versioning should be considered, because it should not be possible to change existing workflows.
    • workflows are published as a xamlx. No compilation required
    • every workflow exposes "generic" endpoint that is used to start or resume workflows
    • client application activates workflows by name using generic interface. Client API uses discovery service to find corresponding endpoint by name.

    • Marked as answer by albra Tuesday, February 5, 2013 10:00 AM
    Monday, February 4, 2013 11:15 AM
  • Thanks for the info the link to that cool vid! AppFabric is new to me so I will need to check this out but as per the video it seems that it is not actually required to host the services that way. Some questions:

    - I don't get why persistence is a function of AppFabric, surely the persistence would be defined somehow in the service/workflow definition itself?

    - These services can handle multiple concurrent instances of the workflow right?

    Tuesday, February 5, 2013 7:16 AM
  • 1. You are right. AppFabric uses SQL Persistence Provider that is shipped with .NET 4.0 and “AppFabric” just makes it easy to configure and use .NET 4.0 persistence features by using IIS Manager Extensions and Power Shell cmdlets. See AppFabric FAQ: Persistence for more info.

    2. In this scenario every workflow is a service and handles multiple concurrent calls and instances like other services based on WCF Throttling Settings. See WCF Using ServiceThrottlingBehavior to Control WCF Service Performance.

    Tuesday, February 5, 2013 9:37 AM
  • Thank you Alex, you have been very helpful
    Tuesday, February 5, 2013 10:01 AM