Almost 90% of new IBM BPM adopters are asking this question
to implementers rather asking the product owner (IBM) before buying this
product. Does it worth spending money on developing custom inbox/portals? Honest
answer is big NO.
Out of the box portal is JSP page which directly interacts
with DB using AJAX listeners. Also it has more features like task
assignment, task auto claim, task routing and etc. OTB portal has dynamic inbox
component, if another user picks a task which assigned to group, listener senses
it and removes that task from user inbox as it is currently owned by other
user. Task list in your inbox is more dynamic with lots of event listeners
which directly interact with DB seamlessly.
What if I develop a custom inbox using coaches? Either I can
query the database to get the list of tasks which are available for the logged
in user or use TWSearch API to find out list of active and eligible tasks for
the logged in user. Can I build a dynamic task table? Yes, but it is very
complex and added more and more events listeners in on coach, it will slow down
the coach performance and it can lead to script time out errors in IE(you can’t
run more than 500k lines of script )
If I go for DB query approach, I need to query DB for every time and it does not seem to be right option if you want to build custom inbox for larger group. If it is very small group of people, it is okay. If you have 100+ concurrent users???
What if I user TWSearch API? Few organizations, they don’t allow
developers to directly interact with product DB. In such cases, you may have to
go for this option. It is like adding one more wrapper to DB approach. Instead of
directly interacting with DB, you are using API’s to convert your code into DB scripts
and get the response back. It is does not seem to be right option if you have larger
group.
Forget about data
population for now, if I think about coaches. It is always slow performers and
building dynamic view/table using coach. It will be over head for browsers to
run thousand lines of client side scripts in less than a second.
Last thing, if you get into any issues with performance or
product related issues. IBM won’t directly support your custom inbox and raising
a PMR and get it fix will take million years.
do you have OTB and custom inbox comparison performance stats?
ReplyDeleteI know that sometimes it looks stupid, but for some users the table view (saved searches) that combines business data and process data is necessary. Click on each task to see the business data or search for a specific data isn't good enough for them. They need to see all data, already loaded, on a table view to decide which task they want to run.
ReplyDeleteSad but true.
Yes, Custom inbox mechanism lead to performance issue. Gathering instance / business data through DB/TWsearch using coach/coach view in client side will be very slow and often script get time-out. We implemented TWsearch for custom inbox which is getting time-out in 20 seconds for 12k records. After that we have tuned infinite loop deduction policy in 100Custom. But we faced same issue & got time-out in 60 seconds for 35k records.
ReplyDeleteCustom inbox approach fails when we have larger data.