Customizing of the Product Catalog API 
Customizing of the Product Catalog API
When administration functions were added to the catalog API, customizing of the API changed.
The current configuration involves two files that have to be managed:
In the eai-configuration file, all configuration data specific for the connection to the SAP CRM system and/or the SAP R/3 system is managed.
Note the following information:
In the site configuration file, all configuration data specific to a special catalog engine (e.g. Requisite, Trex, etc.) is managed.
The three new types of objects that can be customized are:
Catalogs used to be backend objects, but now, the site and the servers are backend objects. There should be only one site per application.
In special test scenarios there might be more than one site configured in an eai-config.xml/eai-data.xml file. In that case, make sure you have a clear understanding of configurations, session scope, application scope, and caching, because a wrongly configured system in the business logic layer might be extremely hard to debug when problems appear.
In the site configuration XML file (a valid document with regard to the catalog.dtd) all catalog servers that the catalog API needs to know must be entered.
The catalog site and each server that is entered in the site configuration file must have a corresponding reference in the eai-configuration file. That is, because each server and the site are backend objects and they are consistently created via the EAI mechanism.
For the behavior of the catalog site, server and catalogs, it is important to know that all of them are cached. A site always asks the cache if a server it wants to create is already cached. The same happens with the catalogs created by a server. Therefore, the top level application that finally uses a catalog site should check with the catalog cache if a site has already been cached.