(4 votes, average: 4.00 out of 5)
Loading ...Yesterday a reader of Siebel Unleashed asked an interesting question stating a requirement. I thought it would be interesting to share that requirement with all of you and know your thoughts on it.
Question:
I want to display records from 2 Siebel tables in a single applet. Is it a good idea to create a VBC and fetch records from both Siebel tables and display it in the UI? If yes, how can I achieve that? At least high level steps.
Answer:
Surprise…… 
I was about the post the answer (basically my thoughts not a solution) to the question but then I thought to do it a little differently. I wanted to hear your thoughts about this requirement first and then see if it matches the answer I was thinking.
I am pretty sure there are lots of smart people out there with lots of experience who can guide what is best possible way to do it. I will share my answer on Thursday.
So you have 2 days to post your thoughts and answers to this question.
Stay tuned
————————————————————–
Three people contributed and provided an answer. I must say that they covered all the options that I had in mind. Jimit came really close to what I had in mind. Here is what I was I was thinking.
The first question that came to my mind was:
Are these tables related?
If yes, then as Jimit correctly pointed, use join. If they are not related in anyway, then we are open for options of using EBC or VBC. As Graham has correctly pointed, that this technical solution needs backed up by a careful functional analysis.
Let’s weigh both options:
EBC: It is easy to implement and maintain in Siebel but we have to create a view at database level that performs union of tables as suggested by Viktor. So, you have maintenance problems if there is some change in table schema and also it will be readonly.
VBC: We assume that both the tables are in same schema as other Siebel tables so it is easy to create Business components on that table. So, VBC option is easy to maintain as through scripting we can instantiate both business components and do display them in whatever we want to or we can follow sINDhuja’s approach create IO based on those Business Components but it requires more effort to implement as compared to EBC.
This is where functional analysis comes into picture which will help us to decide us on approach we need to take.
I would like to thank Viktor, Jimit, Graham and Sindhuja for there contribution
Authors bio is coming up shortly.
Loading ...
Hi.
If you need only to display it, make DB View as union select. Then make Table in Tools to match that new View, do not apply this table.
BC will be fine for reading.
Option 1 : [Straight Fwd - VBC]
Create a VBC. Write eScript to retrieve the data’s from required BC’s and display it in applet.
Option 2 : [With IO - VBC]
Create a VBC, and an IO with required IC’s. Using EAI Siebel Adapter BS, reteieve the result and give it back to VBC to display on Applet.
Option 3 : [As suggested by Viktor using DB View and EBC]
1. Create a view with Req Tables and columns. [union Select]
2. Export the View’s Script and import the Script into Siebel tools under the object “External Table Schema Import” to create EBC.
3. Create a BC based on this table.
4. Create Applet based on this BC.
all the above are my thoughts… [as neel mentioned..]
As long as the data is only being used to read then an EBC on a view will be a good solution, it has a “short” path to the database and so will give a good level of performance. However, updating or creating records through this route will not be supported by Oracle.
If a full CRUD solution is needed then you’ll be forced into the VBC route, as you then have the control (within script or any other technology you use to implement the background logic) in order to implemented your business rules and logic so that the database integrity is maintained.
This technical solution needs backed up by a careful functional analysis though. Why do the two BCs need combined? How will updates be handled? What are the relationships? Often exploring these sort of questions uncovers that a carefuyl structuring of the view and the applets within it are all that are really needed to solve the business requirement; remember that by creating an EBC or VBC to meet the requirement you are implying an ongoing maintenance cost for the life of the implementation, an operational cost that the business will not necessarily have considered when they wrote the requirement!
Hi,
There can be two things.
1) if both table is related with each other, one use join at BC (Based on any one of the Table) level and display the fields on the aplpet. and if the tables are related in such a way we can make one table as ane extention of the other table, then nothing like it, easily we can show the data of two tables in single Applet
2) If both tables are completly different..and not even related to each other, one can create a new table(union or atleast has all the columns to store data of both the tbales) and BC on the new table. Use Trigger(Database layer solution) on both the table, and whne record inserted, insert the same record on this new table). BC,BS (Siebel business layer solution) use of writerecord event to insert the data to new BC as well. Additionaly you can filter the data by adding the type to the new table according to need.
and create a applet on this new BC(pointing to the new table-combine data of both the tables).
Else as mentioned by other people(Victor,sINDhuja Lingaswaran ,Graham) EBC(with view on db) and VBC option is always open and easy to implement.
cheers,
Jimit
can you explain more about DB View as union select? how to create it in siebel.
sorry forgot to mention Jimit in end. Just updated the post.
Hi Guys,
I am not sure whether I have understood the requirement correctly. But I have one option to the above issue. We can create database view for the 2 tables and then we can create BC based on this view. Siebel supports creating BCs based on views. I will try to post more information on this topic.
Thanks,
Subbu
The only problem with the DB View is that you cannot update a view. Even if you jump through all the hoops to make it a properly materialised view (and so updatable as far as the database is concerned), updating data through a View is not supported by Siebel.
For this particular scenario this is the reason the VBC is probably a better route, as it offers you the ability to update as well as to read.
cheers,
Graham
Till now, i know what is VBC and for what it is used for. But studing at this article, i comes to know about an idea about VBC, EBC and new one (DB View and EBC). Thanks Neel.
Hi,
I came across this forum recently n found it very interesting.Good going buddies, keep up the good wrk
I have a query regarding Siebel VBCs. As per the bookish defn. they are used for displaying external data onto the Siebel UI, if its so, how do we explain the use of VBCs in Siebel 8's homepages. The Screen home pages like: Accounts Home Page, they use VBC to display some quick data like: Recent Records, iHelp, Add and Search.
Thanks,
Shravi
Shravi,
An IO is suppose to be used in integration with another application and is fundamental entity in any integration but if you search in this site you will be able to find example where IO is used in configuration (no integration) and do things like copyin entites etc. I think what bookshelf is trying to state in defination is the primary purpose of the VBC but you are not limited to it.
Use your imagination and you can use it in various places.
I think VBC is used for two purposes
1. Display data from external applications.
2. Display data that resides in siebel. for example displaying Product config data in a list applet which is not possible otherwise.