3 Replies Latest reply on Jun 23, 2009 5:48 AM by tom.baeyens

    Extending jBPM, Plugging in custom IdentityService implement

    shekharv

      I was trying to identify how one could extend the current jbpm identity implementation or plugin one's own IdentityServiceImpl. I dug around in the code a bit and noticed that there are a couple of bindings.xml files that really are responsible for configuring what Implementation classes are responsible for each of the high level Service interfaces that we have in jBPM. TaskService, ExecutionService, etc.
      jbpm.wire.bindings.xml
      jbpm.user.bindings.xml

      Had a few points to note about the approach mentioned above,
      1.) Is this the intent of the designers of the system and the api developers to provide extension points into the engine in this manner?
      2.) There is also the jbpm.user.bindings.xml. From the looks of how the bindings are being stored(as a list) it does not seem that any bindings that we add to this file would override the bindings in the jbpm.wire.bindings.xml. So it seems to be more of an additive nature than overriding. So you could add new bindings, but you cannot replace/override the ones that the engine sets up by itself(default wire.bindings.xml)
      3.)Taking the above point into consideration, should the jbpm.wire.bindings.xml be user configurable option? If needed? So that there is a more straightforward way to 'register' one's custom implementations for Identity and other Services(If needed). Or should the jbpm.user.bindings.xml be loaded in such a manner that it can override the existing ones. So store the bindings in a Map rather than a List?

      All this is based on my understanding of the way things are being setup within the engine, we have really been working with jbpm4 for a little over a week now. So I could be really miles away from the truth and the bigger picture. Excuse me if that is the case.

      Plugging in a custom IdentityServiceImpl would be a big gain if we are able to hook it up seamlessly to work with our own auth mechanism.

        • 1. Re: Extending jBPM, Plugging in custom IdentityService imple
          tom.baeyens

          here's pointers on how to plug your own identity service

          in jbpm.cfg.xml, remove the line

          <import resource="jbpm.identity.cfg.xml" />


          and add

          <transaction-context>
           <object class="your.package.YourIdentitySessionImpl" />
           </transaction-context>
          


          YourIdentitySessionImpl should implement org.jbpm.pvm.internal.identity.spi.IdentitySession

          Making this identity pluggable is not our first target, but it was taken into the design. Let us know how it goes. I'll add these notes to the developers guide. And update them with your feedback.

          • 2. Re: Extending jBPM, Plugging in custom IdentityService imple
            shekharv

            That is neat!
            Works like a charm!

            We also are trying out another extension for jbpm from our end. This is similar to what jbpm3 had with regards to CustomTaskInstance(s).

            Use Case: Domain specific Task information to be stored in a separate table and linked up via the taskid to the jbpm Task table. Enables some custom extensions and reporting for tasks.

            In jBPM4 we added a custom activity:
            <custom-task>
            Put in the binding for the same using jbpm.user.activities.xml.

            Our Custom Activity simply extends the TaskActivity provided out of the box, and over rides the execute method of task creation,

            This is where we add the code to also fire off an insert into our custom table with all the information that we need to persist.

            And since we need a handle to the Task ID, we cannot simple call

            super(execution)

            and instead we have to copy some of the code from execute in TaskActivity

            public void execute(ActivityExecution execution) {
             JpdlExecution jpdlExecution = execution.getExtension(JpdlExecution.class);
             TaskImpl task = jpdlExecution.createTask(taskDefinition);
            
             CustomTask customTask = new CustomTask(task);
             customTaskDAO.create(customTask);
            
             TaskHandler taskHandler = task.getTaskHandler();
             boolean wait = taskHandler.executionCreateTask(task);
            
             if (wait) {
             execution.waitForSignal();
             }
             }
            


            Again wondering if this is the best way to do so? How does the design of jBPM allow for solving this?

            • 3. Re: Extending jBPM, Plugging in custom IdentityService imple
              tom.baeyens

              at first sight, this seems to be the right way