Friday, September 26, 2014

Can I develop a custom inbox using Coaches?

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.

Considering above drawbacks, I won’t really recommend it to anyone. But there are many customers willing to try this and to give up after spending lots of money on product and coach development. 

3 comments :

  1. do you have OTB and custom inbox comparison performance stats?

    ReplyDelete
  2. I 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.
    Sad but true.

    ReplyDelete
  3. 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.

    Custom inbox approach fails when we have larger data.

    ReplyDelete