Professional Documents
Culture Documents
Many get confused with data loading for the new siebel application starting from scratch.
Below is the order in which we need to load data for new Siebel application. we should
start loading data in follwing sequence to avoid problems
2) Responsibilities
3) Views
4) Organization
5) Position
6) Employee
7) Address
8) Account
9) Contacts
10) And now other related entities depending on the dependency of the entity but here
also we load all the parent entities or reference entities for any child or referring entity.
The S_PARTY table is the base table for all the party related entities: Person
(Contact), User, Employee, Partner User, Account, Division, Organization, Partner
Organization, Household, Access Group and User list. Party components have M: M
relationships among them. For each party record stored in the S_PARTY table, the value
of the PARTY_TYPE_CD column denotes the party type. Along with the party type,
extension tables provide the primary differentiation between the different parties.
1)
E.G:
Features:
The base table (S_PARTY) and extension table (S_CONTACT) that define a contact or
person. A person is the simplest representation of an individual in the database
2)
E.G:
• A registered customer on (your) Web site
• A self-registered partner user, that is, one who has no position.
Features:
• A User is a Person who can log into your database and has a responsibility that
defines what application views are accessible.
• A self-registered partner on a Siebel partner application has a responsibility, but
does not have a position like a full Partner User has.
The base table (S_PARTY) and extension tables that define a user (S_CONTACT and
S_USER) form User Data Model. A User is a person with following added qualities
2) The S_PER_RESP intersection table specifies the responsibility for this user
3)
E.G:
Base table (S_PARTY) and the extension tables (S_CONTACT, S_USER, and
S_EMP_PER) define employee. This includes internal employees and Partner users.
4)
PARTY => POSITION
E.G:
Features:
5)
An account is typically made up of contacts It can have parent and child accounts.
Base Table (S_PARTY) and extension table (S_ORG_EXT) defines Account data
Model.
6)
Features:
A division exists for the purposes of mapping a company’s physical structure into the
Siebel Database and for providing a container for position hierarchies.
A division may have a parent division. It may also have child divisions.
Data cannot be associated directly with a division. (Divisions that are not designated as
organizations do not drive visibility.)
Base table (S_PARTY) and extension table (S_ORG_EXT) define division data model
along with INT_ORG_FLG=Y (in S_ORG_EXT) table
7)
E.G:
A partner company
Features:
An organization exists for the purpose of providing a container in which positions can be
associated with data.
A division can be associated with only one organization: itself or an ancestor division that
is also an organization.
Base Table (S_PARTY) and extension tables (S_ORG_EXT and S_BU) define
Organizational data model.
An Organization, sometimes known as a business unit, is also a Division, but has a record
in the S_BU table.
The base table and extension tables (S_ORG_EXT, S_BU, and S_ORG_PRTNR) define
a Partner Organization.
A group of people, typically a family, who reside at the same residence forms Household
A household may have any combination of contacts, users, employees, and partner users
as members.
9)
Base table (S_PARTY) and extension table (S_USERLIST) defines User list.
E.G:
A support team made up of some internal employees and some partner users.
Features:
A user list is an ad hoc group of people. It may have any combination of contacts, users,
employees, and partner users as members
10)
Base table (S_PARTY) and extension table (S_PARTY_GROUP) defines access group
E.G:
An access group may have a parent access group. It may also have child access groups.
Divisions, organizations, and accounts are instances of the Organization party type.
3. Not proper permission/grants to the Siebel file system where the attachments are
stored.
1. Siebel user used to run the EIM process should have R/W grants on the source folder
and read grants to all attachements.
2. Siebel user used to run the EIM process should have the R/W grants on the Siebel file
system folders and sub folders.
3. The attachment folder must exist in Siebel file system folders and eim user should have
the write permissions on the folder.
Location of the file can be easily checked from the EIM log file.
User Key — specifies one or more columns that must contain a unique set of values.
Prevents users from entering duplicate records based on the user key.
Siebel EIM identifies the unique record with the help of the user key. Thus Siebel does
provide some good practice to update the user key through EIM as the user key in the
heart of the Siebel EIM on which it work and updating the same user key is some
where we are contradicting with the very basics of the Siebel EIM architecture on
which it has been developed.
Siebel provide following EIM table to update the user keys through EIM:
EIM_ORG_EXT_UK
EIM_PARTY_UK
EIM_PROD_EXT_UK
EIM_PROD_INT_UK
To update the user key for the S_ORG_EXT table you need to use
EIM_ORG_EXT_UK.
The following columns will play the role :
1) The PARTY_TYPE_CD and PARTY_UID will contain the data for the existing user
key.
2) The column ORG_NAME and ORG_LOC will contain the data for the new user key
which you want to update.
I have practically worked on this requirement in past and it worked good for me.
The people have some doubts about the integration_id but this column is not used in this
process.
Other than these you cannot update the user key through EIM but can use many other
work around through scripting , business service, sql update queries etc.
In the similar fashion you can update user for S_PARTY , S_PROD , S_PROD_INT
using the tables EIM_PARTY_UK , EIM_PROD_EXT_UK, EIM_PROD_INT_UK
respectively.
1) Source System
The first step is to indentify and explore the source system.
The best approach is to identify the group of data, account information, customer
information and details, order and product details and other description based on the
target application model.
The source system may contain thousands of fields; some might be good data, duplicate
data or data that we may not require for the target application.
The source data may not contain all the data that we require for the target application we
have clearly understand that gap and analyze from where we can get the require set to
data, in some cases we may have to pull this set of data from the other third party source
system etc. Finally we have to consolidate the data from the multiple sources and create
the complete correct set of record to full fill the requirements for the target application.
The end of this phase you should be able to identify the source data that will populate the
target model. You will also indentify the various gaps in the data set and consolidate
these gaps using different source systems. Finally you will have to broken the data into
various categories/entities to make the things more manageable. You will also identify
the correct flow of data, that is, to load master data initially followed my parent entities
and then child entities. Thus can also identify the various categories/entities that can we
worked out in parallel.
2) Data Quality
The next very important step is to identify the quality of the source data. The new system
may fail due data inconsistency or data redundancy, duplicate data thus making data
migration unsuccessful.
Here is a important term called data profiling.
Data profiling is analyzing the contents of all the columns in the tables of interest. The
data profiling will help us to identify the defects at the table and column level. It will help
us in evaluating the correctness of data and ensuring the data quality as per the
requirements of the target application.
Data profiling evaluate the actual record level and meta data information for the record
set. Many projects start without analyzing the quality of the data of the source system.
By including the data profiling in very early stages of the project life cycle will help us to
reduce the risk in the project , will give confidence to the migration team and client , will
reduce project overruns, delays and to give timely successful delivery.
Thus at the end of this phase you will able to evaluate the quality of the data and if the
source data is fit for the business process in the target model. You will also have the good
understanding of the various data gaps and what correctness measures to be taken to
fulfill those data quality gaps. You will also have the good understanding of mapping of
the data from the source to target data model. Finally you will be able to develop the high
level data integration plan.
3) Migration Design
In this step you will define the detailed technical architecture and design of the data
migration process.
You should also provide some guidelines of the testing teams to be in sink with your data
migration process.
In this it is important build all the detailed documentation for the project and takes all the
required approvals to carry on the various activities successfully and timely.
4) Migration Strategies
The data migration strategies are the most important phase for the successful delivery for
the project. Here you will define the details mapping of the source system to the target
system.
The details of the various data messaging routines with proper set of data should be
documented correctly and routines should be developed with considering all those
business requirements in the data messaging routines.
The most important area that need to be covered is the testing , it is should explain how
the testing should go first at low level with testing all the data by breaking it up into small
categories/entities and then integrated testing of the various modules.
Output of this phase is fully tested process that can be delivered.
5) Execution
After running comprehensive testing the time comes to run the migration. In the majority
of case the source system will be shutdown when migration takes place. To minimize the
impact it is likely to occur on weekends or on public holidays. The synchronization for
the source and target data will be validated.
6) Transition
Once the data is migrated, at some point of time you need to decide when to move the
new system and where it is appropriate to retire old system. The synchronization of the
data will be validated and checked before the actual transition happens.
7) Production
As part of the design the system retirement policy will be created to address the old
system. You will also manage the ongoing improvements and monitor the data quality of
the new system.
Also try to identify the reusable components which can reused as well as possible
improvements that can applied in the next migration project.
The data migration projects need to be handled with patience and leaders should show the
confidence in the team because in any migration project you will get some very
challenging issues and have look for work arounds for the fixing the issues.