rlrcstr

If I have a workflow with a delay activity and I wnat to make the delay time configurable by a workflow administrator, what's the best way to do it

Does the .xoml file come into play here It looks to me like that file is compiled into the workflow library assembly, so it's not available at runtime to modify.

I can pass the value into the workflow and expose it as a setting for the hosting service, I suppose. Is that the best way to go

Any advice is appreciated...

J




Re: Windows Workflow Foundation Where's the best place for a configuration parameter?

Derek Smyth

Hi mate,

If it was me I'd just store the setting in the application configuration file. You could pass it to your workflows as a parameter or your workflow could load it directly using the configuration manager class in a InitaliseTimeoutDuration method.

I'm not an expert with workflow but I hope that proves helpful






Re: Windows Workflow Foundation Where's the best place for a configuration parameter?

TrevorW

I would definetly make it a paramater of the workflow, that is what they are for: providing external data to the workflow and retreiving data from the workflow. Workflows are designed to have rules such that some properties or states, etc can only be modified by certain users.

So, I would setup a defaut value and, based on your statement, would allow the user to change the default value if they have "administrator" privledges. If you are using a state machine workflow, it is likley that it would also only be allowed to be changed while in certain states. For example, would it make sense to change it if the workflow is completed

Personally, I think its a bad idea to use configuration files.

Trevor





Re: Windows Workflow Foundation Where's the best place for a configuration parameter?

rlrcstr

I'm currently passing the value as a parameter of the workflow. This particular workflow performs account deprovisioning. It delays for a specified amount of time. Let's say current business rules dictate a 90 day waiting period. So the workflow waits 90 days and then deprovisions the account.

The delay is defined by business process and not likely to change very often. So since it's generally a static value, I didn't see it as a parameter that needs to be passed to every instance of the workflow. But I still wanted the value to be chage-able without recompiling the workflow class library.

J






Re: Windows Workflow Foundation Where's the best place for a configuration parameter?

TrevorW

Properties of a workflow do not have to be passed in with every instance, they are simply available. So, it could just have a default value and you don't pass any reference to the property/parameter into the workflow. For the few that you do want changed, then you do specify the parameter and do pass it in.

However, after thinking about it more, I see the benefit of using both. The workflow could use a configuration file to apply the default value AND the workflow allows values to be altered by allowing them to be passed in as a parameter.

So, do both!

Trevor





Re: Windows Workflow Foundation Where's the best place for a configuration parameter?

Roman Kiss

rlrcstr,

The complexity of the configuration depends from type of the application. The following one is for multi-tiers clustered enterprise solution:

In our enterprise application, driven by xoml workflows, we created a workflow root base class to encapsulate some common behavior, application context, configurations, handlers, etc. Some parameters can be overwritten by host layer. Basically, we have one place such as the root activity to manage a configuration of the workflow. That's the first part of the configuration solution.

The second part is related to the configuration provider and storage. Enterprise application requires using different configurations based on the deployment environments such as staging, ..., qa, production. For example, in your case, parameter for Delay activity is 90 days for production, but for test environment should be few minutes, etc.

We built own configuration layer to enable using a value (simple or complex type) from the config file or central knowledge base (database). The config value can be identified by direct or alias name. In the case of alias name, the configuration manager will try to obtain a value from the config file, otherwise will ask a knowledge base. All values are cached in the configuration layer with capability to invalidate a cache based on the broadcasting message. This feature allows us to change a specific configuration in the tier, layer, appDomain on the runtime without updating the config file and/or restarting process.

Beside that, we have a logging system to capture a behavior of the enterprise application across the layers, tiers and clusters for post-processing such as monitoring, simulation, analyzing, tuning, reporting, etc. Based on the post-processor Analyzer, we can tune our configuration on the fly, updating the configuration cache or knowledge base.

Thanks

Roman