Model attribute value

[alladas]

@raoul2000,

First of all, bravo and thanks for this amazing workflow engine. Really cool.

I read everything I found about WorkflowDbSource. Very interesting. A lot of tips and good examples.

I wonder if there is a way to get a dynamic workflow definitions for a model according to its type. I am after something like a task_type which will provide a json encoded workflow rules to be used per task. Meaning definitions would be stored in the task type table. Any tips or suggestion would be welcome. In advance thanks

[raoul2000]

hi @alladas, and thnks for your nice comments.

I had not thought about this use case so I need a little bit of thinking to reply. Let's see ... of course at some point you will need a workflow source able to read a JSON workflow definition and provide workflow objets (Statusn Transition, Workflow). In itself this should not be a problem...

Now a potential problem for this new workflow source would be to be able to provide a workflow definition depending on the model it is attached to through the behavior. (more precisely, based on the _tasktype attribute value of the model). The workflow source component has no knowledge of the model it is used by: the model attaches the behavior, and the behavior initializes the workflow source component....

Humm... ok, for now, I don't see how to implement such thing as a DynamicWorkflowSource (finding a name is the easiest part :smile: ) but I'll think about it and let you know if I found a solution ...

ciao

[alladas]

@raoul2000 Many thanks for your reactivity. Yes, DynamicWorkflowSource is the best name for that. :smile: A way to pass the task type to the behavior. Merci.

[raoul2000]

I've been thinking of a possible solution that may reply to your problem. You would need to write a WorkflowDbSource component that would load the workflow definition from the task table (column task_type). The workflow ID value would be the same as the primary key of the task, so you would have one workflow per task. Then the only thing you have to pay attention to is assigning the correct initial status of a task. This can't be done through the defaultWorkflowId because this is a parameter of the workflow behavior, (identical for all tasks) but it can be easely done after task is inserted in the table (then you have it's PK).

For example :

• a task is inserted (pk = 231)
• update the task (assuming you have selected which workflow is should be inserted to)
  • status : set the selected workflow initial status value (e.g. 231/new)
  • task_type : workflow definition in JSON format

After that, when for instance, the behavior invokes the workflow source to find "reachable statuses" starting from 231/new, the workflow source will simply read the task_type column from line 231, parse the JSON as a workflow definition, and use it.

The drawback is that you need 2 DB access on each task insertion : one to get the PK, another one to update status and _tasktype columns.

That's all I can think about right now... Hope it helps.

ciao :sunglasses:

[alladas]

Hello @raoul2000, Hope this post finds you well. Many Thanks for coming back with a solution. Yes, this could be the best way to go. I will give it a try.

Worrying about big data handling, I've been thinking about grouping the workflows through the task_type. Concerning this I would like to ask you:

• what would look like the best to access the behavior's public properties from a TaskWorkflow class?
• I am thinking about a private function in the TaskWorkflow class which would be a kind of definitions provider for the getDefinition function. Maybe a bad idea! :laughing:

[raoul2000]

hi @alladas , you're right to be concerned about big data handling because storing one workflow per task in a task table column would mean load and parse a complete workflow each time you access a task (unless you implement some caching feature) I don't know what your requirements and constraints are, but if you have one workflow per task type, it would be much more efficient to store them in a separate table (the task_workflow table).

Now I'm sorry but I'm not sure to understand your questions. TaskWorkflow class has no knowledge of the model (i.e or its attached behavior's public properties) ... I may be missing something here as it seems you want to create some sort of dynamic TaskWorkflow where a private function would provide different workflow definition based on a behavior's attribute. That's brave !! :open_mouth: ... and I don't know how to do it.

hope it helped ciao :sunglasses:

[slow-loris]

Hi @raoul2000

I know it's a old issue but does a better solution for this use case exists? I have the same issue loading the workflow definition from the same ActiveRecord instance. In my case the client can push a workflow with it's own definition via rest api to the system. While editing the record the workflow transition should be validated.