-
-
16. Re: various questions
We're developing an in-house workflow application around JBPM, and we've decided at the application level that we'll use a dedicated 'docid' variable in our workflow instances to correlate the workflows with the Purchase Requests, etc., identified by numeric document id in our underlying system.
It helps our users out a whole lot, and we didn't need any special new support from JBPM to get this feature, but we are having to develop our own web console to provide some of the higher level features we want in our environment. -
17. Re: various questions
In general, I support what David and Ronald are saying. In order to get a clean, performant association between our processes and business objects (ie, orders) we're storing process instance ids in a dedicated table that maps to the business keys of our business objects. Our process variable table is huge and we need something much smaller that is properly indexed for speed.
Of course, if jBPM implemented a general business key, it would also need to support configuration in the process def or what it should be called. Otherwise, different kinds of keys (order/trouble ticket) could duplicate values, and a generic UI wouldn't know what to call the key. (can't rely on process definition id or name to distinguish your business key types, because a single business concept, like order, may be represented by more than one process def depending on the kind of order). For performance, the business key type should be stored directly against the key's value and procInstId, whether it be a reference to the type string or the string itself.
-Britt -
18. Re: various questions
"brittm" wrote:
Of course, if jBPM implemented a general business key, it would also need to support configuration in the process def or what it should be called. Otherwise, different kinds of keys (order/trouble ticket) could duplicate values, and a generic UI wouldn't know what to call the key.
I think that naming the field anything other than "key" would be a question of user code policy.
After all, users might think of a process instance as a "ticket" or a "request" or an "order", rather than as a process instance. Apart from possibly providing customizable resource bundles in the web console, I don't think this is something that should be dealt with by the jBPM core.
Also, uniqueness is something that should be decided by the application developer. The developer may decide that every process definition gets a unique key, or they may decide that key is unique by process name. Or they may develop rules that we can't anticipate. -
19. Re: various questions
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 -
20. Re: various questions
IMO the best way to add a "business key" to a processInstance is by extending ProcessInstance (using the Hibernate subclass mechanism). Unfortunately, when I tried to do this in the past, I had issues with hibernate proxies, etc. The benefit of this approach (assuming the proxy issues could be resolved) is that the developer can extend ProcessInstance with whatever data type or however many business keys they deem appropriate, and then create hibernate queries as needed to support their requirement.
-
21. Re: various questions
I see a number of similarities between the proposed business keys in jPDL, natural IDs in Hibernate and correlation sets in BPEL.
"Hibernate Reference" wrote:
A natural key is a property or combination of properties that is unique and non-null. [...]Hibernate will generate the necessary unique key and nullability constraints"BPEL4WS 1.1" wrote:
Each correlation set is a named group of properties that, taken together, serve to identify an application-level conversation within a business protocol
instance.
Notice the "combination" or "group" of "properties" references and the association to the identity of an instance. In both cases, the name and type of the properties are defined by the user.
Correlation sets exist due to the opaque nature of the instance id. Conversely, natural-ids and business keys are convenient, user-defined handles to the instance id.
Adding a "businessKey" property to the ProcessInstance class is not the way to go, because its name and type would not be defined by the user anymore. Further, composite business keys would not be possible anymore.
I see three ways:
1. Take Jeff's suggestion. Developers subclass ProcessInstance, add properties to the subclass and define natural-ids on them.
-> Subclassing ProcessInstance might not be desirable. Further, jBPM would neither be able to provide an API to get the business key(s) associated with a process instance, nor retrieve the process instance given a business key.
2. Create a BusinessKey class. Define a bidirectional association between one ProcessInstance and many BusinessKeys. Developers subclass BusinessKey, add properties to the subclass and define natural-ids on them.
->jBPM would be able to provide an API to get the business key(s) associated with a process instance, but not retrieve a process instance given a business key.
3. Create a BusinessKey class. Define a bidirectional association between one ProcessInstance and many BusinessKeys. Developers add properties to a map in BusinessKey.
->jBPM would be able to provide an API to get the business key(s) associated with a process instance *and* retrieve a process instance given a business key. However, lookups by business key cannot be fast, as Britt wants, because property values are stored in rows rather than columns. -
22. Re: various questions
"brittm" 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 ? -
23. Re: various questions
"jeffdelong" wrote:
IMO the best way to add a "business key" to a processInstance is by extending ProcessInstance (using the Hibernate subclass mechanism). Unfortunately, when I tried to do this in the past, I had issues with hibernate proxies, etc. The benefit of this approach (assuming the proxy issues could be resolved) is that the developer can extend ProcessInstance with whatever data type or however many business keys they deem appropriate, and then create hibernate queries as needed to support their requirement.
subclassing is in many cases not an option because it changes the DB schema and hibernate mappings for every process that you try to deploy. -
24. Re: various questions
"alex.guizar@jboss.com" wrote:
I see a number of similarities between the proposed business keys in jPDL, natural IDs in Hibernate and correlation sets in BPEL.
i think in most cases, a single String property that is defined upfront is sufficient. In case you want the full bpel correlations, you still could use that single property business key as a reference to a set of correlations. -
25. Re: various questions
created http://jira.jboss.com/jira/browse/JBPM-841
add a string based business key property on the process instance. combination of business key + process defintion must be unique if a business key is supplied.
is that a good solution ? does it overlook some of the aspects mentioned in this thread ? -
26. Re: various questions
I really like the idea of having the ability to retrieve the actual business object from a ProcessInstance. That is a nice touch.
...the combination (processDefinition, businessKey) must be unique ...
Actually, while this doesn't address part of the scenario I constructed (one business object being represented by multiple processes), it is workable as long as the various processes can be 'wrapped' in a single parent process that represents the business object one-to-one.
However, in that scenario, it would be much easier if the developer could simply declare in each process definition exaclty which business concept is being represented rather than go through the excercise of creating a single parent process and the logic to select one of several sub-process.
Of course, in my solution, a single process doesn't readily serve multiple business objects, but I'm having a hard time thinking of a case in which one would.
Thanks,
Britt -
27. Re: various questions
"alex.guizar@jboss.com" wrote:
Adding a "businessKey" property to the ProcessInstance class is not the way to go, because its name and type would not be defined by the user anymore. Further, composite business keys would not be possible anymore.
(...complex explaination...)
Alex, I think you're missing the point here - this is not a mandatory field. This is a field that can be used by simple applications (which I believe will be the majority). Applications for which this field is not useful need not use it, and thus are unaffected."tom.baeyens@jboss.com" wrote:
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)
All databases that I know of support multi-column unique constraints that include nullable columns - that said, I'm not sure that it should be unique by default. That is something that the user could decide."tom.baeyens@jboss.com" wrote:
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.
Maybe... that might be feature overkill though. Users should be able to handle manipulating a String."tom.baeyens@jboss.com" wrote:
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.
It shouldn't matter - the user can just query as if it is text. It wouldn't be a real key from the database's perspective, just a column that is indexed for efficient queries. I think it is important to emphasize that database keys should never, ever have business meaning.
Business keys often tend to be strings anyway: think of JIRA issue keys, or account numbers that are issued by banks, telephone companies, etc., which tend to be mixed letters and numbers."tom.baeyens@jboss.com" wrote:
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.
Exactly.
People, I think we just need to add a single, optional, indexed text field to ProcessInstance (and maybe Token and TaskInstance too). I think that such a field would be handy in a variety of situations, and I also think that we don't need to add a ton of other features or complexity to make it useful. -
-
29. Re: various questions
"david.lloyd@jboss.com" wrote:
Alex, I think you're missing the point here - this is not a mandatory field. This is a field that can be used by simple applications (which I believe will be the majority). Applications for which this field is not useful need not use it, and thus are unaffected.
My concern is not the business key being mandatory (clearly it is not) but the lack of flexibility in its type and multiplicity.
I can easily think of a process whose instances are identified by purchase order and customer name. Even for this simple case we already push the developer to implement a custom conversion framework. Since jBPM converters already exist just for that purpose, we could throw them in at no charge.
