|








 !
!

À
 Lecture: 30 ± 40 minutes; lab: 15 ± 25 minutes

 To discuss the ideas that were introduced in the last module
(joins, mapping to joined tables) when party business components are
involved.

 Person-related business components; organization-related business
components; grouping for access control; joining party data; implicit and
explicit joins.
 À

Party Business Component
Person-Related Party Business Components
Person-related Party Business Components
Organization-Related Party Business Components
Groupings for Access Control
Party Implicit Joins
Explicit Join Definition

|



 
|

 




 !


Each objective and ³why you need to know´ should be stated aloud.

|



 
 |

 




 !


Relationships among party types can be dynamic and complex.

ü     
 Yi Wen Zhang was a contractor for ABC
Corporation. Yi then became an intern at ABC Corporation. ABC
Corporation liked her work so much they then hired her as an employee.
For most systems, there would be a separate record for Yi as a customer
contact, then as a contractor and then as an employee. However much of
Yi Wen Zhang¶s information has remained the same, such as her name,
birth date, and other demographics and skills. Because Yi Wen Zhang¶s
information is stored in several locations, many systems would have
trouble keeping her information accurate and consistent.
  Siebel addresses the multiple role business challenge via the
employee type field in the Administration ± User screen. This field has
three values: Contractor, Intern, Employee, which can be changed at any
time.
Ad hoc: an entity, such as an access group, formed for a single, specific
purpose, such as the January 2007 Big Release Roll-out Event.
  an intern is a student or recent graduate working in industry with
some or little supervision from the education institution (Broadly
equivalent to a houseman in Great Britain.)
  for non-English native speakers, @
@
@means existing or
-
  |

|
  
 
   
  being everywhere, esp. at the same time; omnipresent: @
@
@ 
  |

 
      @
@
@


 

 
|

|



 
|

 




 !


Some data models show separate entities for various types of people,
such as employees, contractors, supplier contacts and customer contacts.
The problem with keeping this information in separate entities is that
people may also have different jobs and roles which change over time.
Most systems will record redundant information about a person since
they store a record each time the person¶s role changes.

    include additional challenges, as you see fit.

|



 
|

 




 !


The point behind this diagram is that there over 160 party BCs, and a
network of relationships can be created among them, as needed to
address changes and complexities in the business environment.
In this diagram we have several of the most frequenty used party business
components. Each of these business components can be related to each
other as the need arises in the business environment. For example, need
to provide access to a set of records for a major conference next month?
You can create an access group that relates participants of that
conference, whose data, perhaps, resides in several entities: employee,
position, and account. The employees are the individuals from your
company who are presenting. The position includes individuals in your
organization who might want to view information being presented, such
as the VP of Sales, and the accounts could include a list of customers who
will be attending the conference.
Note: employees and contacts cannot be directly related to access groups.
Instead, employees and contacts can be related to organizations, users, or
positions. These, in turn, can be related to access groups. This is reflected
in the diagram.
u   

Jasmine is an employee at Acme Cable Company. Jasmine lives in a
household where she is also a customer of Acme Phone
Company. Jasmine sells cable to other companies. Jasmine's Position is
on the Sales team for many of those opportunities, and her Position
belongs to the Acme Cable Company Organization. Acme Cable is a
subsidiary of Acme Telecom, which provides phone, cable, and
internet. Another branch of Acme Telecom, Acme Phone, considers
Acme Cable to be a customer Account, and Jasmine is essentially a
Contact of that Account.
In this scenario, we¶ve viewing all relationships from Acme Telecom,
who is a Siebel customer purchasing the Siebel CRM application.
(CONTINUED ON NEXT PAGE)

|



 
|

 




 !


(CONTINUED FROM PREVIOUS PAGE)

