New Comment System@Siebel Unleashed.. Do Try and give me feedback | Next Tip »Home
Written on October 27, 2009 at 2:07 am by neel

tale of 2 tables and a VBC

Filed under Configuration, eScript View Comments
OkAvarageGoodVery GoodExcellent (4 votes, average: 4.00 out of 5)
Loading ... 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

  • Share/Bookmark

Related Posts


Article by neel

Authors bio is coming up shortly. neel tagged this post with: , , Read 387 articles by neel
  • Doss
    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.
  • Graham
    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
  • Subbu
    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
  • sorry forgot to mention Jimit in end. Just updated the post.
  • Piyush
    can you explain more about DB View as union select? how to create it in siebel.
  • Jimit
    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
  • 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!
  • sINDhuja Lingaswaran
    all the above are my thoughts... [as neel mentioned..] :)
  • sINDhuja Lingaswaran
    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.
  • Viktor
    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.
blog comments powered by Disqus
audit trail Best Practices Case Study Check In -Check Out Configuration Data Source Downloads EAI eScript Forum How To Informatica Introduction I Wish I Knew Jobs List of Values Logs Metalink Office Humor Oracle MetaLink Performance personal Problem Solutions Product Configurator Runtime Events Scripting Scriptless Siebel siebel Siebel 8.0 Siebel Admin Siebel Administration Siebel Analytics Siebel EAI Siebel Testing Siebel Tools Signals smart script SQL task based ui Tips User Properties User property Web Services workflow Workflows

Polls

Do you like the new Comment System and new look to Site?

View Results

Loading ... Loading ...