> Hi, > > Today, I got a talk with Nicolas about the relevance of the workflow > engine in Tryton. > We came to the conclusion that it will be perhaps better to drop it. > So here are the arguments: > > - The Subflow which is indeed a key feature in the design of workflow is > never used in Tryton because by experience (on OpenERP) we knew that > it doesn't allow enough flexibillity. Most of the time, you need to > trigger the workflow in some other activities then the starting/ending > one. > > - The flexibility. Normally the workflow engine must provide > flexibility but in the reallity, we have most of the time more > difficulty to modify it through modules (any standard module does it). > So we manage it by inheriting some methods. > > - Simplicity. Just looking at the workflow of sale and you understand > that when you try to modelise complet life cycle of a document, the > workflow becomes very complex. But we can print a picture of it. > > - Misunderstanding, most of the developpers (and users) think that the > workflow is linked to the status of the document but because of the > nature of the engine, it is not. And you can have inconsistency > between both. > > - Speed, it is well know that the workflow engine is not very fast. Does > it deserve this sacrifice? > > - Security, this is a point where it is good. The access right to go > througth a transition works well. > > > So by what could we replace the workflow engine? > > The idea will be to have just simple method calls. Those methods will > replace the activities. The transitions will be replaced by different > way: > > - buttons which are linked to methods > - methods that call other methods > - triggers? (not sure because they can be heavy) > > The security will be replaced by capacities. So some method will be able > to check (via decorator?) if the user has a specific capacity to run the > method. The capacities will be defined in XML and they will be linked to > groups. > The workflow trigger will be replaced by overriding the right method of > the target model (it is already done like that with model without > workflow). > Optional advantage of such design is the traceback of calls will be more > clear. > > So what do you think? > -- > Cédric Krier >
For me it would be of a great advantage if I could visualize the steps that are made in Tryton and compare them to my business process model. With it I can track the changes and take action on them. Ideally you "translate" your business processes to worksteps in the application, but then you need a very flexible information system, with all the problems that go with it. Other possibility; If I could create a visualized view of the workflows that take place in Tryton for my situation and compare them to my business process model, I can track the gaps between them and act on it; change my business process a little, or change the workflow in Tryton a little. At he moment I have found no free BPM application that supports comparance to your own business situation, and there is no free ERP-like system that visualize the "information flow" so you can compare it to your business model. Anthony Anthony -- tryton-dev@googlegroups.com mailing list
