1 2 Previous Next 25 Replies Latest reply on Jun 23, 2009 7:55 AM by tom.baeyens Go to original post
      • 15. Re: EJB 2.1 Beans in jbpm 4?
        camunda

        Currently we have the requirement to choose on a Command per Command base if it is sync or async.

        I will have a look at the implementation ASAP. For the release I think it is OK. Just keep the CommandService as well please :-)

        For the rest I will come back to it when I had a deper look and know requirements a bit better...

        • 16. Re: EJB 2.1 Beans in jbpm 4?
          camunda

          Okay, I checked the Remote configuration now. Quite cool! Pretty nice for normal use cases I think.

          I still have some concerns:

          1.) For Marketing reasons I would like to see EJB 3 inside of it. Even if you don't use it directly, EJB 2.1 is just "odd old" ;-) Too unsexy for jbpm 4. Maybe not a high priority, but still. And as Jorram pointed out, the developers supporting it or people trying to figure out transaction problems or whatever have a harder live here.

          2.) I wouldn't completly let got of the commands. Zwo use cases from my last projects of a big customer, where I still would prefer them:

          a) Batch Commands: We just added a thin layer around the commands in order to be able to call them in a batch. The same command, but just with different parameters (e.g. from a csv). So in one batch you could execute a couple of thound commands (sync or async. Normally async with a big amount). Would be possible with the current API as well, but was/is much easier by using the commands directly.

          b) Chained Commands: Think of the use case, where you have to fix an instance. E.g. you have to cancel it, start a different "fixing" process for it, maybe jump to a special node and execute a Groovy script to fix process variables. Okay, maybe not the best example here, but we had business requirements to do stuff like this. Therefro we introduced a CommandChain which can execute other commands IN ONE transaction. (Clue is you can execute the chain as batch :-)). If you use the remote ProcessEngine it executes every call in its own transaciton, right?
          And again, I think it is even easier to implement with the commands, than with the API...

          This is why I still like the commands. But maybe I am just too used to it? So if you have good points agaionst it just let me know :-)

          Thoughts?

          Cheers
          Bernd

          • 17. Re: EJB 2.1 Beans in jbpm 4?
            camunda

            Another objection: The Process Engine has a more fine grained API, e.g.:

            taskService.setVariable(task.getDbid(), "problem", "Out of stock");
            taskService.completeTask(task.getDbid());
            


            This could be done with one command before. Means, now we have
            - 2 transactions
            - 2 remote invocations


            • 18. Re: EJB 2.1 Beans in jbpm 4?
              tom.baeyens

              command functionality like you describe will always be available. but not yet exposed as supported. consider direct command access as still being in incubation.

              optimisation of 2 separate methods is an optimisation. create a jira and assign it to 4.1 or 4.x

              • 19. Re: EJB 2.1 Beans in jbpm 4?
                kukeltje

                And what about this

                • 20. Re: EJB 2.1 Beans in jbpm 4?
                  camunda

                  I think the problem there is, that some stuff is not pre fetched at the server.

                  This is what we tackled with the Commands as well in jbpm 3 (overwrite and access object graph on the server side). Don't know how that can be tackled easily in jbpm 4 without using commands...

                  • 21. Re: EJB 2.1 Beans in jbpm 4?
                    kukeltje

                    Oh.. yes, that is for sure the case. That is why I posted it. I'll need this in several cases in my apps.

                    • 22. Re: EJB 2.1 Beans in jbpm 4?
                      camunda

                      +1

                      Maybe Commands are still the best way to go there (sorry Tom for insisting on liking the Commands ;-)).

                      Or other ideas how this can be tackled via the API in a good manner?

                      • 23. Re: EJB 2.1 Beans in jbpm 4?
                        tom.baeyens

                        lazy fetched relations are indeed not exposed in the objects that are returned from the service methods. this is to prevent lazy initialization exceptions.

                        but commands are not the solution.

                        adding a findProcessInstanceByTask(long taskDbid) on the TaskService is the way to go.

                        • 24. Re: EJB 2.1 Beans in jbpm 4?
                          camunda

                          Hmm, I get the feeling that this offers not such a powerful options like Commands especially for remote communication. Too much invocations. Reminds me of EJB 2 EntityBeans ;-) No, thank god not that bad..

                          Okay, lets see what happen in the projects. The Commands are not gone, so if you need more you can get it.

                          • 25. Re: EJB 2.1 Beans in jbpm 4?
                            tom.baeyens

                             

                            "camunda" wrote:
                            Okay, lets see what happen in the projects. The Commands are not gone, so if you need more you can get it.


                            exactly. just indicating that the methods are the more stable option.

                            1 2 Previous Next