Create an Organization called Acme Telecom, a Division called Acme
Cable Company, a Division called Acme Phone Company, a Position
called Acme Cable Salesperson. Relate it to Acme Cable. Note: Position
can be related to only one division. Create a Position called Acme Phone
Salesperson. Relate it to Acme Phone, Create an Employee record for
Jasmine. (Administration ± User > Employees)
Relate it to the Acme Telecom Organization. (Jasmine must be related to
at least one organization at this point, but can be related to more. Note: at
this point, Jasmine is also added as a contact. However, the data model
does not support movement from contact to employee since two records
would be required).
Relate Jasmine, a salesperson, to the Acme Cable Salesperson Position.
(Jasmine can also be related to multiple positions at this point).
Relate Jasmine with opportunities that she persues. These opportunties
are other cable companies. (at this point, you have to login as Jasmine to
create an opportunity for her. You can create an opprotuntiy, but the
primary defaults to SADMIN as well as the Sales Team, and these can¶t
be overridden)
Create a new employee record for Julia, an Acme Phone Company
salesperson. Relate the Acme Phone Salesperson Position to Julia in her
employee record. Relate Julia¶s employee record to the Acme Telecom
Organization.
Create an Account for Acme Phone Company (an account to which
Acme Phone will sell services). Call it Acme Cable Company. Relate this
account to Julia by specifying her as the account team.
Create an Opportunity called Big Phone Sale. Relate it to Acme Cable
Company Account.
Jasmine is now related to the opportunity. She¶s a contact in the Acme
Cable Company Account.
Verify the relationships: Navigate to accounts. Drill down on Acme
Cable Company account. Drill down on the Big Phone Sale opportunity.
Verify that Jasmine is listed as a contact under that opportunity.

|



 
|

 




 !


Before we move into the types of party business components, it is

important to know that a key feature of the party business component is
that all its record-level data is stored in extension tables, not the base
table.
With standard BCs, record data is stored in the base table. This is done to
ensure ready access to and from data in the table.
However, by storing its data in extension tables, S_PARTY is then free to
act solely as a means to create relationships between party entities, such
as accounts and contacts. As we viewed earlier, there needs to be a way
to create relationships between these various party entities. This is
accomplished by placing data in the extension tables, not the base table.
This way, business components go to the extension table to get their data.
  as stated, S_PARTY provides a i to establish a relationship; it
doesn¶t create the relationship itself. That is done by the intersection
table, such as S_PARTY_PER and S_PARTY_REL.

|



 
 |

 




 !

S_PARTY primarily uses eight tables in which to store its data. These
tables can be thought of as person-related, organization-related, or
access-control related. Next, we¶ll see how the various party business
components reference these tables.
INSTRUCTOR NOTE: this is a positioning slide. Its not necessary to
describe what¶s in each table or their relationships. For this slide, simply
list the names and how they are related.

D
 -
 
|   !"  
##
 
$
 

|  
%
 

  |
$
 
&

 



|
$
 
'

$

(
  |



)

" 




 *|&

|



 
|

 




 !


The previous slide focused on the 

 used with party data. This slide
shows how party @
i   are arranged in a similar fashion:
person-related, organization-related and access control. The party types
we just discussed in S_PARTY and the party business components to
which they provide data can be grouped into three major categories:
‡person-related
‡organization-related
‡access control-related.
u  represents anyone associated with a Siebel application.
May be someone using the application:
‡Employee at a company that deployed a Siebel application
‡Individual at a channel partner
‡Customer logging in to the Web site
Or may be someone referred to in the application:
‡Individual external to your company associated with the business
process



  related represents any group of persons or organizations
that require access to the database.
   represents any business enterprise associated with
a Siebel application
‡The company or part of the company deploying the Siebel application
(division, organization)
‡An external company that purchases your products (account)
‡A partner company that assists you in your business (channel partner)
In the next section in this module, we¶ll take a look at person-related
BCs.
  party BCs aren¶t limited to using data from a single extension
table. A given party BC may use data from several extension tables.
We¶ll see in a moment that there is not necessarily a one-to-one,
exclusive relationship between a party BC and a given extension table.

|



 
|

 




 !
!

Person-related business components all use a small number of common

tables. S_CONTACT is the primary. Some person-related business
components have additional data stored in S_USER and S_EMP_PER.
S_CONTACT stores basic demographic information, such as last name,
first name, address, etc.
A  is a person who can log into your database and has a
responsibility assigned to them that defines what application views are
accessible. For example, a registered customer on your Web site is a user.
Information for this individual, is stored in S_USER.
An 
  is a User associated with a position in a division within
