Module Overview Welcome to Configuring Navigation This module teaches students how to create and configure some of the navigational aids in Siebel applications.
This module will attempt to: Describe how to configure drilldown for a View Describe how to Enable the Thread Bar Describe the steps necessary to Configure Toggle Applets
A drilldown allows the user to drill down from a cell in a list applet to a designated view. Drilldown controls or list columns in a list applet in Siebel application consist of colored, underlined text, much like a hyperlink in a Web browser. The user clicks a field in the record and is taken to another view. Static drilldowns are called ‘static’ because you always end up at the same destination view, no matter what the value of the field that was clicked. For example, drilling down on the account field in a contact list applet will normally navigate the user to the account detail view. Dynamic drilldown enables hyperlink navigation to multiple views from the same hyperlink field, depending on the value of a field in the applet’s current record. This is useful in the situation where special processing is desired for various types of contacts, opportunities, accounts, and so on. The business component may have a field that indicates a classification, such as the Lead Quality for an opportunity or the primary Industry for an account. The drilldown behavior can be to check this field in the current record, and navigate to different views for different values found there.
This slide defines static drilldown within the same business component. Note that static drilldown within the same business component is most frequently seen in the list applet of a More Info view. The screen shot shows a static view drilldown implemented in the Contact list applet (on the left). The contact of the record is maintained (so we are still looking at the record for Ross Allen). The drilldown was configured on the Last Name field, not the First Name; and the drilldown action navigates to a view where the information is based on the same business component as the BC from which we are we’re drilling down. In this example, we drilled down to the contact detail view where we can more information for the the specific contact we drilled down, as well as the activities associated to this contact.
Let’s use the example in the previous slide to create a new static drilldown. A user navigates to the specific applet object and selects the child object “Drilldown Objects” in the object explorer. The example uses the Contact List Applet. A user then needs to specify the desired field to be drilled down, in this case that field is “Last Name” as well as the desired navigation view, which is the “Contact Detail View”. In this example the name of the drilldown object is “Original”, original is the vanilla name Siebel uses. The name of the drilldown object can be anything, as long as it is unique in that applet.
This slide defines a static drilldown to a different business component. Don’t confuse this concept with a dynamic drilldown. This is a different concept that we will explore later. A drilldown to a view using a different business component is configured a little different and requires a little more information. In the screenshot, our starting context is on the Contact List Applet. Then we want to drill down to the Account Form Applet inside the Account Detail - Contacts view. This means our context has moved from the Contact BC to the Account BC.
This slide shows the extra properties we need to set in order to configure the definition for a static drilldown to a different business component. The screenshot shows how the drilldown illustrated on the previous slide is configured. Note that we have to specify additional information: The BC to which we are navigating – in this case the Account BC The name of the foreign key field in that source BC that will match the primary key field in the target BC. In this case, the foreign key field is the Account Id, because the Account Id in the Contact BC is the foreign key to the ROW ID in the Account BC. In this example the destination field is left blank, because it is implied that the destination field is the ROW ID. We only need to populate this field if we use a primary key field other than the implied ROW_ID column.
This slide defines dynamic drilldown. In most cases, a dynamic drilldown is generally to a different business component. This screenshot shows the Expense Report line items. Drilling on the Type field in a record where the value is of the field “Hotel” takes you to a view with information specific to hotel expenses, while drilling on the same field in a record where the value of that field is “Mileage” takes you to a view with information about mileage expenses.
Here are some items of business logic the developer should determine before configuring a dynamic drilldown. Since a dynamic drilldown is determined by a value within a field with the applet record, a developer must specify the conditions to navigate to a particular target view. On the previous slide we saw Hotel and Mileage as the matching conditions (values) to trigger the hyperlinks. An order must also be specified when configuring a dynamic drilldown since multiple matches could occur. A winner is selected that contains the match given the highest priority.
The screenshot shows how the dynamic drilldown illustrated in the previous slides is configured. First, you configure a drilldown object for each destination view. These create the set of possible places to go. Each drilldown object will also have a sequence number. The conditions that dictate which view is drilled down to are specified in the ‘dynamic drilldown destination’ (DDD). This is a child object of the drilldown object. You must configure this for the drilldown object with the lowest sequence number, and best practice is to configure it for all. (The sequence number also enables “priority” for a drilldown object – if the user double-clicks in a row with one or more drilldowns configured, the application navigates based on the drilldown with the lowest sequence number.) For example, You might have one form applet for hotel expenses, and another for miscellaneous expenses over $500. You want all hotel expenses to go in the hotel form, even if they are over $500. In this case, you would configure a DDD object for each form. The DDD object for the hotel form would trigger if value of the expense item type field was ‘Hotel.’ The DDD object for the large miscellaneous expense form would trigger if the value of the amount field was over $500. Finally, to make sure that hotel expenses over $500 go in the hotel form, you would give the DDD object for the hotel form a lower sequence number.
This is a checklist of general principles for configuring a dynamic drilldown without unwanted results. Where do you want users to navigate to when there is no matching condition? The default should always be the last item to check in the sequence, and should have no matching condition. If no default is defined, and no matching condition is met by a given record, the drilldown will do nothing (that is, the user will continue to see the current view). Configure a drilldown object that navigates to your target view (that is, set these properties to define the required target/destination view at which users should arrive). Each target view must be specified in a drilldown object (DO) definition. Each condition (Dynamic Drilldown Destination (DDD)) should point back up to a drilldown object. If you fail to do this, it may cause a loop.
Thread bars track the user’s navigation through views. The thread bar updates (that is, adds another view to the thread bar) when the user navigates to a new view in another BO. For example, if we were to drilldown on the Account field, in the Contact List Applet the thread bar would be updated, because if you remember, this particular drilldown navigates the user to a view that uses a different business object, the Account business object. The thread bar allows a user to navigate easily back to the previous view. For example, let’s say the user does drilldown on the account name and navigates to the Account Detail View. If the user wants to go back to the contact list applet, they can simply click on the appropriate thread bar to go back to the highlighted contact record.
This slide shows how thread applet and thread field definitions relate to the appearance and behavior of the thread bar. Note that while drilldown is configured on a field of an applet, thread bar properties are configured on a view. This example uses the Contact Detail View. The thread applet and the thread field property specifies the record to remember in the hyperlink as well as the thread title represents the prior business object. As you can see in the screen shot on the left, the configured thread bar shows the Contact business object and the last name of the contact that was drilled down. In this example, the last name was Corning. If a user was to invoke the hyperlink in the thread bar, the user would navigate back to the contact form applet with the contact record of “Corning” highlighted.
To enable a thread bar, the template associated to the applet must include a thread bar tag. This tag should reference the external CCThreadbar.swt template file. This is just something to note as most developers do not have to include this tag themselves. This tag already exists in all vanilla applet template files.
In review, a drilldown is configured on a single field. A thread bar is configured on a whole view. And a new concept, the applet toggle, is configured on a whole applet. An applet toggle is used to navigate to a different applet containing different information, but different information based upon the same business component. For example, an applet toggle could be used in the Notes view within the Opportunities Screen, to toggle between Public Notes and Private Notes. Both of these Notes views contain information based upon the same business component. In the example above, a user can toggle between a Designer View or a Steps view. The designer view is on the right and the Steps view is on the left.
Let’s configure the definition for an applet toggle based upon the previous slide’s example. Keep in mind, when a toggle is defined on an applet, it will appear in every view where the applet appears, even if it makes no sense. In addition, a toggle defined this way can give users access to an applet to which they should not have access. Therefore, if a developer needs to create a toggle on an applet which is used in multiple views, it might be better to create a copy of the applet, then replace the original on those views where the toggle makes sense. To configure the the applet toggle from the previous slide, you can see that we simply specify what applet the user should have the ability to toggle view in the Applet Toggle object. This is a child of the applet object in the object explorer window within Tools.
Toggling is not reciprocal. That is, if you define an Applet Toggle object on applet A, and define applet B as a toggle applet for that toggle, applet B will be available as a toggle in any view where applet A is defined as a view Web template item. However, if applet B is defined as a view Web template item, this will not include a toggle to applet A unless you define a separate applet toggle object on applet B and define applet A as a toggle applet for that toggle. So if I wanted to be able to toggle from private notes to public notes, I would specify public notes as my applet toggle on the private notes applet, but I would not be able to toggle back to the private notes applet unless I also create an applet toggle for private notes on my public notes applet.
Like thread bars, the togglebar tag must also be included in all applet templates. Again, the applet toggle tag exists in all vanilla templates so most developers would not have to worry about this.
Dynamic toggling can also be configured in Siebel tools. Dynamic toggling is controlled by the application rather than the user. This is similar to dynamic view drilldown, in that the applet that appears is determined by the value in a specified field (in the displayed record). For example, the contents of the Type field in the list applet determines what applet is displayed below.
In more detail, if the record that is highlighted in the list applet has a type value of Single, then the form applet on the right is displayed. If the user navigates to a record in the list applet with the Type field of Matrix Based, then the form applet on the left is displayed.
Let’s look at how to configure the definition for a dynamic applet toggle. The Screenshot shows how the toggle illustrated on the previous two slides is configured. The important attributes to consider are Auto Toggle Value and the Auto Toggle Field. The Auto Toggle field is the field name and the Auto Toggle Value is the value to check for that specific field. In the first applet toggle, the field is Type Language Independent, and the value and if the auto toggle value is Single, we then want to make sure that the Pricing Factors Detail applet – Single is invoked. Again the sequence attribute determines priority since multiple matches may occur if different field names are used.
Now that you’ve completed this module, you should be able to: Describe how to configure drilldown for a View Describe how to Enable the Thread Bar Describe the steps necessary to Configure Toggle Applets