Scenario 1:-

How are CREATED and CREATED_BY columns populated using EIM?

In standard Siebel applications, 'CREATED' and 'CREATED_BY' are system columns that will be
automatically populated when importing data via Enterprise Integration Manager (EIM). The
starting time of the EIM server task and login information of the employee starting the EIM server
task populates these columns. There is no EIM mapping from the Siebel Interface tables to the
CREATED and CREATED_BY columns in any of the base tables.

The following interface tables are an exception. They have a mapping into the 'Created By'
column: EIM_LITERATURE, S_ACTIVITY_IF, S_APPT_IF, S_CONTACT1_IF,
S_CONTACT2_IF, S_CONTACT_IF, S_FSCT_ACCNT_IF, S_FSCT_OPTY_PRD_IF,
S_FSCT_OPTY_IF, S_FSCT_POSTN_IF, S_FSCT_PROD_IF, S_FUL_IF, S_FUL_ITEM_IF,
S_LITERATURE_IF (and EIM_APP_QUERY for version 7). Please note that The S_ type
interface tables are provided for backward compatibility with releases prior to 6.x, as they do not
provide support for multiple organizations they should be used only in an environment with a
single organization, or under exceptional circumstances.

As a consequence, it is not possible to populate or update 'CREATED' and 'CREATED_BY' via

EIM (except if the mapping already exists), And as they are systems fields it is also impossible to
update them via the GUI or Siebel VB.

If you need to populate, or update these system fields with a different value than the default one,
and you cannot use the EIM tables above, the only solution is to create an extension column to
store these values.

Siebel applications support extensions made to the database and modifications made to the user
interface. Given below is a one way to accomplish this:

1. Add two extension columns to a base table and give them unique names (that
is, "X_CREATED_DATE", "X_CREATOR").
2. Add two extension columns to the corresponding interface table.
3. Map extension columns in the interface table to the extension columns in the
base table.
4. Configure the applications so that two new extension columns will be
displayed in user interface.
5. Populate data via EIM, User Interface or VB/OLE.

You might want to store a foreign key in the extension column, and as documented in the Siebel
Tools Guide, if you choose to implement this, you must consult with Siebel Expert Services
concerning the visibility rules applied to the foreign key table, and in order to add an EIM foreign
key mapping

Scenario 2:-

Recovery After an Aborted Run of IFMGR

Enterprise Interface Manager (EIM) performs many SQL statements on an interface table while
preparing rows for being inserted or updated into the base tables during import. Once the
interface table has been prepared (all rows have been validated and any foreign key values have
been looked up), it proceeds to update existing rows with data from the interface table (step 8)
and insert new rows (step 9).

Lastly, it resolves "primary child keys" within base tables imported from all interface tables of the
batch. Note that steps 1 through 9 processing occur completely for each interface table in the
order specified in the batch file, but step 10 occurs for all interface tables after the normal import
processing has occurred for all interface tables.

Summary

In order to maximize performance of importing, EIM uses set-based processing for all preparation
steps (1 through 7) and for inserting new rows (step 9). However, if transaction logging is turned
on, EIM will usually use row-by-row processing for the actual updates to maximize the granularity
of the transaction log. Like updating, primary key processing (which is always updating) will use
row-by-row processing when transaction logging is turned on. Regardless of whether set-based
or row-by-row processing is done, EIM will operate on all rows for each target base table (one at
a time).

Because all processing occurs in a table-by-table manner, an unrecoverable failure while running
EIM (such as SQL server shutdown, aborting the EIM process, etc.) may leave some of the tables
inserted or updated but others not. For example, when importing from S_ACCOUNT_IF (or
EIM_ACCOUNT in Siebel version 6.x), populating only S_ORG_EXT (Account headers) and
S_ADDR_ORG (Address children of S_ORG_EXT), it is possible for new Accounts to have been
inserted into S_ORG_EXT, but not the corresponding addresses in the event of an unrecoverable
failure after the S_ORG_EXT inserts but before the S_ADDR_ORG inserts.

Another possibility is that the regular importing will succeed for some or all tables, but an
unrecoverable failure will halt processing before primary key updating (step 10) is complete. This
will result in primary child keys not being correctly set (usually left as NULL if not satisfied during
regular imports). Please note the primary key updating referred to be that of the implicit primary
key processing carried out by Siebel in versions prior to Siebel 2000. In Siebel 2000, there is
additional support for EXPLICIT primary key updating and the information given below can be
applied equally to both types of primary key updates other than where the information refers
specifically to IMPLICIT primaries.

Controlling the SQL Transaction Granularity

The most obvious way to fix this is to use the database-supplied transaction control operations to
provide an "all or nothing" model for interface manager. For example, a maximally cautious
setting of:
COMMIT EACH TABLE = FALSE
COMMIT EACH PASS = FALSE
ROLLBACK ON ERROR = TRUE
in the configuration (.ifb) file will cause EIM to only commit after the entire batch (for all interface
tables and for primary processing) has been completed and to roll back the transaction on error.
(More likely, the database will roll back the transaction itself.) This solution is ideal if the database
configuration can support it. Because of the large amount of space required by updates, typically
the database will run out of transaction log (sometimes called rollback) space, causing the EIM
run to hang or fail. It is possible to configure your database with a very large amount of
transaction log space in which case this option is feasible.
Another problem is that EIM will obtain many locks during the course of processing the
(potentially long running) transaction, which will reduce concurrency of the database. This is not
an issue during initial load, but can be a significant issue for continuous updates in a running
installation.
If possible, this option is strongly recommended because it provides the best reliability and error
recovery.

