- 17.9K All Categories
- 3.3K Industry Applications
- 3.2K Intelligent Advisor
- 59 Insurance
- 534.1K On-Premises Infrastructure
- 137.6K Analytics Software
- 38.5K Application Development Software
- 5.3K Cloud Platform
- 109.1K Database Software
- 17.5K Enterprise Manager
- 8.8K Hardware
- 70.8K Infrastructure Software
- 105.1K Integration
- 41.5K Security Software
Oracle BPM - Human Task Design perspective
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:
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,
Middleware version: 184.108.40.206