"brittm" wrote : anonymous wrote : After all, users might think of a process instance as a "ticket" or a "request" or an "order", rather than as a process instance. | That's really my point. Those business concepts are established prior to defining the process defs that serve them. By allowing the developer to specify a business entity /context for the key via jpdl, then the business entity that the process/execution is intended to represent is clear (and quickly and easily queryable). | | In the scenario I'm proposing, a keyable business concept is represented by one or more processes (definitions) --duh. The defs specify the concept or entity type they represent, and their executions reference the business key. The 'type' and 'key' together provide the necessary business context. | | To put it differently--The question is whether the business context (keyed entity representation) should be derived from the process name, some user table, or up front by configuration. If context is derived from the process name, the developer has to implement plumbing to map potentially several process names back to a business concept--and he has to do it everywhere--UI resource bundles, every imaginable report, etc. However, if business context is provided in process config the developer only has to specify it once--now the domain relationship is established. | | If an 'order' is only ever represented by a single parent 'order' process, then none of this is a big deal. However, if an 'order' can result in the execution of a 'New Customer Order', or a 'Change Order', or a 'Move Service Order', or a 'Cancel Service Order' process being started, then it becomes an issue, because all of these separate processes are probably still 'just an order' as far as business keys go. | | If my thinking is off base here, or too narrow, somebody slap me back on track :) | | -Britt let me see if i get your point by proposing a solution: ProcessInstances gets an new 'businessKey' property of type String. This property is added to the constructors. Such a business key is optional, but the combination (processDefinition, businessKey) must be unique if the businessKey is not null. (not sure if DB's support such a unique constraint) Often the business key is a reference to some other object. So on the process definition you could specify a Converter that converts the String based business key into the referred object. So on the ProcessInstance you would get 2 methods like this: public String getBusinessKey(); public Object getBusinessObject(); The business key can be used in queries. I'm not sure if HQL can support the type differences between the text based reference and the typical number based PK of the referred table. I think that even in this case, you could have multiple types of processes in 1 single process definition. Suppose that you have change orders and customer orders all being processed by the same process definition. In that case you could compose the business key like this: "customerorder["+customerOrderId+"]" for customer orders and "changeorder["+changeOrderId+"]" for change orders. that makes the business key unique and still you can specify custom code to convert these business keys into the proper referred objects. Britt, does this come close to what you were explaining ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4017487#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...