For an initial load, you can use 30,000 rows for a large batch. For ongoing loads, you can use 20,000 rows for a large batch. You should not exceed 100,000 rows in a large batch.
Furthermore, you should limit the number of records in the interface tables to those that are being processed. For example, if you have determined that the optimal batch size for your system is 19,000 rows per patch and you are going to be running

8 parallel EIM processes, then you should have 152,000 rows in the interface table. Under no circumstances should you have more than 250,000 rows in any single interface table, since this will have a tremendous negative performance impact.

NOTE: The number of rows you can load in a single batch may vary depending on your physical machine setup. To reduce demands on system resources and improve performance, you should always try to use smaller batch sizes.

You should try the following options to improve EIM performance:

Verify that all indices exist for the tables involved.

Limit tables and columns to be processed using ONLY BASE TABLES/COLUMNS configuration parameters to minimize EIM processing.

Consider switching off transaction logging during the EIM run. This will definitely improve performance. However, it must be balanced with the need for mobile users to reextract afterward.

Try using different batch sizes. Large batch sizes are often not efficient.

NOTE: Although the limit of rows you can process in a batch depends on your physical machine setup, you should not use a batch size of more than 100,000 rows.

For import processes, and delete processes that use the DELETE EXACT parameter, it is recommended that you use around 20,000 rows in a single batch.

Try using batch ranges (BATCH = x–y). This allows you to run with smaller batch sizes and avoid the startup overhead on each batch. The maximum number of batches that you can run in an EIM process is 1,000.

Perform regular table maintenance on interface tables. Frequent insert or delete operations on interface tables can cause fragmentation in the tables. Consult your database administrator to detect and correct fragmentation in the interface tables.

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

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

Set the USING SYNONYMS parameter to FALSE in the .ifb configuration file to indicate that account synonyms do not need to be checked.

Avoid using the UPDATE PRIMARY KEYS parameter in the .ifb configuration file.

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

above listed tips are some of the very useful eim performance improvement techniques.

To use the DELETE EXACT parameter to delete data from base tables other than the target base table, specify the user key columns only for a single base table for each row in the interface table. When specifying rows for exact deletion, make sure any columns not necessary to specify the row to be deleted are NULL to avoid problems with deleting from the wrong base table. EIM tries to enforce this behavior by requiring other user key columns to be NULL. If a row cannot be identified as clearly referring to a row in a single base table, that row will fail to be deleted.

The following procedure explains how to delete data from base tables other than the target base table using the DELETE EXACT parameter with the following scenario as an example.

In this example, EIM_ACCOUNT is mapped to base tables including S_ORG_EXT, S_ORG_PROD, and S_ORG_INDUST. If you want to delete data only from S_ORG_PROD, and not delete data from S_ORG_EXT or any other base tables, complete the following procedure.

To delete data from base tables other than the target base table
1 Populate the following columns in the IF table (such as user keys for the S_ORG_PROD table and all the special IF columns):
■ ACCNT_NAME
■ ACCNT_LOC
■ INS_PROD_NAME
■ INS_PROD_VENDR
■ INS_PROD_VENDR_LOC
■ INS_DT, ROW_ID
■ IF_ROW_BATCH_NUM
■ IF_ROW_STAT
■ ROW_ID

2 Add or modify the following process section in your .ifb configuration file:
TYPE = DELETE
BATCH NUMBER = < number used to populate IF_ROW_BATCH_NUM column>
TABLE = EIM_ACCOUNT
ONLY BASE TABLES = S_ORG_PROD
DELETE EXACT=TRUE

3 Run EIM.
This will delete all rows from the S_ORG_PROD table that have user keys that match the rows in your IF table.

This is Siebel EIM Interview Q&A Part 3 We have collected the Siebel real time interview questions related to EIM ( enterprise integration manager) , these are asked in real interviews in most of the companies. All the best for your job interview!

1.What is the behavior of the EIM merge process?

Ans: Data from the record you select as the surviving record are preserved. Data from the other records are lost. If there are other records associated with the records you merge, those records—with the exception of duplicates—are associated with the surviving record.

2.Why is the IF_ROW_STAT column set to the value NO_SUCH_RECORD after running a merge process?

Ans: If you do not correctly populate all the user key columns, the merge process will fail and the IF_ROW_STAT column in the interface table will be set to the value NO_SUCH_RECORD. This indicates that EIM cannot find the appropriate rows to merge using the specified user keys.