your company. Employee information is stored in S_EMP_PER, and
includes typical employee information, like hire date, bonus eligibility,
and salary. Other data about the employee is stored in other tables, such
as the employee¶s name and email address in S_CONTACT.
All three tables are not always populated when a contact is added. In the
next slide, we¶ll see under what conditions these tables are populated.

|



 
|

 




 !
!!

Business layer fields in standard BCs reference directly to a data layer

table column. The same occurs with party BCs. The only difference is
that party BCs use Party Type Code.
PARTY_TYPE_CD is used to identify what party type is being recorded.
These are types we discussed earlier. For person-related party BCs, in
general they include Contact, Person and Employee.
In this example, contact data, such as first name, last name, address,
telephone number, is populated in S_CONTACT for John Doe, but since
John is not a user, no record is created for him in S_USER.
Sally Smith and Chris Jones are users, and they will each have a record in
S_USER.
Once these tables are populated, then party business components, such as
User, can extract data from them. For example, the last name field in the
User party business component will extract data from the LAST_NAME
column of S_CONTACT.
  arrows between tables indicate flow.
  the diagram has no data in the first row of S_USER to emphasize
that John Doe has no corresponding record for the S_USER table. In
reality, that row is populated with the data for another record. An empty
record is inserted for John Doe in S_USER.
  viewing only the Join property for a given party BC may not reveal
the relationship illustrated in the diagram. In many instances, such as the
User party BC referencing S_USER, the relationship is represented in
Tools under the SFV¶s Join property.

|



 
|

 




 !
!

Here we can see how multiple party BCs access data from the various
party extension tables. When the user drills down via the contact screen
tab, the same data is accessed as if the user drilled down via Employee
from site map. Same data, same record.
What if Chris Jones is an employee? S_EMP_PER is populated. This is a
good example of how the longer the record (the record starting
S_PARTY through S_CONTACT, S_USER and S_EMP_PER), the more
detailed the business component.
Now, other party business components also use these tables. For example,
the Employee party BC extracts data from all three tables, and includes
detailed employee information, like the hire date.
In this example, there isn¶t a record for John or Sally, so they won¶t
appear in the applet that references the Employee party BC.

|



 
|

 




 !
!

This slide shows the tables in which the organization entities store data.
S_ORG_EXT stores all kinds of information about organizations: the
name, its location, how many employees the organization has, whether
it¶s a partner, it¶s sales volume, etc. The INT_ORG_FLG is set to True
for both Internal Divisions and Organizations.
|
 provides a way to flag a division as being an organization. This has
consequences in terms of visibility, as we¶ll see in a moment.
An    is an account, division or organization.
Account: A company or group of individuals with whom you do business.
Division: is a group within an organization inside your company, such as
Manufacturing, or, for example, a group of people operating within a
particular country.
Organization: a company, such as a customer, a partner, or the ABC
Company. This organization is represented as an Account, Division,
Organization, Partner Organization, Competitor, etc. These types of
entities have records written to S_PARTY and S_ORG_EXT
An Internal business unit is a business unit within the implementing
company or a partner organization, and has the unique ability of granting
access to some types of records. These entities will have records written
to S_PARTY, S_ORG_EXT and S_BU.
   is another organization-related party type. It is a group of
individual consumers who are economically affiliated and share a
common purchasing or service interest; e.g., a group of people, typically
a family, who reside at the same residence, or a group of purchasers who
live in different residences. A household may have any combination of
contacts, users, employees, and partner users as members.

|



 
|

 




 !
!

In this case, we see that ABC Company ± Sales Division does not have a
record in S_BU, but ABC Company and its customer, ABC Customer, do
have records in S_BU. ABC Sales has INT_ORG_FLG set to Y while the
others do not.
A division, internal or partner, is also an organization if its internal
organization flag is TRUE (INT_ORG_FLG = ³Y´) and it has an
associated S_BU record.
An Organization, sometimes known as a business unit, is also a Division,
but has a record in the S_BU table.
S_BU table does the following:
Ŷ Permits indexing on organization name
Ŷ Supports organizational visibility
What is the impact of S_BU on visibility?
When the user selects My Accounts in the list applet, the applet lists all
accounts related to the user.
When the user selects All Accounts, the applet lists all accounts in
S_ORG_EXT with INT_ORG_FLG set to Y.
When the user selects All Accounts Across Organizations, the applet
includes all accounts in S_ORG_EXT with INT_ORG_FLG set to Y as
well as all accounts in S_BU.
Now that when these tables are populated, party business components
like Account and Organization can pull up data from them to be
displayed in the UI.
     
 the diagram has no data in the first row of S_BU
