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_IDEXPORT 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_IDFROM 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_UKEIM_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 FILELOG 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 = EXPORTBATCH = 1TABLE = 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 = EXPORTBATCH = 1TABLE = 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 = EXPORTBATCH = 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).orSet 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_IDS_CONTACT.PR_HELD_POSTN_IDS_ORG_EXT.PR_BL_PER_IDS_ORG_EXT.PR_SHIP_PER_IDS_POSTN.PR_POSTN_ADDR_IDS_POSTN.PR_EMP_IDNote 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 OccurrenceNo 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 ResolutionUse 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 )