3.Can EIM be used to merge rows from secondary tables?

Ans: EIM can only be used to merge rows from target base tables, and not secondary tables. For example, the target base table for EIM_ASSET is S_ASSET. EIM can only be used to merge two or more S_ASSET rows into single S_ASSET rows. You cannot use EIM to merge two or more S_ASSET_CON rows into single S_ASSET_CON rows. During EIM merge, EIM will merge rows from the target base table, and update the rows from the secondary tables to reference the surviving target base table rows. If you try to merge two secondary tables rows into one row by populating the interface table with user keys of the secondary table rows, the interface table victim and survivor rows will have the same target base table user keys values, which will cause the target base table row to be deleted.

4.What is the recommended number of rows that can be loaded in a single batch?

Ans: For an initial load, you can use 30,000 rows for a large batch. For ongoing loads, you can use 20,000 rows for a large batch. You should not exceed 100,000 rows in a large batch. Furthermore, you should limit the number of records in the interface tables to those that are being processed. For example, if you have determined that the optimal batch size for your system is 19,000 rows per patch and you are going to be running 8 parallel EIM processes, then you should have 152,000 rows in the interface table. Under no circumstances should you have more than 250,000 rows in any single interface table, since this will have a tremendous negative performance impact. NOTE: The number of rows you can load in a single batch may vary depending on your physical machine setup. To reduce demands on system resources and improve performance, you should always try to use smaller batch sizes.

5. Should EIM stop processing when multiple rows fail a pass?

Ans: EIM is designed to import large volumes of data. Most failures are caused by data errors. It is usually faster and easier to correct the data errors and resubmit the corrected rows as part of a subsequent batch than to reprocess an entire batch. EIM does not stop when failures occur.

EIM Interview Questions -Part 2

We have collected the Siebel real time interview questions related to EIM ( enterprise integration manager) , these are asked in real interviews in most of the companies. All the best for your job interview!

1.How do I import international phone numbers using EIM?

Ans:

To import international phone numbers, the phone number must be prefixed with a plus (+) sign and the country code. For example, an international phone number with a country code of 44 should have the following format: +44123456789. Any phone number without a preceding plus sign in the database will be treated as an U.S.A phone Number. This will lead to the display of +1 in front of the phone number, and the use of the corresponding PHONE_FORMAT if the regional settings of the client are different.

2.How do I import URL links into the S_LIT base table?

Ans:

To import records as URL links into the S_LIT base table, the FILE_NAME column must not be null and the FILE_EXT column must be null for URLs.

3.When data is exported using an interface table (such as contacts), why doesn’t data from related child tables (such as opportunities) get exported?

Ans:

For all columns to export using an interface table (both data from the base table and data from related child tables), you need to add or modify the following line in the .ifb configuration file:
Export all Columns = TRUE
NOTE: Rows from child tables of related child tables will not be exported.

4.What is the behavior of the EIM delete process?

Ans:

The delete process performed by EIM is cascade delete. The data deleted is not restricted to the base tables mapped to the interface table that you specified in the delete process, but all child records as well. You should be very careful and specific when specifying delete criteria.
For example, using the criteria "DELETE MATCHES = EIM_PARTY, (CREATED > xxxxx)" will cause all records of S_PARTY that matches this criteria to be deleted from the database.

5.Is it possible to delete or merge rows that have the same primary user key and different conflict IDs using EIM?

Ans:

This is not possible. EIM relies on user keys to identify rows in base tables. If there are two rows in the base table that have the same user key but different conflict IDs, EIM cannot distinguish these rows. In such case, the IF_ROW_STAT field of the row in the interface table will be marked as AMBIGUOUS.

NOTE: When you are deleting records based on user keys, the parameter DELETE EXACT should be specified in the .ifb configuration file.

6. Can I remove unnecessary seed data by deleting all rows from the S_LST_OF_VAL base table?

Ans:

No, you should not remove unnecessary seed data by deleting all rows from the S_LST_OF_VAL base table. If you do so, you will not be able to reimport “clean” data and you will be forced to rebuild the seed data or restore from backup.

Use Search box to find more Siebel EIM Interview questions and Answers.

Complete the following procedure:

 To populate the PR_PROD_LN_ID column in the S_PROD_INT base table

Populate the S_PROD_INT base table using the EIM_PROD_INT interface table.