to emphasize that ABC Company ± Sales Division has no corresponding
record for the S_BU table. In reality, that row is populated with the data
for another record. An empty record is inserted for ABC Company ±
Sales Division in S_BU.

|



 
|

 




 !
!

 : an ad hoc group of people. It may have any combination of

contacts, users, employees, and partner users. For example a support team
made up of internal employees who work within the VoIP Services
Technical Support Group, as well as some partner users, who work
within an OEM, Partner VoIP Card Tech Support Team. You¶d like to
allow access to the same SR records related to their common VoIP
interests. The place to do that is S_USERLIST. In this case, individual
Employees and partner Users are added to the user list, not their
organizations.


 !  can be any combination of Position, Organization, and
User List: a group of groups. For example, you could group your partner
IT service providers and business-to-business customer companies that
buy networking equipment. Or, you could group a partner community,
such as the resellers of a particular sector of your product line.
u    is a position within your company that¶s associated with a
division. For example, you could create a record with NAME =
'California Cell Phone Spanish' that will be assigned to all opportunities
meeting this criterion. When a sales representative is hired for this role,
assigning them this position will make the appropriate opportunity
records visible.

|



 
|

 




 !
!

As we observed with person and organization-related BCs, access-control

related BCs have multiple tables that populate depending on the type of
record being added.
When a record is added to S_PARTY with a PARTY_TYPE_CD of User
List, a record is also added to S_USERLIST.
When a record is added to S_PARTY with a PARTY_TYPE_CD of
Access Group, a record is also added to S_PARTY_GROUP.
Then, various party business components can interact with data from
S_USERLIST and S_PARTY_GROUP.
  when a record is added to S_PARTY with a PARTY_TYPE_CD
of Position, a record is also added to S_POSTN. Various party business
components, such as Position, then access Position information from
S_POSTN. For brevity, S_POSTN is not shown in the diagram.

|



 
|

 




 !
!

Finally, let¶s see how S_PARTY can be used to arbitrarily group records
among the various S_PARTY types. This slide, and the next slide,
demonstrate how party types can be variously connected via a network of
relationships, reinforcing the network diagram concept presented at that
beginning of this module. The main point of this example is to
demonstrate how party types can be associated via seemingly random
relationships.
Reading the slide:
1.A user list called ABC User List has a ROW_ID in S_PARTY of 003.
2.PARTY_ID in S_PARTY_PER is a FK that references ROW_ID in
S_PARTY. For the ABC User List, PARTY_ID 003, the ABC User List,
has two records associated with it via PERSON_ID in S_PARTY_PER.
3.Two persons in S_PARTY, John Smith and Mary Smith, are
represented in S_PARTY_PER via the PERSON_ID FK column which
references ROW_ID in S_PARTY.


  to demonstrate the user list, do the following:

Create a user list called ABC User List (Site Map > Administration ±
Group > User List ), and add two users to the list.
1. Identify the user list ROW_ID:
SELECT ROW_ID, PARTY_TYPE_CD, NAME FROM S_PARTY
WHERE NAME = 'ABC User List'
ROW_ID PARTY_TYPE_CD NAME
1-44XG UserList ABC User List
2. Identify the ID for the users on the list:
SELECT PARTY_ID, PERSON_ID FROM S_PARTY_PER WHERE
PARTY_ID = '1-44XG'
PARTY_ID PERSON_ID
1-44XG 1-2RNW
1-44XG 1-2ROD
(CONTINUED NEXT PAGE)

|



 
|

 




 !
!

In the previous slide we established how a Person party type can be

