Forum Stats

  • 3,758,157 Users
  • 2,251,345 Discussions
  • 7,870,070 Comments

Discussions

Oracle BPM - Human Task Design perspective

Moe_ADF_541
Moe_ADF_541 Member Posts: 241

Dear Experts,

I would like to know your expert opinion in the following design/architecture matter. Consider the BPM application below, having 'ADFBPMProject' as the BPM project, and 'ADFBPMUI' as the Human task generated project:

pastedImage_1.png

For developing a BPM Process having a multitude of human task activities, there are possibly two basic solutions (maybe more? kindly advise):

1- It has been found highly more efficient if the development of these human tasks is taking place directly on the BPM payload, meaning that we add our logic, managed beans, task flow modifications,etc... directly on the human-task-based task flows (SubmitADFBPMHT_Taskflow, ReviewADFBPMHT_Taskflow, etc... in the screen shot above), modifying the payload directly, with no direct database interaction whatsoever.

2- conventionally, we create a separate ADF application, interacting directly with a database, deploy this ADF application as an ADF Library jar, and then import this ADF library jar to the BPM UI project.

Now after implementing these two solutions in several different projects, I have come to the following results:

- When using solution '1', we are no way promoting re-usability; we are developing the same human task over and over again and creating possibly the same functionality over and over. This is extremely time-consuming, nerve-wracking, in-efficient way of working, especially when there are a many human tasks for a bpm process, but it shows significant advantage in application performance and overall speed.

- When using solution '2', we are indeed promoting re-usability; since in the separate ADF application we are creating possibly one and only one task flow, used over all the human tasks of the BPM project, where behavior changes or actions are controlled by flags sent as parameters to this common ADF taskflow. This is a one-time development, directly interfacing with the database, highly efficient when considering team collaboration and efforts, but it presents one possible set-back: if for some cases a decision needs to be taken at the level of the back-end (possibly a BPM activity) that needs to access the database, there will be effectively two applications accessing the database instead of interacting with each other (the separate ADF and the BPM), which kind of does not make sense that these two cannot directly interact with one another, and this has shown some significant performance issues at the level of the back-end.

Apologies for the lengthy discussion, but I would really like to get professional advice on how such cases are handled as per standards and best practices.

Looking forward for your input,

Kind Regards,

Middleware version: 12.2.1.3

Answers

  • Martien van den Akker
    Martien van den Akker Member Posts: 2,776 Bronze Crown
    edited May 28, 2019 4:54AM

    Hi Moe,

    What I tend to do in these situations is:

    • I generate my UI using the wizard (not completely automatic), so I can just choose which parts of the UI I want to show and how I want to have this or that generated.
    • I create my task UI's into a separate application workspace. This allows me to create a application wide deployment profile, so that all the UI's from my BPM projects can be combined into one ear file. Also my BPM application workspace is not cluttered by the UI projects.
    • I create a project per task UI, don't combine multiple task UIs in one project.
    • I try to create my BPM payload as small as possible, containing only that info that is needed for the BPM process. Also BPM process data is as confined as possible. Preferably only entity id's. What's needed at certain points is fetched in a (embedded) sub-process using DB adapters or services  in a local scope, when needed.
    • It's recommended to fetch the data in the ADF screen from the database based on the id's in the BPM payload. Then the UI will show the latest info and the user could update the data directly in the database. There can be some time between creating the task by BPM and opening the task in the workspace. Then there is a chance that the data can be out of date when the user opens the tasks.
    • I'm not a core ADF developer. In a BPM centric project, when you reuse the default workspace, it is ok to have a workspace with the more or less generated task UI's. But in a more ADF centric project, where there is a separate ADF application, most of the times we (ADF developers) create screens based on a ADF TaskFlow based on a Human Task.

    Hope these thought-points help.

    Regards,
    Martien

    Moe_ADF_541
  • Moe_ADF_541
    Moe_ADF_541 Member Posts: 241
    edited May 29, 2019 1:01AM

    Hello Martien, and thank you for the most informative reply.

    Indeed we tend to do most of the points you mentioned. But eventually, we end up repeating ourselves in development. Say, for example, that there are multiple requesting users, with more or less similarities in their application forms, with multiple reviewers, etc... if you see the pattern here we always face repeated functionality which could be solved by using a separate ADF application deployed as an ADF library jar. The problem only gets bigger if we create screens based on ADF taskflow based on human task. Bottom line is that we always end up, in my opinion, wasting time by doing the same development all over again.

    That's where the idea of creating a stand-alone application that will replace the BPM workspace came from. Using either Java or REST API's for BPM to construct a Java JEE (perhaps Spring) or Javascript framework (perhaps React JS) to construct a fully independent application that will act directly on the payload and whose functionality would be encapsulated in the BPM API's (either REST or Java API's or Java API exposed as REST, etc...), which I find way more practical than most out-of-the-box capabilities (ADF based on human task, multiple UI projects, several human tasks developed separately, etc...)

    Kind Regards,

  • Martien van den Akker
    Martien van den Akker Member Posts: 2,776 Bronze Crown
    edited May 29, 2019 2:10AM

    Hi Moe,

    Indeed. In most projects we create a dedicated application. Mostly also because it has many other functionalities. Then the task list drives the worklist of the application, but the info is fetched from the database using the id's in the tasklist.

    Regards,
    Martien