5 Replies Latest reply on Apr 17, 2008 7:33 AM by Sascha Janz

    actorId string

    Olivier Debels Newbie

      We are customizing jbpm and are using our custom identity package (user and role).

      This works fine but I wonder why the decision was made to have a string for the actorId (in taskInstance and PooledActor).

      I mean if I want to plug in my custom user and role I prefer to make a foreign key relation in the database, so that when assigning I have a pooled actor which has a foreign key (actorId) to my User and Role.

      Wouldn't it be better to have an extra database table using a foreign key relation with actorId? This database table can have a discriminator and the default implementation could have a string column (just like it is now).

      My identity component can easily be plugged in by creating another subclass for this table (with links to my user and roles).

      Any thoughts?


        • 1. Re: actorId string
          Ronald van Kuijk Master

          we have a comepletely external usermanagement system and do not want any relation (besides a string) to the actorID. For us it is perfect and it gives us very loose coupling.

          • 2. Re: actorId string
            Olivier Debels Newbie

            Good for you,

            But I think it just makes it harder if you want to add a more tighter link. For example when you want a foreign key relation between actorId and user or role table.

            I guess in your case you are able to determine from your actor id:
            1) if it is a role or user (or something else)
            2) What the primary key is of the role and user

            In this case you certainly need an extra query for retrieving roles and users corresponding with the task instances you want, which you can avoid if you have a tighter coupling.

            When adding the extra table I think you have the best of both worlds no?

            • 3. Re: actorId string
              Ronald van Kuijk Master

              1: Correct, and besides that there are no clashes between user/role/group values.
              2: Correct but we kind of use the string as the primary key (see 1)

              We indeed have adapted the identity module so it uses an additional query. We also want this since it makes the group membership dynamic.

              Before extending the identity module in jBPM (you can do it yourself atm) we should wait what 4.0 will bring. Big chance it will be redesigned and intergrate e.g. with the portal which in turn can use opensso so...

              • 4. Re: actorId string
                Olivier Debels Newbie


                Looking forward to see how this one evolves.

                • 5. Re: actorId string
                  Sascha Janz Master

                  could you please explain how you managed it to use your own identity component?

                  please help. i need this information. it's urgent.