related a User List party type. Next, let¶s see how we can then relate the
Person and User List to an Organization. Reading the slide:
1.ABC Access Group is associated with two records in S_PARTY_PER
via PARTY_ID.
2.The PERSON_ID column associates the four records in
S_PARTY_PER with two persons, a user list, an organization, and an
access list.
3.ABC User List itself contains the two Person records discussed above.
The key point here is that any number of associations can be created
among the various S_PARTY types.
Note that employees and contacts cannot be directly related to access
groups. Instead, employees and contacts can be related to organizations,
users, or positions.
A smaller version of the network diagram presented earlier in the module
is provided here as re-enforcement for the concept that party types can be
networked together. This slide presents an example of that concept.
(CONTINUED FROM PREVIOUS PAGE)
3. Identify the users¶ appearance in S_PARTY:
SELECT ROW_ID, PARTY_TYPE_CD, NAME FROM S_PARTY
WHERE ROW_ID = '1-2RNW' OR ROW_ID = '1-2ROD'

ROW_ID PARTY_TYPE_CD NAME

1-2RNW Person Carlson, Cameron
1-2ROD Person Choi, Coery
3. Create the ABC organization (Administration ± Group >
Organizations), and XYZ Access Group.
4. Add ABC Org and ABC User List to the ABC Access Group.
5. Identify the ROW_Ids in S_PARTY for the various party types you
created:
CONTINUED NEXT PAGE

|



 
|

 




 !
!

Now let¶s take a look at how joins are handled with party BCs. This slide
illustrates the point that implicit joins with party BCs are similar to those
with standard BCs.
(CONTINUED FROM PREVIOUS PAGE)
SELECT ROW_ID, PARTY_TYPE_CD, NAME from S_PARTY where
NAME = µABC User List' or NAME = µABC Org' or NAME = µABC
Access Group'
ROW_ID PARTY_TYPE_CD NAME
1-44XG UserList ABC User List
1-44XM Organization ABC Org
1-44XQ AccessGroup ABC Access Group
6. Identify the relationships just created between the party types as they
are represented in S_PARTY_PER:
SELECT PARTY_ID, PERSON_ID from S_PARTY_PER where
PARTY_ID = '1-44XGµ or PARTY_ID = '1-44XQ'
PARTY_ID PERSON_ID
1-44XG 1-2RNW
1-44XG 1-2ROD
1-44XQ 1-44XG
1-44XQ 1-44XM
This last SQL illustrates the point of being able to relate any party to any
other party type. Here we have a party type AccessGroup of ABC Access
Group (1-44XQ) containing a party type UserList of ABC User List (1-
44XG), which itself contains two records, each with a party type of
Person. ABC Access Group also contains a party type Organization of
ABC Org (1-44XM). The organization itself could also contain other
party types subsumed within it. Relating ABC Org to the XYZ Access
Group then also relates any party types with ABC Org to the XYZ
Access Group.

|



 
|

 




 !


In this example, account Name data is brought from a Party extension

table into Opportunity, a non-party business component.

|



 
|

 




 !
!

Here we can seen that Opportunity, the non-party BC, uses one of its
joins to bring in party data from S_ORG_EXT. A join and join
specification are needed. This slide discusses how to handle the join. This
is nearly identical to what was presented in the previous module. The
only difference is in the fact that S_ORG_EXT uses PAR_ROW_ID
rather than ROW_ID.

|



 
|

 




 !


This slide introduces an example of the second special situation in which

we bring parent account data into the account business component (both
are party BCs). Note that there is M:1 relationship between an account
and its parent account.
The example illustrates bringing party data (from one account record)
into a party business component (into a second account record), even
though both records belong to the same business component.
Since there are many relationships between party business components
(for example Account and Contact), explicit joins are used to bring the
related data into the business component.

|



 
|

 




 !


|



 
|

 




 !


" 
#   What characterizes a party business component?

 It has S_PARTY as the base table but stores main data in one or
more of its extension tables.
The subject of performance may come up. Students might ask about the
performance impact of all the extra joins in the party business
components. The answer is yes, there can be some impact on
performance, but many of these business components already have
multiple joins to begin with. In addition, Siebel Engineering tries to make
sure that the joins they create do not have an unacceptable negative
impact. A great deal of work goes into ensuring good performance. Make
sure you point out the benefits of the party business components¶
capacity to create a much more flexible way of allowing access to data
(which will be discussed later in the course).

|



 
|

 




 !


See lab instructions for details.

|