Re-running EIM After A Failure

A simpler and less configuration intensive option is to re-run the batch during which the failure
occurred. This will result in the import being completed (possibly with some warnings about "all
rows being duplicates" for tables which had been successfully imported before the failure).
However some primary key processing may not have been done in this case because it is only
scheduled for newly imported rows. For example, in the S_ACCOUNT_IF example given above,
primary key processing was scheduled to be done for the successfully imported rows in
S_ORG_EXT after the initial import. However, EIM did not complete and the processing was not
done. On the second run of EIM, the rows already exist, so the implicit primary key processing is
not rescheduled since normally primary key processing does not need to be done for existing
rows.
It is possible to re-run implicit primary key processing in absence of actual import using a special
batch identified by setting the
PRIMARY KEYS ONLY = TRUE
property. This is normally not recommended as this processing can be slow since it must check
all rows in the base tables (not just the ones newly imported). However, it will re-validate all
primary keys for the base tables, which correspond to the interface tables specified in the batch.
Note that no batch number is required because no data will be imported. Primary key update
processing only operates on base tables. The interface tables specified in the batch are only used
to determine which base tables should be operated on.

The Siebel Client and Primary Keys

The Siebel client application (siebel.exe) will also patch up primary keys, which are invalid as the
records are visited. This is the reason that primary keys not set properly by EIM are usually not
noticed by users. As the users visit the records, the client will reset the primary keys
appropriately. This is not ideal, however, since it requires extra queries and updates when the
records are visited the first time. The common primary keys are handled quickly and seamlessly
by the Siebel Client. For example, the account address primaries are patched up automatically
with no user visible effect (other than a slight slowdown the first time the record is seen).
In some cases the client may display inconsistent behavior before the primary keys are patched
up (either by EIM or the Client) on some more complex views such as Territory Administration. In
general, it is better to fix the primary keys using EIM than to leave them for the Client to fix up.

Scenario:- 3

Running Multiple SESSION SQL statements for Enterprise Integration Manager Processes

Background

Enterprise Integration Manager (EIM) is a powerful and flexible tool provided by Siebel eBusiness
Applications to enable a two-way information exchange with other enterprise applications. EIM
allows administrators to define processes that import, export, delete and merge data. To allow for
custom processing at the start of one of these processes, EIM allows users to specify a single
user-defined SQL statement for each EIM process.
This SQL statement is sent directly and un-interpreted to the database server before any other
SQL statements for the process. Users can use this SESSION SQL statement to validate
interface table data against existing base table data, or even perform updates to Interface table
data. However, since only one SQL statement is allowed per process, users who want to execute
multiple SQL statements are faced with a dilemma. This technical note explains how to cause
multiple SQL statements to be executed at the start of an EIM process

Summary

At the beginning of an EIM session, EIM reads the configuration files (.ifb files), the contents of
which specify the kind of process to perform, as well as the parameters of the process. In these
configuration files, users define processes to import, export, delete or merge data. Within each
EIM process definition, users can define a single SQL statement to be executed at the beginning
of the EIM session. This statement is called the SESSION SQL and is executed before the rest of
the SQL statements. For example, to import only the opportunities that were generated by a
specific campaign (for example, Upgrade Campaign), use the following SESSION SQL to delete
all the other opportunities from the EIM table:

SESSION SQL = "delete from EIM_OPTYwhere src_name <> 'Upgrade Campaign'

and if_row_batch_num = 1
and if_row_stat = 'FOR IMPORT'"
To assign a specific sales cycle code (example: High Revenue Qualification) to those
opportunities with revenue exceeding $100,000, execute another SQL statement. Since EIM
allows only one SESSION SQL statement per process, use the following procedure to accomplish
the task.

Solution

The method used is to break up the original EIM process into 2 separate processes, each with a
SESSION SQL. Assume that the following configuration file is used:

[Siebel Interface Manager]

LOGIN USER = "SADMIN"
LOGIN PASSWORD = "SADMIN"
RUN PROCESS = Import New Opportunities

[Import New Opportunities]

SESSION SQL = "delete from EIM_OPTYwhere src_name <> 'Upgrade Campaign'
and if_row_batch_num = 1
and if_row_stat = 'FOR IMPORT'"
TYPE = IMPORT
BATCH NUMBER = 1
TABLE = EIM_OPTYROLLBACK ON ERROR = TRUE

To add another SESSION SQL, create a dummy process that contains the other SESSION SQL.
Users can either set the BATCH NUMBER for this dummy process to an unused batch number,
or use an unused EIM table. Create a shell process to call both processes. The new configuration
file should look like this:

[Siebel Interface Manager]

LOGIN USER = "SADMIN"
LOGIN PASSWORD = "SADMIN"
RUN PROCESS = Import New Opportunities
[SESSION SQL Step]
SESSION SQL = "delete from EIM_OPTY where src_name <> 'Upgrade Campaign' and
if_row_batch_num = 1 and if_row_stat = 'FOR IMPORT'"
TYPE = IMPORT
BATCH NUMBER = 9999
TABLE = EIM_OPTY
[Opportunity Import Step]
SESSION SQL = "update EIM_OPTY set stg_name = 'High Revenue Qualification' where
prod_revn > 100000 and if_row_batch_num = 1 and if_row_stat = 'FOR IMPORT'"
TYPE = IMPORT
BATCH NUMBER = 1
TABLE = EIM_OPTYROLLBACK ON ERROR = TRUE

[Import New Opportunities]

TYPE = SHELL
INCLUDE = SESSION SQL Step
INCLUDE = Opportunity Import Step

When EIM runs, the first process will be called and the delete statement will be executed first.
EIM will then generate a failure in the failure log:

IFMGR: Interface Manager v2.1.2 [217] .15 failure log (pid 172).

------------------------------------------------------------------------

Process [SESSION SQL Step] had all rows fail

on EIM_OPTY for batch -9999 in step 1, pass 100:

No rows exist in IF table for this batch. (severity 2, table aborted)

No rows exist in this interface table, which correspond to this batch number.
This means that no rows exist to be imported from this interface table.

Since there was a problem with the configuration of this interface table,
processing was discontinued. However, processing of other interface tables will continue.

EIM processing will continue with the second process. The SESSION SQL defined in
[Opportunity Import Step] will be executed and the resulting opportunity rows will be imported into
the Siebel base tables. With this technique, users can execute as many SESSION SQL
statements as necessary to complete their custom processing.

Scenario:4

Deleting Data Through Interface Manager

Background

Siebel eBusiness Application provides three mechanisms for deleting records through Enterprise
Integration Manager (EIM). This technical note briefly covers these scenarios and then gives
details of how to delete records that cannot be removed by directly utilizing these mechanisms.
This document assumes a working knowledge of EIM and SQL statements.

The example SQL statements provided in this technical note would change depending on which
release is installed. Check the Interface Tables Reference Guide to determine which fields
comprise the user key and the names of the required fields. Although Siebel 2000 and Siebel 7
continue to support the S_*_IF tables, the suggested interface tables are called EIM_*, example:
EIM_CONTACT. In Siebel 7.5 all the _IF tables have been deactivated. Customer must use EIM_
table for all interface jobs.

Siebel version 7 information:

The new S_PARTY table introduced in Siebel version 7 has many implications on performing
DELETE with EIM.
For further information, please refer to the ALERT 0359: EIM EXPORT / DELETE functionality for
S_PARTY based tables in Siebel version 70.

Summary

Through the EIM server module, Siebel eBusiness Application provides a powerful mechanism
for two-way information exchange with other enterprise applications such as manufacturing, order
entry, accounting, and customer service applications. The EIM provides full transaction control,
including support for bulk import, export, delete, and merge operations through Siebel Interface
tables. Of the available operations, deleting allows for the purging of data from the Siebel
eBusiness Application tables. Three mechanisms are available for specifying which rows should
be deleted:

1. Deleting all rows for a named table

2. Deleting data rows identified by user key values in the corresponding interface
table
3. Deleting data rows identified by a WHERE-clause expression in the
configuration file

In method 3 mentioned above, the WHERE clause specifies one or more columns in the base
table. For example, if all accounts that had not been modified since January 1, 1993 had to be
deleted, then the following line would be used in the EIM configuration file to delete those
accounts:

delete matches = EIM_ACCOUNT, (last_upd < '1993-01-01')

If method 3 is to be used, the columns must be available in the base table. There are two specific
situations where the columns that are not in the base table for the delete processing may need to
be specified. These are:

1. A column from a joined table representing a one-to-many relationship

(normally represented in the Siebel eSales User Interface (UI) as a picklist)
2. A column from a joined table represented by a many-to-many relationship
(normally represented in the Siebel eSales UI as a multi-value group)

An example of each scenario would be:

1. The SIC codes for an account

2. The source or campaign associated with a specific contact (this is not exposed
 in the default configuration, but is given here as it is a good basis for an example
that follows)

These two scenarios cannot be solved by using method 3 indicated above, because users must
look to the non-base tables to qualify the match (column NAME in S_INDUST for example 1 and
column NAME in table S_SRC for example 2.). However, if the user keys of the records to be
deleted could somehow be placed into the appropriate interface table then method 2 could be
used to delete these records (remember that this method uses the records in the interface table
to drive which base table records should be deleted).
This technical note describes a method that allows for the deleting of rows that fall into either of
the two categories. All example SQL statements have been written to run against an Oracle
database.
Approach 1
The steps to achieve the required results are as follows:

1. Make sure that the appropriate interface table is empty.

2. Export user key columns for all records in the base table into the interface
table.
3. Delete those records that do not match the criteria for deletion from the
interface table.
4. Perform the delete processing.

Step Details
The following example explains how to delete all those accounts with a particular SIC code.

1. Make sure that the interface table is empty

Although the interface table need not actually be empty, this step is included to
highlight the behavior that any records left in the interface table before the delete
step WILL be deleted from the corresponding base table unless the batch
numbers are modified accordingly to exclude them.

2. Export user key columns for the base table into the interface table.

In this example, all of the user key columns for S_ORG_EXT are exported into
EIM_ACCOUNT (if there is some way of reducing this list, given the columns that
users can qualify against, then do so, otherwise export all rows). Export only the
user key columns so that the size of the interface table is minimized. The
configuration file for this process would look like:
[Siebel Interface Manager]
USER NAME = "SADMIN"
PASSWORD = "SADMIN"
PROCESS = Export All Accounts

; This process demonstrates exporting data into the Siebel

; account interface table. The if_row_batch_num
; is 1 for the rows to be exported.

[Export All Accounts]

TYPE = EXPORT
BATCH = 1
TABLE = EIM_ACCOUNT
ONLY BASE COLUMNS = S_ORG_EXT.NAME, S_ORG_EXT.LOC,
S_ORG_EXT.BU_ID
EXPORT ALL ROWS = TRUE

3. Delete from the interface table those accounts that do not match the
criteria for deletion

This step will clear from the interface table those rows that SHOULD NOT be
deleted from the base table. In the example, accounts that do not have a specific
SIC code are being removed form the interface table. If the SIC code is, for
example, 10, then the following SQL statement would be used against
EIM_CONTACT to remove these rows or accounts:

DELETE FROM EIM_ACCOUNT // Delete accounts with no match

WHERE ACCNT_NAME NOT IN
(SELECT NAME // Get name, loc for accounts
FROM S_ORG_EXT
WHERE (ROW_ID IN
(SELECT OU_ID
FROM S_ORG_INDUST
WHERE INDUST_ID IN
(SELECT ROW_ID
FROM S_INDUST
WHERE SIC = '10'))))

Note that in this example all accounts that have the specified SIC code are
deleted, even if they also have other SIC codes. To keep those accounts that
also had other SIC codes, the following SQL would be required:

DELETE FROM EIM_ACCOUNT // Delete accounts with no match

WHERE ACCNT_NAME NOT IN
(SELECT NAME // Get name, loc for accounts
FROM S_ORG_EXT
WHERE (ROW_ID IN
(SELECT OU_ID
FROM S_ORG_INDUST
WHERE INDUST_ID IN
(SELECT ROW_ID
FROM S_INDUST
WHERE SIC = '10')))
AND ROW_ID NOT IN
(SELECT OU_ID
FROM S_ORG_INDUST
WHERE INDUST_ID IN
(SELECT ROW_ID
FROM S_INDUST
WHERE SIC <> '10')))

Variations on the DELETE statement, which will remove from the interface table
all those rows that are not to be deleted from the base table during delete
processing, should, in general, be possible.

4. Perform the delete processing

 Now that the interface table contains the user key for those rows to be deleted,
EIM can be used with the delete operation. In the example, the following
configuration file contents would perform a delete of the required rows. This can
be further extended to perform the delete in multiple phases or batches etc.
Before running EIM, be sure to set the appropriate values for IF_ROW_STAT
('FOR_IMPORT') and IF_ROW_BATCH_NUM (100 in this example):

[Siebel Interface Manager]

USER NAME = "SADMIN"
PASSWORD = "SADMIN"
PROCESS = Delete Accounts With SIC

; This process demonstrates deleting data from the Siebel

; account table. The if_row_batch_num is 100 for the rows
; to be deleted.
[Delete Accounts With SIC]

TYPE = DELETE
BATCH NUMBER = 100
TABLE = EIM_ACCOUNT
DELETE ROWS = TRUE
DELETE EXACT = TRUE

Approach 2
The second approach is to merge steps 1 and 2 from Approach 1. That is, the interface table is
directly populated with the required row set to be deleted. In the example, the following SQL
would populate the interface table EIM_ACCOUNT with those account user key that would need
to be deleted (in this example, delete all accounts with SIC code '10' and which have no other
SIC code):

INSERT INTO EIM_ACCOUNT

(PARTY_UID, PARTY_TYPE_CD, IF_ROW_STAT,
IF_ROW_BATCH_NUM,S_PARTY.ROW_ID)
SELECT S_PARTY.PARTY_UID, S_PARTY.PARTY_TYPE_CD,
'FOR_IMPORT', 100, S_PARTY.ROW_ID
FROM S_PARTY, S_ORG_EXT
WHERE S_PARTY.ROW_ID = S_ORG_EXT.PAR_ROW_ID AND
(S_ORG_EXT.NAME) IN
(SELECT NAME
FROM S_ORG_EXT
WHERE (ROW_ID IN
(SELECT OU_ID
FROM S_ORG_INDUST
WHERE INDUST_ID IN
(SELECT ROW_ID
FROM S_INDUST
WHERE SIC = '10')))
AND ROW_ID NOT IN
(SELECT OU_ID
FROM S_ORG_INDUST
WHERE INDUST_ID IN
(SELECT ROW_ID
FROM S_INDUST
WHERE SIC <> '10')))
The benefit of this approach is that it should, in general, require less system resources (example:
database structures such as rollback segments and system resources such as CPU and disk I/O)
to achieve the same result.
Whenever deleting records using EIM, always take extra care because once the records are
deleted they are removed from the Siebel database. Consider all steps that should be taken prior
to the delete to allow for quick recovery should the delete be incorrect (example: backup, export
etc.).
Another Example
As another example, if a user wanted to delete all contacts associated with a specific source (PC
Expo 1996) for which no corresponding opportunity exists. That is, the contacts were originally
loaded and associations made to the source. Upon completion of the campaign, all contacts for
the campaign where no opportunity was generated are to be deleted. In this example, a contact
can only be linked to one source. Use the second approach to populate the interface table
(EIM_CONTACT) before running the delete process in Interface Manager.
The SQL statements required to populate the interface table S_CONTACT_IF would be as
follows:
INSERT INTO EIM_CONTACT
(PARTY_UID, PARTY_TYPE_CD, IF_ROW_STAT, IF_ROW_BATCH_NUM,ROW_ID)
SELECT PERSON_UID, 'Person', 'FOR_IMPORT', 100, CON.ROW_ID
FROM S_CONTACT CON, S_SRC SRC, S_ORG_EXT ORG
WHERE CON.SRC_ID = SRC.ROW_ID
AND ORG.ROW_ID = CON.PR_DEPT_OU_ID
AND SRC.NAME = 'PC Expo 1996'
AND CON.ROW_ID NOT IN
(SELECT PER_ID
FROM S_OPTY_CON CON, S_SRC SRC
WHERE CON.SRC_ID = SRC.ROW_ID
AND SRC.NAME = 'PC Expo 1996')
Notes:

• The interface table column ROW_ID has been set to the contact ROW_ID to make sure
uniqueness (the field is a required field).
• The account name and location are also extracted so that the correct contact is deleted
(the contact last name and first name is unique to an account location so be sure that the
correct contact for the correct account or location is deleted).

The EIM configuration file is as follows:

[Siebel Interface Manager]
USER NAME = "SADMIN"
PASSWORD = "SADMIN"
PROCESS = Delete Contacts For Source
; This process demonstrates deleting data from the Siebel
; contact table. The if_row_batch_num is 100 for the rows
; to be deleted.
[Delete Contacts For Source]
TYPE = DELETE
BATCH = 100
TABLE = EIM_CONTACT
DELETE ROWS = TRUE
DELETE EXACT = TRUE
Comments
Generally, Siebel applications provide the columns required to qualify records for delete (or for
that matter export) in the appropriate interface table. This alleviates the need to know both SQL
statements and the Siebel eSales data model. However, the above technique shows how,
through the use of SQL statements and a working knowledge of the Siebel eSales data model,
users can define record sets that would not otherwise be possible. In general, always use the
standard mechanisms within EIM for deleting records wherever possible. If the above technique
is to be used, then make sure that an individual experienced in writing SQL statements that also
has a working knowledge of the Siebel Sales Enterprise data model is involved (such as the local
DBA, Siebel Technical Account Manager or Systems Integrator). If the SQL statements that
defines the record set to be deleted is written incorrectly, and EIM is run to process the set, the
records will be deleted and it will be very difficult to reverse the operation.
Also, the above SQL statements will work well for small data sets, but care should be taken in
writing such SQL statements for large data sets where database and other system resources
should be carefully considered.

Scenario: 5

The ROW-Ids generated using EIM look like "1+9W+6961". Is the plus sign ("+") delimiter
correct behavior?

Yes, the plus sign ("+") delimiter is added for the row id if the record originates from an EIM
import. This is the normal behavior before Siebel 6.2.1.21 (build 10257).
The format of the Row Id is one of the following:

1. CP-NS For records created by the Siebel eBusiness Applications, MidMarket

Edition user interface.
2. CP+NP+NS For records created by Data Integration Manager (EIM). This is true for
any release before Siebel 6.2.1.21 (build 10257).
3. From Siebel release 6.2.1.21 (build 10257) and beyond the format is changed to "XX-
XXX-XXX". Also true for siebel7.0 releases

Scenario:6

How can Accounts be viewed after importing them through the Data Integration
Manager (EIM)?

In order to see imported accounts using the views in the Account screen, a primary position must
be assigned to each account. This can be accomplished in a number of ways:

1. Through the user interface:

After importing accounts through the Data Integration Manager (EIM), log on to
the application using the administrator username and password and navigate to
Screens > Marketing Administration > Accounts in Siebel eBusiness
Applications, MidMarket Edition version 6.x or Siebel Workgroup Applications
version 5.x. In Siebel eBusiness Applications, MidMarket Edition version 7.x,
navigate to Site Map > Data Administration > Accounts

This will display either the 'Account Administration View' for Siebel eBusiness
Applications, MidMarket Edition version 6.x and version 7.x or the 'Account
 Administration View (SWG)' for Siebel Workgroup Applications version 5.x. All
accounts will be displayed regardless of whether or not a position is assigned to
an account.

Select the account and in the 'Account Team' multi value field (MVF), add the
required position. Employees holding this position can view this account in the
Account Screen.

2. Using Assignment Manager:

Positions can be assigned to accounts using Assignment Manager. Assignment
Manger must be run in batch mode, specifying the Account assignment object. A
territory rule must be defined for the Account assignment object, identifying which
positions are to be assigned to the accounts.

3. Using EIM:
Import positions into S_ACCNT_POSTN via S_ACCOUNT_IF (in Siebel
Workgroup Applications version 5.x) or EIM_ACCOUNT (in Siebel eBusiness
Applications MidMarket Edition version 6.x and version 7.x).
In Siebel eBusiness Applications MidMarket Edition version 6.x and version 7.x,
an explicit primary position can be set using the primary column. For example, in
EIM_ACCOUNT table, the ACC_PR_POSTN column when set to "Y", will be
used to set the primary position in the account in S_ORG_EXT.PR_POSTN_ID.

Scenario: 7

Can the PRIV_FLG column of S_CONTACT base table be updated using EIM?

No. The S_CONTACT.PRIV_FLG is not part of the user key to the S_CONTACT table. However,
it is included in the criteria used by Enterprise Integration Manager (EIM) to locate an existing row
in the S_CONTACT table. Currently it is not possible to update the S_CONTACT.PRIV_FLG
using EIM. For contacts loaded using EIM, the only supported value for the PRIV_FLG is "N".
This specification can be enforced by adding FIXED COLUMN=CON_PRIV_FLG, 'N' in the ifb
file.

Scenario: 8

How can I tune my EIM batches to improve performance?

This FAQ is also applicable to Siebel Enterprise Application, MidMarket Edition.

Here are some options that can be tried to improve Enterprise Integration Manager (EIM)
performance:

Check to make sure all the standard indices are in existence for the tables involved.

Limit tables and columns to be processed using ONLY BASE TABLES/COLUMNS configuration
parameters to minimize the work that EIM has to perform.
Consider switching off Siebel transaction logging during the EIM run. This will definitely improve
performance; however, it must be balanced with the need for mobile users to re-extract
afterwards.

Try different batch sizes. Often, large batch sizes are not the most efficient. Siebel Systems
recommends that customers use a batch size no more than 5000 rows, preferably less than 2000
rows in a single batch.

Try using batch ranges (BATCH = x-y). This allows users to run with smaller batch sizes and yet
avoid the startup overhead on each batch.

Perform regular table maintenance on interface tables. Frequent insert or delete operations on
interface tables can cause fragmentation in the table. The database administrator will know how
to detect and correct fragmentation in the EIM interface tables.

Delete batches from interface tables on completion. Leaving old batches in the EIM interface
table will waste space and could adversely affect performance.

Run independent EIM jobs in parallel. EIM jobs that have no interface or base tables in common
can be run in parallel.

Set the USING SYNONYMS parameter to false in the .IFB file to indicate to EIM that account
synonyms do not need to be checked.

Avoid using the UPDATE PRIMARY KEYS parameter in the IFB file.

ORACLE INSERT APPEND MODE. The default value is FALSE, which means EIM does not use
use append mode for insert at EIM process step 9, avoiding a deadlock when running parallel
EIM processes. If you need to improve step 9 performance, you can set the value to TRUE. *

Delete and Merge performance is improved if you create some specific temporary indices first.
Please refer to Siebel Enterprise Integration Manager Administration Guide, Version 7.5, Creating
Temporary Indexes for more details *

If using Oracle database, ensure that Oracle rule-based optimizer is used. Siebel Systems has
highly recommended the Oracle rule-based optimizer because it provides the consistent behavior
needed for effective performance tuning.

If all else fails, set "Trace Flags"=1 and "SQL Trace Flags"=8 and rerun the batch. The resulting
task log will identify slow running steps and queries.

Note:

For Siebel eBusiness Application Version 7, this is documented in the Bookshelf: Siebel
Enterprise Integration Manager Administration Guide > Frequently Asked Questions >
Performance Questions.

For Siebel eBusiness Application Version 6, this is documented in the Bookshelf: Siebel
Enterprise Integration Manager Administration Guide > Advanced Usage > Questions and
Answers > Q. How can I tune my EIM batches to improve performance?
Scenario: 9

What’s New in Enterprise Integration Manager (EIM) Siebel 7?

Background

Enterprise Integration Manager (EIM) is one of the server components in EAI Component Group.
This document provides an overview of the new enhancements and new changes in Siebel 7 EIM
area.

Summary

1. S_PARTY Table

S_PARTY table has been introduced into Siebel Data Model in version 7. Note that S_PARTY
table is the target base table, whiles S_ORG_EXT, S_CONTACT, S_USER, S_POSTN now
become the extension tables of S_PARTY table. S_EMPLOYEE table becomes obsolete in
version 7. These schema changes have direct impacts on EIM behavior.

2. MISC SQL Parameter

MISC SQL parameter is introduced in Siebel 7 to allow EIM to set certain Primary Child Foreign
Keys, such as S_CONTACT.PR_OU_ADDR_ID, S_POSTN.PR_EMP_ID. Note that when using
MISC SQL in Siebel 7 to set Primary Child Foreign Keys, EIM does NOT log any transactions for
mobile users. Users should only use this parameter in their initial data loading.

3. utleimdiff.exe Utility

Siebel Data Model changes from release to release. Any data schema change will have impact
on EIM behavior. utleimdiff.exe utility can be used to find differences in all interface tables
between two repositories. It also allows users to generate a selective report of only the EIM tables
a customer is using. The results can be used to help existing users prepare their interface tables
for EIM data loading.

4. EIM Table Mapping Wizard

EIM Table Mapping Wizard is introduced in Siebel 7 to assist adding custom extensions to the
Data Model:

• Add new customer columns to existing Siebel Table

• Add new extension table
• Add new intersection table

5. EIM_PROD_INT_UK
EIM_PROD_INT_UK in version 7 can be used to update user key columns in S_PROD_INT,
such as NAME and VENDR_OU_ID. INTEGRATION_ID is an alternative user key in
S_PROD_INT. EIM engine uses this new user key to update traditional user key columns.

6. LOG TRANSACTIONS TO FILE

LOG TRANSACTIONS TO FILE is introduced in version 7 to allow EIM to log transactions into
.dx files stored in the File_System\EIM directory. A marker transaction will be created in
S_DOCK_TXN_LOG table.
EIM EXPORT / DELETE functionality for S_PARTY based tables in Siebel version 7

Description

The introduction of the S_PARTY table in Siebel version 7 means that tables such as
S_ORG_EXT and S_CONTACT become extension tables to the S_PARTY table. Tables such as
S_ORG_EXT and S_CONTACT are no longer the target tables of Interface Tables such as
EIM_ACCOUNT and EIM_CONTACT.

Although the Enterprise Integration Manager (EIM) functionality has not changed in Siebel
version 7, the data model changes mentioned above may have a significant impact on the
expected results of EXPORT and DELETE processing carried out by EIM. This is because tables
such as S_ORG_EXT and S_CONTACT are no longer the target tables of the Account and
Contact Interface Tables. EXPORT and DELETE functionality operate from the target table
(S_PARTY) and then cascades down to the "children" tables (S_ORG_EXT, S_CONTACT etc).

This causes the following behavior to occur:

EXPORT ALL ROWS = TRUE will cause all records (regardless of "party type") from the
S_PARTY table to be exported to the specified Interface Table.

Change Request 12-8TF4SO has been logged to address this Product Defect.

EXPORT MATCHES
Following syntax should be used for all base tables where target base table is S_PARTY table:

(1) For example, for exporting data into EIM_ACCOUNT table, the following syntax may be used:

[Export Accounts]
TYPE = EXPORT
BATCH = 1
TABLE = EIM_ACCOUNT
EXPORT MATCHES = S_ORG_EXT, (NAME Like 'Siebel%')

Note that during export process, multiple records may be exported into EIM_ACCOUNT table
depending on the number of dependent objects for the Party object.

For DELETE MATCHES process, the following syntax may be used:

[Delete Accounts]
TYPE = EXPORT
BATCH = 1
TABLE = EIM_ACCOUNT
DELETE MATCHES = S_ORG_EXT, (CREATED > '2002-07-10')

Note that records will always be cascade deleted starting from matching S_PARTY record.

(2) If an EXPORT MATCHES criteria is to be specified against the S_PARTY table, then the table
name is required:

[Export Accounts]
TYPE = EXPORT
BATCH = 1
TABLE = EIM_ACCOUNT
EXPORT MATCHES = S_PARTY, (CREATED > '2002-07-10')

(3) For all other interface tables where base tables is not S_PARTY, syntax for EXPORT
MATCHES or DELETE MATCHES remains the same as in previous versions:
EXPORT MATCHES = (CREATED > '2002-05-01')
DELETE MATCHES = EIM_ACTIVITY, (CREATED > '2002-05-01')

Change Request 12-AYTER7 has been raised to address this documentation change.

DELETE EXACT should be used with caution if carried out in conjunction with the EXPORT
processing described above. This is because EXPORT will export all records from the S_PARTY
table to the specified Interface Table, if the specific party type is not provided. If this is followed by
an EIM DELETE task, it will result in the deletion of all the S_PARTY rows followed by a cascade
delete of all child rows. If using EXPORT and then DELETE EXACT, ensure that only those
records in S_PARTY that to be deleted, get exported. As described above, if the match criterion
for EXPORT is not specific enough, then unintended records might be exported and deleted. An
alternative to the "EXPORT then DELETE" approach is to use SQL to select records in S_PARTY
to be deleted into the interface table followed by DELETE EXACT.

WARNING: STRONG CAUTION IS RECOMMENDED IN USING THIS APPROACH.

INCORRECT USAGE COULD RESULT IN A DELETION OF YOUR ENTIRE DATABASE.

DELETE MATCHES should be used to remove data from the S_PARTY table - as documented in
the EIM Administration Guide; however caution should be applied based on the
recommendations made above

Likelihood of Occurrence

The behavior described above is standard EIM functionality that has not changed in Siebel
version 7. This Alert has been written to ensure that the impact of the Data Model changes
introduced in Siebel version 7 on the functionality described above is fully understood.
It is recommended that any EIM tasks that are currently used in Siebel 2000 should be thoroughly
tested in Siebel version 7 to ensure that all EIM processes behave as expected.

Primary Responsibility cannot be set for Employees using Enterprise Integration Manager
(EIM)

Description

After running the EIM import process to import employee and their responsibilities through
interface table EIM_EMPLOYEE into base table S_CONTACT and S_PER_RESP tables, the
primary responsibility cannot be set. The value is always set to "No Match Row Id" in
S_CONTACT.PR_RESP_ID even with EIM_EMPLOYEE.CON_PER_RESP = 'Y'.

Change Request 12-ABM2X3 has been logged to address this Product Defect.
Likelihood of occurrence

This behavior will be encountered if an EIM import process is performed, when importing records
into S_PER_RESP and S_CONTACT base tables using EIM_EMPOYEE interface table.

Possible symptoms

S_CONTACT.PR_RESP_ID is set to "No Match Row Id".

Workaround or Resolution

Set the Primary responsibility manually in the user Interface (UI).

or
Set the Primary responsibility through Siebel Visual Basic (SVB).

When using MISC SQL in Siebel 7 to set Primary Child Foreign Keys, Enterprise
Integration Manager (EIM) does NOT log any transactions for mobile users

Description

MISC SQL parameter is introduced in Siebel 7 to allow EIM to set the following Primary Child
Foreign Keys:
S_CONTACT.PR_OU_ADDR_ID
S_CONTACT.PR_HELD_POSTN_ID
S_ORG_EXT.PR_BL_PER_ID
S_ORG_EXT.PR_SHIP_PER_ID
S_POSTN.PR_POSTN_ADDR_ID
S_POSTN.PR_EMP_ID
Note that when using MISC SQL in Siebel 7 to set Primary Child Foreign Keys, EIM does NOT
log any transactions for mobile users. Change Request 12-BGA6EK has been raised requesting
providing this information in EIM documentation.
In Siebel 7.5 , this has been documented in the Siebel Bookshelf 7.5 > Enterprise Integration
Manager Administration Guide > Importing Data > Editing the Configuration File for Importing
Processing > Header and Process Parameters.
For more information about the usage of MISC SQL, please refer to Enterprise Integration
Manager Administration Guide (7.0), page 4-15.
Likelihood of Occurrence
No transactions will be logged for mobile users when using MISC SQL within an EIM process in
Siebel 7 to set the Primary Child Foreign Keys listed above.
Workaround or Resolution
Use MISC SQL only during initial EIM data loading. Afterwards, it is recommended to use Siebel
Visual Basic, COM Interface or User Interface to set or update Primary Child Foreign Keys listed
above.

BI columns should be _BU columns in EIM interface tables

Description
Before running the EIM process, _BU columns of interface tables should be populated instead of
_BI columns. These _BI columns will be populated by the EIM process based on the value in _BU
columns.

The Interface Tables Reference lists _BI columns instead of _BU columns. This reference gives
the impression that _BI columns need to be populated. Change Request 12-ABM2XH has been
logged to address this Documentation Defect.

Please note that the Interface Tables Reference of Siebel Version 6 and 7.5 lists _BU columns
correctly. This Alert is only applicable for Version 7.0.x.

Possible Symptoms

Not Applicable

Likelihood of Occurrence

Not Applicable

Workaround or Resolution

Not Applicable

Enterprise Integration Manager (EIM) does not prevent inserting S_PARTY records when
S_ORG_EXT records that violate the unique index S_ORG_EXT_U2 are rejected

Description

When running import through Enterprise Integration Manager (EIM) using EIM_ACCOUNT,
sometimes EIM tasks error out with ODBC error indicating that the unique S_ORG_EXT_U2 is
violated (actual error messages generated vary depend on different databases platforms).

Likelihood of Occurrence

This occurs when S_PARTY record specified in EIM_ACCOUNT is a new one based on
S_PARTY_U1 and the associated S_ORG_EXT record is a duplicate of existing one in terms of
S_ORG_EXT_U2 (NAME, LOC, BU_ID). Since S_ORG_EXT is considered a one-to-one
extension table of S_PARTY, EIM only checks if there is an existing S_ORG_EXT record that
references (by PAR_ROW_ID) the S_PARTY row. No record is returned since the S_PARTY
record is a new one.

As a result, the S_ORG_EXT_U2 index is violated when EIM tries to insert the record into
S_ORG_EXT.

Possible Symptoms

An incomplete EIM job with new S_PARTY rows inserted without associated S_ORG_EXT rows.

Workaround or Resolution
To avoid the situation, the interface table should be populated in a way that when there is a new
S_PARTY record, the corresponding S_ORG_EXT one must also be new in terms of
S_ORG_EXT_U2.

Questions:-

1) Under What are the circumstances one chose between EIM and EAI for data transfer..

Answer:-

• In maintaining database, when users have very thin updates( 1-10 columns) to a narrowly
defined set of siebel base tables (maximum 3).
• When business requirements dictates the real-time feeds be available from other
enterprise applications that their employees must utilize inorder to accomplish their jobs

2)