Configuration Tips - Customer/Product Extensions
- Jana Volencová (Deactivated)
- Jan Panoušek
- Ondřej Tesař
Tips and Notes
Topic | Tip | Details |
|---|---|---|
Using SKU as business key | Product SKU can also be selected as the Business Key. It is recommended to use the first attributes (attribute1, attribute2, attribute3, ...) as the Business Key to achieve better performance. If needed, a single database index (attribute1, attribute2, attribute3, ...) can then be created for all product extensions (this requires discussion with the Support team). | |
Product Extensions maximum column length | For each column, there is a limit of 255 characters. For product extension with 50 attributes, the limit is 70 characters for each column. If you change the size of the product extension from a lower number of attributes to 50 attributes and some of the attributes have more than 70 characters, a warning is displayed and the character string is truncated. |
|
Unique business key validation | Column(s) used as Business Key must be unique. This uniqueness restriction is applied only when the user enters data manually in the user interface, and also for data modified via calculation logics. It is not forced, however, during integration. | |
Changing number of attributes for extension with large data | When changing the number of attributes for an extension with large amount of data, make sure that no calculations will use that customer extension during the data migration. Consider stopping the adapters and calculation flows and do not allow the end users to trigger any calculation. In extreme cases, consider temporarily dropping the unnecessary database indexes for the source and target CX table and recreate them after the migration. | |
Log off needed when changing Customer Master Extensions | After changing Customer Master Extensions, you need to log off and log in again to see the changes reflected in other parts of the application. Changing the name or type of an existing Customer Master Extension that is used in a calculation logic will require a change there too. Note that the configuration is cached and it can take up to five minutes for a change to take effect. | |
Querying the PX tables | When querying the PX# tables using the generic functions, it is important to know that data rows of all PX# tables (with the same number) will be stored in the same database table. So the query to PX# must always contain a filter for the name of the table to distinguish which rows you want to retrieve. | |
Querying Company Parameter tables | When querying the Company Parameter tables using the generic functions, it is important to know that data rows of all (e.g. "Matrix(1)") tables are stored in the same MLTV table. So when constructing the query, ensure you filter by ID of the Company Parameter table. | |
Attribute columns values go back to String | When limiting the number of columns to get back, the system will not convert the attribute# columns values to their expected data types. Instead, all the values will stay as Strings. So you must take care of the conversion in your Groovy code. | |
Filtering CX/PX attributes with subclauses | When you filter in Products using Product Extensions attributes or in Customers using Customer Extensions attributes, using subclauses will return correct results only if the | |
CX/PX/SX type code while searching with | When searching CX/PX/SX tables using |
Found an issue in documentation? Write to us.