Populate the S_PROD_LN base table using the EIM_PROD_LN interface table, and the S_PROD_LN_PROD base table using the EIM_PROD_INT1. You need to populate the S_PROD_INT base table before the S_PROD_LN and S_PROD_LN_PROD base tables so that the PROD_ID key is resolved appropriately.

If you are using EIM interface tables, you can explicitly set primary addresses for accounts. If you are not using EIM interface tables, you can still set primary addresses using IF interface tables. 

If you are loading accounts with single addresses, you should use the address fields in the EIM_ACCOUNT table. If you are loading accounts with multiple addresses, do not populate the address fields in the EIM_ACCOUNT table. Instead, use the EIM_ADDR_ORG table to load all addresses for these accounts. If you need to set a primary address in this case, import the primary address using the EIM_ACCOUNT table in one batch, and the rest of the addresses using the EIM_ADDR_ORG table in another batch.

NOTE: This procedure works only for an account that does not already have an address with which it is associated.

To set the primary address for an account

1 Populate the EIM_ACCOUNT table with the following primary address data which maps to the S_ORG_EXT and S_ADDR_ORG base tables:

■ ADDR_ADDR

■ ADDR_CITY

■ ADDR_STATE

■ ADDR_ZIPCODE

■ ACCNT_LOC

■ ACCNT_NAME

2 Run an EIM import process for the EIM_ACCOUNT table. The address will automatically be set as primary.

3 Populate the EIM_ADDR_ORG table with other addresses. Make sure the account data (ACCNT_LOC and ACCNT_NAME) is consistent with that imported earlier in the S_ORG_EXT table. The following columns need to be populated in the EIM_ADDR_ORG table:

■ ADDR

■ CITY

■ STATE

■ ZIPCODE

■ ACCNT_LOC

■ ACCNT_NAME

4 Run an EIM import process for the EIM_ADDR_ORG table. The addresses will be associated with the related account.

The following example uses this procedure to import two addresses for the ABC CORP account located in SF and sets the 111 MILL ST FREMONT CA 94536 address as the primary address.

To set the primary address of ABC CORP as an example

1 Insert the primary address into the EIM_ACCOUNT table by executing the following SQL statement:

insert into EIM_ACCOUNT (ROW_ID,IF_ROW_BATCH_NUM, IF_ROW_STAT,

PARTY_UID,PARTY_TYPE_CD,ADDR_ADDR,ADDR_CITY,ADDR_STATE,

ADDR_ZIPCODE,ACCNT_LOC,ACCNT_NAME,ADDR_ACTIVE_FLG,

ADDR_BL_ADDR_FLG,ADDR_DISACLEANSEFL,ADDR_MAIN_ADDR_FLG,

ADDR_NAME_LOCK_FLG,ADDR_SHIP_ADDR_FLG,ADDR_ADDR_NAME) VALUES (1,1,'FOR_IMPORT','ABC CORP PARTY','Organization','111 MILL ST',

'FREMONT','CA','94536','SF','ABC CORP','Y','Y','Y','Y','Y','Y','Fremont facility')

2 Run an EIM import process by adding or modifying the following process section in the .ifb configuration file:

[Import Address Data]

TYPE = IMPORT

BATCH = 1

TABLE = EIM_ACCOUNT

3 Insert the remaining address into the EIM_ADDR_ORG table by executing the

following SQL statement:

insert into EIM_ADDR_ORG (ROW_ID,IF_ROW_BATCH_NUM,IF_ROW_STAT, ADDR,CITY,STATE,ZIPCODE,ACCNT_LOC,ACCNT_NAME,ADDR_ACTIVE_FL,ADDR_BL_ADDR_FLG,ADDR_DISACLEANSEFL,ADDR_MAIN_ADDR_FLG, ADDR_NAME_LOCK_FLG,ADDR_SHIP_ADDR_FLG,ADDR_ADDR_NAME) VALUES (1, 1,'FOR_IMPORT','2050 LAKE DR','SAN MATEO',‘CA','94555',

'SF','ABC CORP','Y','Y','Y','Y','Y','Y','Fremont facility')

NOTE: Make sure that ACCNT_NAME and ACCNT_LOC are populated with the exact data that is in the S_ORG_EXT table for the respective account. 4 Run an EIM import process by adding or modifying the following process section in the .ifb configuration file:

[Import Address Data]

TYPE = IMPORT

BATCH = 1

TABLE = EIM_ADDR_ORG