I know … I know that Task based UI has been hailed as next big thing in Siebel and is only available in Siebel 8.x version and you might have already raised your eyebrows on hearing Siebel 7.8 instead of Siebel 8.0. So, what do I mean when I say Task based UI @ Siebel 7.8?
For those who have worked in Task Based UI will know that Task Based UI is nothing but a bit more configuration to display applet in a different way and guide user through a business process using a wizard like interface. For Task Based UI to work you have to create additional applets and views and then use Task Designer and develop a business process.
I have not worked much with Task Based UI but from what I heard that is a nice functionality to have but with kind of bugs that are present you are better off without it.
It is really difficult to create a complex business process using Task Based UI. I might be wrong but I would really like to hear your feedback on this. Do post your experiences in using Task Based UI
When I say “Task based UI @ Siebel 7.8”, I mean that it is possible to create something similar in Siebel 7.8 (It should be possible to do this in Siebel 7.7 also but I have tried it in Siebel 7.8 only). So, for companies who were looking to upgrade because of Task Based UI only ( I know it can never be the only reason but still.. it grabs your attention doesn’t it
) they can try this approach and see if it of any use.
With combination of Smart Scripts, Hidden views, Interactive Workflows and a bit of scripting it is possible to have same Wizard based UI that can take user through a business process and also have functionality like “Save For Later”.
I will be posting a video presenting demo of what I am talking about, in next few days and will discuss technical details and how to actually implement it. So, stay tuned for now I am just attaching few screenshots to give you a bit of idea.
I will be discussing about its limitations and compare it against Task Based UI in next post of the series.
Next in series >>








Hi there,
First of all, I can say I have expert knowledge of Task UI in Siebel 8.0. To answer your question:
No, it is not difficult to develop complex Task UI process, when you know how it really works (no how it should work), what are “don’ts” and know about bugs. Task transactions are so weak and badly coded, you will have to make more complex tasks Transactional=false, in turn loosing one of benefits of using Task UI. Tasks are pretty hard to test.
To sum bugs/issues up:
1. You have to have primary BC context, even if modifying BC or TBC that is unlinked to primary BC in task’s BO. This leads to dummy queries and dummy records and complicates Task UI context.
2. Call/pass through commit step in your task process and your TBC data are still here. No big problem? Use that TBC later in task and you will receive random error “record was modified before it was retrieved…”.
3. There is no easy way navigating user to another view after task completes. Pretty common requirement in business processes.
4. No control over BC’s visibility in Siebel Operation steps. Mostly you will have to disable it.
5. Parent task and its sub tasks must use same BO. This dramatically lowers subtask usage.
6. No customization of Task UI engine messages (like “are you sure to cancel current task?”)
7. Some context issues when using workflows.
And now hold your hats
:
All of these issues are present in 8.1.
Viktor,
That is great info.. thanks for sharing this with all may be it will help somebody while working with Task Based UI.
But one thing is clear now, there are bugs in TBUI and it is not easy to actually get this thing working.
I hope there are others out there who will sharing there thoughts with all.
Task Based UI is ofcourse a new thing and useful functionality but the bugs arising with it is very difficult to handle as you need to go through log files for the bugs…Hence better you avoid it.
Viktor,
I agree there are some defects in TBUI and i am not an expert in TBUI but to clarify some of yours bugs/issues:
1.) TBUI is implemented to be remained in the context of Primary BC so as keep its handle through the task on a single record refrence.
2.) TRUE, it will throw the Error if you retry to use the same TBC as the refrence is not changed.So its better to create a new TBC if you want to use it after Commit step in your task
3.) Navigating to view other than the one where TBUI was started can be considered requirement and not an issue which Siebel does not provide OOTB.
4.) Yes we can consider it as a Bug that there is no control over the BC visibility
5.) As explained for First point the reference of the record need to kept through out the task,thus may be we have to make less use of Subtask but in highly complex and strategical requirement of branching (Like region wise usage of task), we can consider the Subtask in to picture
6.) YES, NO control over the vanilla Error message (Can be considered as an issue)
7.) Context issues of WFs can be resolved by using some logic.
Every thing is not a flaw but then nothing is flawless.
Prince