Thursday, March 29, 2012

Extending the Physical Data Model in Siebel CRM

Do you know what caveat means? Well you sure are internet savvy and have googled or wikipediated it already. Caveat is latin for "beware".

This post is a follow up to the last article on how not to extend the Siebel data model.

I considered it worthwhile not to go into too much detail on how to create new columns or tables (that should be common Siebel developer knowledge) but instead point out some "caveats". So beware of the following points when you extend the Siebel data model:

1. All changes to the Siebel data model must be done through Siebel Tools and can only be additive in nature.

Believe it or not, a common source for headache in our typical next-door Siebel project is adding (or modifying) columns, tables or indexes through direct DDL scripting rather than creating an object definition in Siebel Tools and applying it properly.

2. Schema changes must be applied to all databases

When we say "all databases" we mean:
  • All local developer databases
  • The development server database
  • All other server databases (test, production, training, etc.)
  • Mobile user's local databases (if you are using Siebel Remote)
Now that's a big table! (The Writer; sculpture by Giancarlo Neri)
3. What about EIM tables?

If you intend to populate or update your brand new tables and columns with Enterprise Integration Manager, then don't forget to extend the interface tables as well. And don't forget the EIM table mappings.

4. Siebel Remote

If your company uses Siebel Remote to synchronize server databases with mobile clients, you must also take care of the Dock objects so that the data in your new columns and tables is synchronized.

5. Performance

Performance shouldn't be considered last but better late than never. In the unlikely event that your end users never query or sort the data in your new columns and tables, you can forget about indexes. Otherwise you end up with a facepalm moment, because, you know, you forgot to create an index.

So do we have a checklist here or what? Did I miss a caveat? Please share your knowledge using the comments.

have a nice day



Joan Martí Peraire said...

Hi, that's so useful check list in order to ensure that "Alles ist in Ordnung"...

Anyway, I think that another aspect to consider in this check list is the impact on ETL (in case your Operational system involves the integration into existing analytical systems).

Alexander Hansal said...

Hi Joan,

many thanks for the additional check point.

Of course, if Siebel is integrated with any other system (such as OBAW or back-office apps) then extending the data model grows in just more than one dimension...

have a nice day


Joan Martí Peraire said...

well, thinking about that, if there are new columns, then another point is that it's required review configuration related to Import Objects (in case of export through menu enabled)

Anis Shaikh said...

Docking rules already exist to synchronize data present S_ORG_EXT_XM tables with the Accounts. My question is if we extend this table by adding custom columns, does the data in these columns synchronize without making any additional changes? i.e. Does addition of any custom column require any other configuration change for the data present in these columns to be synchronized from local to server or server to local for Siebel Mobile Clients. Please Clarify

Alexander Hansal said...

Hi Anis,

the mechanism is related to records, not rows. So theoretically (I haven't tested it...) any custom extension column to a table which is already a member of a dock object should be synchronized.

Of course you must propagate the schema changes to the local database by either a new db extract or by shipping ddl scripts to the remote clients and executing them locally.

have a nice day


Anis Shaikh said...

Thank you for your response Alex. Your blogs are always informative.