4 Replies Latest reply on Jun 19, 2012 2:27 AM by Ravi Jegga

    Integrating BPM taskflows into an ADF application

    Yannick Ongena
      We have a lot of processes that need to be integrated with an ADF application and we have a discussion about where to put the implementation of the taskflows of these BPM tasks.

      BPM allows us to auto generate the taskflows based upon the payload of the process. This does not allow a lot of flexibility to change the taskflow. If we change the taskflow and have to generate again, we lose the changes we made.
      The BPM architects say that we will gain a lot of time by autogenerating. The ADF architects (like me) say that it's better to build those taskflows ourself and put them inside the ADF application (or ADF LIbrary jar). This way we have full control over the code.

      One of the main reasons why we are not that fund of using the autogeneration is that we have a detailed UX guideline that requires some special attention of the development of an ADF page. When autogenerating the taskflow, we probably have to change quite a lot to make it compliant with the UX standards.

      The question is, do we have control over the autogenerated taskflows so we don't have to redevelop everytime we generate a taskflow again?

      What are the advantages of generating instead of developing it yourself? Being an ADF developer myself, I tend to say we have to go for the custom implementation because of the UX requirements so we have full control over the code.

      Can anybody give some more information about the generation or give his point of view about this problem.

        • 1. Re: Integrating BPM taskflows into an ADF application
          Ravi Jegga
          Hi Yannick
          1. I agree with both the arguments from both BPM and ADF architects.

          2. BPM Architects -> When we auto generate form, it does take care of lot of things. Specially it creates DataControls and Bindings for all the Task details like Task Header, Comments, Attachments, History, and custom Payload (any complex xsd schema of custom payload is parsed and bindings created). The most important things are the Actions associated for that .TASK file like Submit, Approve, Reject, MyCustomAction1 etc etc. It creates logic when to show/hide these buttons, link the actual action etc. Finally it creates taskDetails1.jspx file and corresponding page def files etc. Creating all this manually based on just .TASK file will be complex for non-bpm devlopers like pure adf developers. So I would kind of agree with what BPM Architects say.

          2. ADF Architext -> Yes, totally agreed. The final UI generated in taskDetails1.jspx is mostly non-user friendly and definetly do not meet any UX Standards specific to that company. Like a company have standard CSS defined for labels, input texts, tables, columns, etc etc. Most importantly, all the Payload elements are shown vertically one below the other. The history is shown on top. comment and attachments shown on the bottom. So I would agree with ADF architects too, that it is not user friendly and mostly do not meet UX standards

          3. Now, the real cool thing, I would see is, use both the above stuff. There is no need to use auto generated taskDetails1.jspx file. Instead we create our own custom Tabbed screens (just for example). Each tab will have specific sections. Like one tab for actual custom Payload, one tab for history/details, one for comments/attachments etc. All we do is on Each Tab, drag and drop that data control. For each Task, we do have data controls created on left side for Payload elements, comments, attachments, all other sections of a Task. Then we apply our custom CSS to those UI Parts. Since we have bindings defined, we can use them in our own UX standard defined components.

          4. Anytime payload is modified like added new fields in custom payload .xsd file. All we do is add bindings for those new fileds manually in page def file and couple of other files. And we can use them in already build existing custom jsp file.

          5. Now another approach is, most of the times, we have data on the screen coming from the backend db stuff and NOT stored in the Payload. Like Payload will just have OrderId or main Primary Key data. All the fields for that come from backend db. This happens in both ways, When we show a TaskDetails page, we query backend and get all details. Also when we Save/Submit TaskDetails all data should be saved in custom Database. Payload has NOTHING. Now in this case, we create our own EJBs to begin with having all method like saveOrder(..), getOrder(..) etc. Create DataControls for them. Create a Custom Fragment (jsff) and drop these data controls. NOW on the main TaskDetails Page, use af:region tag, and drop the page def of that custom fragment. We can use PropertiesMap to exchange data between main task and fragment. The main point, I want to say here is, in Custom Fragment, I can have totally my own look and feel and my own data from backend. TaskDetails has nothing.

          6. Also, say we have like 5 Tasks. All Tasks refer same payload (like show same payload data and for timebeing in same look and feel). The only difference is, Task1 is initiator with Submit Action. Task2 is approver with Approve, Reject. Task3, 4, 5 and other set of Approvers with same Actions (Approve, Reject). If you carefully observe the task details page auto generated for all these, they are all exactly SAME, EXCEPT for the top Actions part where you have CommandButtons and Menu Items generated. And corresponding those backend datacontrols and bindings will have only extra bindings for these actions like Approve, Reject etc. We can combine all these Actions from all the pages into one big single set. Do not copy same Save, Submit etc which are same for all actions. Just copy each action unique for each Task. Pick any one TaskDetails def page and add all unique bindings for unique custom actions into this. Thats it. You can have just ONE TaskDetails page for all the 5 Actions that dynamically show actions valid only for that .task, The button has workflow tags to render buttons (visible="#{wf:isCustomActionAvailable('APPROVE', 'bindings.customActions')}").

          7. We did similar thing and put the entire action buttons set into another file named like actionMenu.jsff. And replace the top 200 lines of code of buttons/menus with one line to include actionmenu.jsff.

          There are definetly some challenges, but we can blend one time auto generated task details with our own ux standard defined pages.

          Ravi Jegga
          1 person found this helpful
          • 2. Re: Integrating BPM taskflows into an ADF application
            Yannick Ongena
            Thanks a lot for the detailed information.

            As it seems we can build our own taskflows and put them in BPM. I was not aware of that. I thought we could only use the autogenerated TF's and change them.
            As it seems we can use use the data controls from BPM and build our own taskflows.

            Is it also possible to build our taskflows in our own ADF application?

            The reason why is that currently (autogenerated or not) the BPM taskflows are deployed in BPM. Is it possible to just use the taskflows from our ADF application so we don't have taskflows deployed on BPM? I there still a possibility to get the BPM context or isn't that possible if the taskflows are not deployed in BPM?
            • 3. Re: Integrating BPM taskflows into an ADF application
              Sudipto Desmukh
              Is it also possible to build our taskflows in our own ADF application
              Isn't the ADF Pages and taskFlows generated in a ViewController application . Do you mean another separate application ?
              The reason why is that currently (autogenerated or not) the BPM taskflows are deployed in BPM
              Do you mean the SOA Server ?

              As Ravi said I too have used Custom tskFlows embedded as regions within pages which are finally used in the default autogenerated taskforms / taskDetails pages and it works fine.
              The BPM Context can still be available(at least at the top level) since you are finally embedding everything within the autgenerated page/ taskflow.

              generally as Ravi said , we embed those custom taskflows as regions which use data from ADF BC etc and not necessarily from the payload.
              • 4. Re: Integrating BPM taskflows into an ADF application
                Ravi Jegga
                Hi Yannick
                This is another post that will address your additional questions. Its a long post :).
                Re: Not able to Run ADF jspx Pages in BPM Application using JDev Integrated WLS

                Yes, you can have TaskForms in your own ADF WorkFlow application as far as you have some dependent JARs related to BPM Workflow DataControl and Services that have APIs to access all Task details.

                If you observe carefully, by default, we create like a BPM Application that creates only BPM Project. Here we create BPM Process and all Human Tasks, BPELs and all the workflow stuff. Now when we create a TaskDetails page, thats when it creates a totally different Project like MyTaskForms (the name that we give). It adds all the ADF related JARs in the Project Classpath and ASLO add some workflow related JARs to support APIs to interface with Task details. Also we deploy this MyTaskForms as a totally Separate Project. I deploy Workflow project as SCA JAR File. And the TaskForms and any supporting EJBs projects as a separate EAR file. This means auto generated TaskForms project is just another View Controller Project with additional JARs. In above post, I gave couple of JARs for TaskForms project that has workflow modules referred.

                Unless you need heavy customization for out of box Workspace, usually its NOT worth to totally create your own workspace using all custom APIs. You can always use a blend of solution and make use of out of box stuff as much as possible.

                You can have just one TaskForms project that has TaskDetails JSPX pages for all your .TASK files. And if you can commonalize all your Actions into one big set and integrate all corresponding bindings into one page flow def file, you can end up with just ONE TaskDetails page that could work for almost all your Tasks. This way any customizatios, rework is fairly easy.

                Not only this, you can deploy TaskFlows in entirely different SOA Domain itself. And the Process in a different SOA Domain. This will still work. TaskFlow files and actual Tasks connection/relation can be seen in EM Console.

                Deployment of TaskFlows still needs a BPM Domain. Or a simple ADF Domain with additional BPM Modules deployed. Finding these modules will be tough. Hence yes, you need a BPM Domain for TaskFlows to support modules that have core Workflow APIs to get data from Tasks.

                Ravi Jegga