EIM Load order for any new Siebel Application

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

1) Administrative data – LOV’s

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.

PARTY DATA MODEL

S_PARTY model is the major change seen in Siebel 7.X and later version.

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.

PARTY DATA MODEL:

PARTY TYPE AND PARTIES:

1)

PARTY => PERSON (CONTACT)

PARTY TYPE => PERSON

E.G:

• An employee at the customer company.• An employee at the competitor’s company

Features:

• A Person is an individual who is represented by a Person record in the database• Without additional attributes, a Person has no access to your database

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)

PARTY => USER

PARTY TYPE => PERSON

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

1) The S_USER table contains a login for this user

2) The S_PER_RESP intersection table specifies the responsibility for this user

3) It is possible to promote a contact to a user. For example, adding a User ID value for a person in the All Persons view in the Administration – User screen causes the person to appear as a user in the Users view.

3)

PARTY => EMPLOYEE

PARTY TYPE => PERSON

E.G:

• An Employee at your company – An Employee is a User who is associated with a position in a division within your company

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.

An Employee is a User with the following added qualities:

1. S_EMP_PER provides employee data for this user. 1. A position defined using the S_POSTN table is typically (but not

necessarily) associated with an employee.2. If the organization to which the position belongs is not a partner

organization, then the employee is an internal employee.3. If the organization is a partner organization, then the employee is a partner

user.

4)

PARTY => POSITION

PARTY TYPE => POSITION

E.G:

• A job title within (your) company• A job title within the partner company

Base table (S_PARTY) and extension table (S_POSTN)

Features:

• Position exist for the purpose of representing reporting relationships• A position within your company is associated with a division and is associated

with the organization to which that division belongs.• A position can be associated with one division only.• A position may have a parent position. It may also have child positions• One or more employees can be associated with an internal position, and one or

more partner users can be associated with an external position.• An employee or partner user can be associated with more than one position, but

only one position is active at any time.

5)

PARTY => ACCOUNT

PARTY TYPE => ORGANIZATION

Account is a company or group of individuals with whom you do business.

An account is typically made up of contacts It can have parent and child accounts.

An account can be promoted to partner organization, but it is not a division, an internal or external organization.

Base Table (S_PARTY) and extension table (S_ORG_EXT) defines Account data Model.

6)

PARTY => DIVISION

PARTY TYPE => ORGANIZATION

Division is an organizational unit within a company such as Manufacturing or Corporate unit.

It can also refer to a group of people operating within a particular company.

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

This flag specifies that division is an internal organization.

NOTE: For Account this flag is set to N

7)

PARTY => ORGANISATION

PARTY TYPE => ORGANISATION

E.G:

An Organizational unit within the company such as Asian organization and

A partner company

Features:

An organization is a division that is designated as an organization.

An organization exists for the purpose of providing a container in which positions can be associated with data.

An organization can be internal or it can be a partner organization.

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.

Partner Organization Data Model:

The base table and extension tables (S_ORG_EXT, S_BU, and S_ORG_PRTNR) define a Partner Organization.

A Partner Organization is the same as an Organization but the flag PRTNR_FLG in S_ORG_EXT qualifies it as a Partner Organization

PARTY => HOUSEHOLD

PARTY TYPE => HOUSEHOLD

Base table (S_PARTY) and household (S_ORG_GROUP) defines Household.

A group of people, typically a family, who reside at the same residence forms Household

A group of purchasers who live in different residences are also included.

Typically, a household is a group of individual consumers who are economically affiliated and share a common purchasing or service interest.

A household may have any combination of contacts, users, employees, and partner users as members.

An individual can belong to more than one household.

9)

PARTY => USER LIST

PARTY TYPE => USER LIST

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

A user list cannot have a parent or children.

10)

PARTY => ACCESS GROUP

PARTY TYPE => ACCESS GROUP

Base table (S_PARTY) and extension table (S_PARTY_GROUP) defines access group

E.G:

Partner IT service providers and business-to-business customer companies that buy networking equipment.

An access group is a group of any combination of parties of type Position, Organization, and User List. That is, it is a group of groups

An access group may have a parent access group. It may also have child access groups.

Parties relation to each other:

Divisions, organizations, and accounts are instances of the Organization party type.

• 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.

• Every division is associated with one organization: either itself or the closest ancestor division that is also an organization.

• Every position is associated with a division. The position is then also automatically associated with one organization: the organization with which the division is associated.

• Persons (contacts), users, employees, partner users are instances of the Person party type.

• Typically, you associate each employee and partner user with one or more positions. The employee or partner user has only one active position at one time. The employee or partner user is automatically associated with one division and one organization at a time—the division and organization associated with the active position.

• For purposes of granting visibility to data, associations of parties of type Person with other types of parties are stored using the S_PARTY_PER table. For example, accounts are associated with contacts, users are associated with

positions, and so on. A user associated with a position can see data for accounts or opportunities assigned to the position (when this is the active position). Relationships stored in S_PARTY_REL also affect data routing for mobile users.

• For purposes of storing ad hoc, informational relationships between parties, such associations are stored using the S_PARTY_REL table. For example, a company and its accounting firm may both be stored as accounts. Assuming that your application provides the capability to define this relationship, it can be stored in the S_PARTY_REL table.

• Ad hoc and informational relationships between parties are stored in the table S_PARTY_REL. For example, a company and its accounting firm may both be stored as accounts. The relationship between these two accounts can be stored in the S_PARTY_REL table, assuming that your application has been configured to define these relationships.

Error – Loading attachments using Siebel EIM

We were loading the attachments for the data migration phase for a requirement faced some issues and would like to share my thoughts.While we were loading the attachments through EIM we got a error that stopped the entire load processing.Error SBL-EIM-00900: Unknown failure running process

Possible reasons for the error:

1. Attachment sub folder might be missing in Siebel file system folder(s).

2. Not proper permission/grants to the source folder and attachment files/folder(s).

3. Not proper permission/grants to the Siebel file system where the attachments are stored.

Possible work around :

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.

Updating User Key Through EIM

In recent time I have come across many queries regarding updating the user key columns in the Siebel through EIM. Lets understand what is the importance of user key in siebel eim and discuss how to update User Key using EIM.

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_UKEIM_PARTY_UKEIM_PROD_EXT_UKEIM_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.

Data Migration Process Steps

I am trying to put down some of the steps that we need to follow in any data migration projects. I have consolidated these steps after working on few migration projects and going through the some articles and documents that we used during our migration project cycle.As per the various researchers data 65% to 70 % migration projects are failures .

These failures mainly occur due some very small information gap which later becomes the major issue.So lets us try to discuss the step oriented approach to avoid these failures and make a successful data migration delivery.

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 QualityThe 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 DesignIn 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 StrategiesThe 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) ExecutionAfter 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) ProductionAs 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.