1 2 3 Previous Next 36 Replies Latest reply on Oct 30, 2006 8:26 AM by tom.baeyens

    extending form / task functionality

    kukeltje

      One of our customers has a requirement which we are evaluating to see if we are going to meet these or not. Let me explain.

      The application has several tasks that have to be performed in sequence. These tasks can be performed directly, one after another, but it could also be that there is a one day delay between them. So it is not realy a wizard or pageflow, but real tasks. So far no problem. The customer also wants that IF the user performs the task he/she should automatically see the next task in that process if it is one for him. Currently the ui goes back to the tasklist. This is highly unwanted by the customer and we (not higly, buy to some extend) agree. I'm currently looking into ways of achieving this. If there is any hint or tip on how to achieve this, I'll be greatfull. Especially if this is functionality interesting enough for jBPM.

      The other requirement is that the customer has is a kind of wizard functionality

      jBPM has pageflow functionality (wizard?), process/workflow and there is the forms.xml file. It would be nice if the pageflow.xml and form.xml would become one. There is a lot of overlap

      <page name="Task1" view-id="/task1Page.xhtml" redirect="true">
       <transition name="checkout" to="checkout"/>
       <transition name="complete" to="complete"/>
       </page>
      

      could be easily used instead of
       <form task="Task1" form="/task1Page.xhtml" />
      


      If there is no transition, the default 'tasklistpage' is shown if there is a transition, the corresponding page is looked up and displayed. This way a pageflow can be used in a task. The only thing is that the last page should contain a call to a method which ends the task, whereas the other pages contain calls to methods which just update the processvariables, other beans or do whatever is needed, just not end the task. This could be done either based on explicitly in the form or by adding an attribute in the pageflow to explicitly (e.g. a conversation) tag around several pages, or a pageflow file per task.

      I'd like to discuss these here, since if it is interesting for the jBPM webapp framework, we can contribute. If it is not, we have to implement something ourselves and will probably not use the jBPM webapp at all

      Ronald
      (not as moderator)

        • 1. Re: extending form / task functionality
          hosierdm

          We had basically the same requirement in a project we are working on. I won't touch on your discussion of changes to jBPM since that's over my head still. This is how we solved the problem, and it may not suit you depending on how your application is designed. When a user closes a task, it submits to a Servlet and I signal the process and use the LoggingInstance to see if a new task has been assigned. If a task is assigned, I get the task instance ID and return that as part of the HttpResponse. I redirect to the task list page, and the logic in that page says that if the task-id parameter is non-zero then load the task with the given id. This way it simulates a wizard, but the logic on the server side is always the same. So like I said, that may not work for you with how you've designed your app, but maybe it will give you something to chew on. I hope it helps. I'll paste a code snippet (which I adapted from the jBPM webapp)....

          LoggingInstance loggingInstance =
           task.getTaskMgmtInstance().getProcessInstance().getLoggingInstance();
          List assignmentLogs = loggingInstance.getLogs(TaskAssignLog.class);
          if (assignmentLogs.size() == 1)
          {
           TaskAssignLog taskAssignLog = (TaskAssignLog)assignmentLogs.get(0);
           log.debug("A new task has been assigned to '" + taskAssignLog.getTaskNewActorId() + "'");
           newTaskId = taskAssignLog.getTaskInstance().getId();
          }
          
          <snip>
          
          response.sendRedirect("/SAS?task=" + newTaskId);


          • 2. Re: extending form / task functionality
            kukeltje

            This is kind of similar to what we are thinking about. In addition the taskname would be returned and we use that to select which real pageflow (currently jsf config based) should be taken.

            We then have the combination of direct sequential execution of tasks and real pageflows separated from the processdefinition.

            If at least we (you and I) have these requirements, I bet they are interesting engouh for others as well. I'll file a jira issue to develop this functionality in jBPM

            • 3. Re: extending form / task functionality
              brittm

              Ronald,

              We've built our own web apps for both task management/execution and administration. Regarding automatic continuation of task screens, we're building the same thing into our task management UI at user's request. This is very much a desireable feature.

              -Britt

              • 4. Re: extending form / task functionality
                kukeltje

                ok, now I will surely file a jira issue. We can either draw up requirements there, or use a wiki page for it. I'm in favour of the latter.

                Ronald

                btw, long time no hear (or did I mis something), wb

                • 5. Re: extending form / task functionality
                  brittm

                  Didn't miss anything. I've been busy with my company being acquired, travel, deployments, firefighting, and lots and lots of process diagrams.

                  • 6. Re: extending form / task functionality
                    koen.aers

                    Acquired? So you also know what it feels like then ;-)

                    Cheers,
                    Koen

                    • 7. Re: extending form / task functionality
                      kukeltje

                      Me to, 2.5 years ago we were owned by all major dutch insurance companies and got sold to a big American company (ADP) and became part of their claims handling division.. Half a year ago this claims related division was sold to an investor company (Solera), so we went from 200 to 40.000 to 2000.

                      • 8. Re: extending form / task functionality

                         

                        "kukeltje" wrote:
                        We then have the combination of direct sequential execution of tasks and real pageflows separated from the processdefinition.

                        If at least we (you and I) have these requirements, I bet they are interesting engouh for others as well. I'll file a jira issue to develop this functionality in jBPM


                        I don't know about others, but it seems to me this could be a really nice feature to have, since most processes (e.g. people executing processes) involve some kind of GUI.

                        Let me explain further on this subject: regarding BPM, business process modeling and applications development, I tend to think in terms of processes and not applications (kind of 'process driven development'); this way, processes need applications, or even fine-grained pieces of an application (maybe just a single page for a given task).

                        If we had this feature in jBPM, we would have an 'integrated' view of our model, considering the process by itself, along with people (roles), and applications (JSF/Facelets pages). Somehow, jBPM engine should be able to figure it out what path to follow, given the process definition, and using process instance variables state. This way, you won't have to embbed any "navigation" logic in your Java code (not even in faces-config files), since this would be handled by the jBPM engine.

                        What do you think on this?.

                        Regards.

                        • 9. Re: extending form / task functionality
                          tom.baeyens

                          a wizard always relates to 1 task. the form in that case is just spread out over multiple pages. we currently don't forsee support for that in our default webapp console forms mechanism.

                          getting the next task of the process if it is assigned to the logged on user is fairly easy to add to the current webapp. After a user ends a task in the task form, the webapp could check if there is a new task assigned to this user. If so, navigation could be redirected to this task form instead of the task list home page.

                          does that answer the question ?

                          • 10. Re: extending form / task functionality
                            kukeltje

                            I agree with Tom that initally there is no support for wizard style task handling. Since Seam already has pageflow and jBPM can be used to create those, I do see synergy in this.

                            • 11. Re: extending form / task functionality

                               

                              "tom.baeyens@jboss.com" wrote:
                              a wizard always relates to 1 task. the form in that case is just spread out over multiple pages. we currently don't forsee support for that in our default webapp console forms mechanism.

                              getting the next task of the process if it is assigned to the logged on user is fairly easy to add to the current webapp. After a user ends a task in the task form, the webapp could check if there is a new task assigned to this user. If so, navigation could be redirected to this task form instead of the task list home page.

                              does that answer the question ?


                              I was thinking more of automatic execution of a form by an integrated mechanism (not having to wire it). I know you can do this via Seam, jBPM and pageflows. However, wouldn't it be better to have all this information defined in a single file? I mean, shouldn't this form-attached-to-a-task be part of the process definition? At this moment (and you can see it in the dvd-store example), you can have different jpdl definition files, and they seem unrelated among them, there is no unified view of your process and the forms it needs to run. Besides, it is not clear how roles apply to pageflows and forms; roles are (at this moment) related only to tasks, which is correct, but they should also be related to pageflows (IMHO).

                              On the other hand, a single file containing all this information would be (at least for complex processes) unreadable. Considering this, a single file is NOT such a good idea. Maybe, you could have multiple diagrams/files (even sub-processes), each one describing part of your process, including any necessary pageflows. This way, you don't need a huge file, but a set of related files each one describing a part of the process. So, you could model an extremely complex project, without the burden of a complex and hard to understand file. Yet, the only requirement would be that the files were related somehow (jBPM/GPD managing these relationships), because is not so useful to have multiple jpdl files and not having a precise definition of how they relate to each other.

                              Regarding the automatic redirect, I'm not sure if that would be a nice feature. I mean, what if you don't want to execute that task at this moment?. That?s why you have a task list, to execute tasks whenever you want.

                              What do you think about this?.

                              Regards.

                              • 12. Re: extending form / task functionality

                                By "automatic mechanism" I meant this: as soon as you click on a link, jBPM engine already "knows" which form is needed, then shows it to the user.

                                • 13. Re: extending form / task functionality
                                  tom.baeyens

                                  forms are not included in the process definition because they are too big. also, we moved to xhtml facelets files for forms. this adds extra customizability for the users. meaning that the gpd can create flat list forms, but the users can easily customize these forms and make the user experience better.

                                  it remains to be seen wether in real intranet applications, the forms mechanism will be used. for some reason or another projects always include their own UI, not leveraging the task UI included in jbpm.

                                  let me know if this doesn't answer your question

                                  • 14. Re: extending form / task functionality

                                     

                                    "tom.baeyens@jboss.com" wrote:
                                    forms are not included in the process definition because they are too big. also, we moved to xhtml facelets files for forms. this adds extra customizability for the users. meaning that the gpd can create flat list forms, but the users can easily customize these forms and make the user experience better.


                                    Please pardon me, I didn't mean "include the whole form definition", but a "link" to the page (a la JSF). Of course, managed by jBPM (they way you can actually do by using pageflows, but in a single file --> process definition + pageflow definition).

                                    "tom.baeyens@jboss.com" wrote:
                                    it remains to be seen wether in real intranet applications, the forms mechanism will be used. for some reason or another projects always include their own UI, not leveraging the task UI included in jbpm.


                                    I agree with you, I think most developers will want their own look and feel, but I don't know if it's desireable that you need to develop/code the dependencies between tasks and forms; have you seen Carnot? I'm thinking of something like that; please take a look at http://www.carnot.ag/products/workflow/products/rad/products/rad/casabac-en.htm). However, I think pageflows are a more powerful mechanism than just defining a single page, but an integration directly from the GPD would be nice (IMHO).

                                    Let me know what you think about this.

                                    Thanks for your time.[/url]

                                    1 2 3 Previous Next