All,
I am using JBoss JBPM and Drools.
The workflows are loaded to the KnowlwegdeBuilder as resources. There are multiple sub-processes (or child processes) that are invoked from parent processes.
is there any way to check if these child-processes were loaded prior to loading the parent process?
i.e. some kind of parent-child dependency check.
Reason is - if there are any missing sub-processes (child processes) - I know about this only at run time (when my workflow is actually running), is there a way to determine this prior to actually firing the workflow?
regards
D
There is nothing to check that I'm afraid. Because the sub process reference can be a process variable which can also be calculated at runtime it is something difficult to check. Parsing the Process to find the sub process references if they are not variables can be done fairly easy.
Which version of jBPM are you using?
Cheers
Related
In MDriven Enterprise Information, why is there a Processes Hierarchy and also a Processes Tree? Aren’t they the same thing? Is this not redundant duplication?
Processes are defined by their steps.
A Process step can make use of another processes - ie defining a sub-process.
To both have the complete list of processes and the resulting expanded tree of process and their sub-processes and even their sub-processes (infinity) we added two nodes.
First node is the complete straight list of existing processes regardless if they are sub-processes or not.
Second node is the constructed tree of whom uses who - and a sub-process can then show up multiple times in this tree.
Notice that ApproveNewBulk is re-used in 2 processes in the example below.
My team is new to developing these things and I came into a project that is defining an over-arching workflow using separate processes that are all defined under the same project. So it appears that right now the processes defined are all discrete units, and the plan was to connect these units together using inputs and outputs.
Based on the documentation it looks like the best-practicey way of doing this would be to define the entire, over-arching workflow using sub-process tasks.
So I wonder:
Is the implementation we've started workable?
or
Should I only have one process unit per one workflow, which defines sub-processes if the workflow is too complicated and has discrete parts?
It's fine to separate out certain parts of the process into its own process, and then call those from some sort of parent process. The task you should use in the parent process is called reusable sub-process, or call activity. It's absolutely fine to have multiple processes in the same project.
The result of SqlWorkflowInstanceStore.WaitForEvents does not tell me what type of workflow is runnable. The constructor of WorkflowApplication takes a workflow definition, and at a minimum, I need to be able to store a workflow ID in the store and query it, so that I can determine which workflow definition to load for the WorkflowApplication.
I also don't want to create a SqlWorkflowInstanceStore for each custom workflow type, since there may be thousands of different workflows.
I thought about trying to use WorkflowServiceHost, but not every workflow has a Receive activity and I don't think it is feasible to have thousands of WorkflowServiceHosts running, each supporting a different workflow type.
Ideally, I just want to query the database for a runnable workflow, determine its workflow definition ID, load the appropriate XAML from a workflow definition table, instantiate WorkflowApplication with the workflow definition, and call LoadRunnableInstance().
I would like to have a way to correlate which workflow is related to a given HasRunnableWorkflowEvent raised by the SqlWorkflowInstanceStore (along with the custom workflow definition ID), or have an alternate way of supporting potentially thousands of different custom workflow types created at runtime. I must also load balance the execution of workflows across multiple application servers.
There's a free product from Microsoft that does pretty much everything you say there, and then some. Oh, and it's excellent too.
Windows Server AppFabric. No, not Azure.
http://www.microsoft.com/windowsserver2008/en/us/app-main.aspx
-Oisin
I have 7 workflow that need to execute; that need to run in certain order ? Is there any scheduling service for this in wf4 or any other approach i can use?
Ocean
If you need to run them sequentially in a certain order, why not just create another workflow and put all 7 of your workflows as activities in a top sequential activity?
If you create an activity that derives fron NativeActivity you can schedule child activities in any order you like. That is the closest thing to a "SchedulerService" I can think of.
However you have to know the activites you want to run at compile time. You can only arrange the order differently using this approach.
If you don't know which activities you want to use at compile time you could use a parent/child technique I showed on my blog WF4 How To Invoke a Child Workflow as XAML
Windows Workflow Foundation has a problem that is slow when doing WF instances persistace.
I'm planning to do a project whose bussiness layer will be based on WF exposed WCF services. The project will have 20,000 new workflow instances created each month, each instance could take up to 2 months to finish.
What I was lead to belive that given WF slownes when doing peristance my given problem would be unattainable given performance reasons.
I have the following questions:
Is this true? Will my performance be crap with that load(given WF persitance speed limitations)
How can I solve the problem?
We currently have two possible solutions:
1. Each new buisiness process request(e.g. Give me a new drivers license) will be a new WF instance, and the number of persistance operations will be limited by forwarding all status request operations to saved state values in a separate database.
2. Have only a small amount of Workflow Instances up at any give time, without any persistance ofso ever(only in case of system crashes etc.), by breaking each workflow stap in to a separate worklof and that workflow handling each business process request instance in the system that is at that current step(e.g. I'm submitting my driver license reques form, which is step one... we have 100 cases of that, and my step one workflow will handle every case simultaneusly).
I'm very insterested in solution for that problem. If you want to discuss that problem pleas be free to mail me at nstjelja#gmail.com
The number of hydrated executing wokflows will be determined by environmental factors memory server through put etc. Persistence issue really only come into play if you are loading and unloading workflows all the time aka real(ish) time in that case workflow may not be the best solution.
In my current project we also use WF with persistence. We don't have quite the same volume (perhaps ~2000 instances/month), and they are usually not as long to complete (they are normally done within 5 minutes, in some cases a few days). We did decide to split up the main workflow in two parts, where the normal waiting state would be. I can't say that I have noticed any performance difference in the system due to this, but it did simplify it, since our system sometimes had problems matching incoming signals to the correct workflow instance (that was an issue in our code; not in WF).
I think that if I were to start a new project based on WF I would rather go for smaller workflows that are invoked in sequence, than to have big workflows handling the full process.
To be honest I am still investigating the performance characteristics of workflow foundation.
However if it helps, I have heard the WF team have made many performance improvements with the new release of WF 4.
Here are a couple of links that might help (if you havn't seem them already)
A Developer's Introduction to Windows Workflow Foundation (WF) in .NET 4 (discusses performance improvements)
Performance Characteristics of Windows Workflow Foundation (applies to WF 3.0)
WF on 3.5 had a performance problem. WF4 does not - 20000 WF instances per month is nothing. If you were talking per minute I'd be worried.