13 Replies Latest reply on Aug 22, 2008 8:59 AM by kukeltje

    exposing db ids

    tom.baeyens

      for clients to reference executions, we need to give them a reference. so far, we have 2 options for that:

      1) the db id, generated by pvm

      2) a user defined key (String)

      The current ExecutionService supports both. It's too hard to force users to provide always a key.

      But maybe the two approaches can be merged. Suppose that we so something like this:

      String startProcessInstance(String processName);
      String startProcessInstance(String processName, String processInstanceKey);
      


      Then in both cases, the user gets the reference to the execution back as a string. In the first method, the DB id could be taken as the default generateed processInstanceKey.

      In that case, signalling and loading an execution can always be done based on the combination of process definition name and the execution key. It would probably simplify the API.

      WDYT ?

        • 1. Re: exposing db ids
          kukeltje

           

          It's too hard to force users to provide always a key.

          From my experience it is *not* hard. Some people just don't realise it they have one, or try to store all data in the engine.

          The thing we run into is that we almost always have to use composite keys. A business-key in our situation is e.g. a licenceplate number when the process is car damage repair. Since a car can have more damage then one, we use something like <real-business-key>:<some-other-known-value>.

          Signalling and loading is done based on this composite key.

          But you assumption might be right. It simplifies the api, but to a small extend

          • 2. Re: exposing db ids
            jbarrez

            I'm in favour of having these options.

            In my past projects, I've always used a similar approach (ie exposing an API with the business key to the outside).

            • 3. Re: exposing db ids
              tom.baeyens

               

              "kukeltje" wrote:
              It's too hard to force users to provide always a key.

              From my experience it is *not* hard. Some people just don't realise it they have one, or try to store all data in the engine.


              i agree. i think that in many cases this is appropriate. and that this is not known enough.

              "kukeltje" wrote:
              The thing we run into is that we almost always have to use composite keys. A business-key in our situation is e.g. a licenceplate number when the process is car damage repair. Since a car can have more damage then one, we use something like <real-business-key>:<some-other-known-value>.

              Signalling and loading is done based on this composite key.

              But you assumption might be right. It simplifies the api, but to a small extend


              then you still need to put the process definition into the mix. And concurrent paths of execution. That leads to a big composite key, which is not straightforward to deal with.

              • 4. Re: exposing db ids
                tom.baeyens

                maybe we could assume that we'll always generate String keys to the user.

                then we could make a KeyGenerator which is pluggable.

                the default keygenerator would make a string like this:

                "processDefinitionName:executionKey"


                where executionKey is the given key or Long.toString(execution.getDbid())

                An alternative (more optimized) key generation strategy may generate

                "executionDbid"


                This allows for one interface and one way of working. And promotes to work with keys like:

                "order:CO872364:shipping"


                where order is the process name, CO872364 the user defined key (eg the order id), and shipping represents the concurrent path for the shipping...

                • 5. Re: exposing db ids
                  porcherg

                   

                  "tom.baeyens@jboss.com" wrote:
                  for clients to reference executions, we need to give them a reference. so far, we have 2 options for that:
                  1) the db id, generated by pvm
                  2) a user defined key (String)
                  WDYT ?


                  I think this problem exists not only for executions, but there is the same problem for process definitions, tasks...

                  Having only a reference of type long (dbid) or string can be difficult to use:
                  if a user tries to use a processDefinition reference instead of an execution reference in a method, the java code will compile but the execution will fail.

                  Why not adding typed references ? startExecution would for example take a ProcessReference as parameter and return an ExecutionReference. There can be not confusion between references (or the java code will not compile).
                  (these references may only be wrappers around a business key or the dbid)

                  regards,
                  Guillaume

                  • 6. Re: exposing db ids
                    kukeltje

                    we've never encountered the problem for definitions, tasks etc... just with the businesskey.

                    What I don't get is how a typed reference solves the issue? Then the question would be what fields to put in it, how many, how to search for a processinstance with a certain processreference etc...

                    • 7. Re: exposing db ids
                      tom.baeyens

                      For executions, only exposing String keys and having a pluggable Key generator seems like the best approach to me.

                      Don't know yet what's best for the other types like ProcessDefinitions and Tasks

                      • 8. Re: exposing db ids
                        csouillard

                        Hi all,

                        I think adding keys is a good option. Adding a default KeyGenerator too.
                        But I join Guillaume on the point that we probably need to have typed keys.
                        This is the case in Bonita currently.
                        We have a ProcessKey which is an object and inside we have a String value which look like the one you are talking about (process-number)
                        This helped us a lot to clarify apis.

                        Best regards
                        Charles

                        • 9. Re: exposing db ids
                          tom.baeyens

                          I like the fact that the API gets more fool-proof.

                          But I also think that this will lead to more packing and unpacking of the keys. E.g. when users want to store a reference to a process execution.

                          This would create a kind of unconvenience like with the basic types for which autoboxing was introduced.

                          @kukeltje: it's not the individual fields that would be encapsulated, but just the generated string. so the ExecutionKey would just wrap 1 string member field.

                          I would think the extra runtime overhead (more garbage creation) is neglectable.

                          So I'm still in doubt.

                          What do others think ?

                          • 10. Re: exposing db ids
                            jbarrez

                            IMO, when comparing between String/typed keys, I don't see much difference. The API gets nicer, but working with the API get tougher due to all the wrapping in/out that needs to happen. As a lazy developer, I would choose the String option ... I don't see much benefit in compile-time safety here (unless you can provide me a really really good example).

                            However, if the PVM would support KeyGenerators which are in fact Key Factories, I would like to have full freedom:

                            For example for process keys:
                            - The keygenerator always returns an ProcessKey (interface)
                            - The default keygenerator implementation of the ProcessKey interface is a SimpleKey object (simple wrapping of the String)
                            - Different implementations of the ProcessKey can be written: CombinedKey with getters/setters for the different fields. The value that is saved to the database still is a String however (the implementation should define how the fields are mapped to the String)
                            - The KeyGenerator can even be a generic class, simply returning the ProcessKey implementation that is in the type of the generic.
                            - The default, most used option should be without configuration

                            This might all sound very fuzzy: but what I mean is that when the KeyGeneration is free, the implementation of the key should also be free. Off course there is the DB limitation that it always should map to a String... but using a String you can compose complex keys (that would be the KeyGenerator's job: it receives a String an returns a ProcessKey implementation).

                            This is just another view on the problem... i definitely don't want to say this is the right choice!

                            • 11. Re: exposing db ids
                              tom.baeyens

                               

                              "jbarrez" wrote:
                              This might all sound very fuzzy


                              it's clear. and it is at least an interesting new argument/option in the mix.

                              "jbarrez" wrote:
                              - The KeyGenerator can even be a generic class, simply returning the ProcessKey implementation that is in the type of the generic.


                              that is the part that i didn't get yet. can you elaborate what you meant ?

                              "jbarrez" wrote:
                              Different implementations of the ProcessKey can be written; ... what I mean is that when the KeyGeneration is free


                              At first glance I thought "that's it!".

                              On second thought, if you want to use the specific implementation capabilities beyond the string thing, users will have to cast and they go outside the portable boundaries anyway.

                              Instead of integrating those functions directly into the engine, it might be better for users to do this outside of the engine like this.

                              String executionKey = executionService.startExecution("myprocess");
                              ...
                              MyCompositeKey mck = new MyCompositeKey(executionKey);
                              mck.getProcessName();
                              mck.getProcessVersion();
                              mck.getProcessInstanceKey();
                              mck.getExecutionPath();
                              
                              ...or the other way round...
                              
                              executionService.signalExecution(mck.toString());
                              


                              So this doesn't necessary have to be baked into the engine itself. But it could.

                              • 12. Re: exposing db ids
                                tom.baeyens

                                all in balance, i think i'll go for the String based approach.

                                so access to property dbid (long) will be removed in the interfaces.

                                ProcessDefinition, Execution (and later also Task) will get a key property.

                                The current 'key' property in execution (unique only within the scope of one process definition) will change its meaning to the new key (unique over all executions)

                                The key property (String) will be exposed in the interfaces.

                                • 13. Re: exposing db ids
                                  kukeltje

                                  The textual example from Joram is what I was trying in a real java example and in fact what I want in a PAO.

                                  So the string is a good choice