Table type structures and table definitions can be created in STEP through STEPXML imports. However, table import files are primarily intended to transfer tables from one STEP instance into another, not to build table objects and tables anew. The recommended steps for using STEPXML files to import tables are as follows:
- Manually create and configure table type objects and table definitions on a STEP test environment
- Export these table types and table definitions in STEPXML. It is recommended to export the table types and table definitions in separate files.
- Import the table types file into the STEP production environment
- Import the table definitions file into the STEP production environment
The export and import process itself is straightforward, but multiple considerations must be taken into account to ensure that the import is successful. For example, since tables are defined on product / classification hierarchies, the same product / classification object types and hierarchies that are present on the source system must also be present on the target system. This also applies to attributes, assets, transformations, commercial terms, publication versions, contexts, and so forth. As such, this topic does not address the actual import process, but provides information on the prerequisites for a successful import and how to troubleshoot any errors that may occur with an import.
Importing the Files
Two types of files containing tables information can be imported into STEP: those containing System Setup table types, which are exported by selecting Include Table Types in the Export Manager; and those containing table definitions from product and classification objects in the Tree, which are exported by selecting Include Table Definitions in the Export Manager.
Files that contain tables information are imported into STEP like any other STEPXML file, either through the Import Manager or through an Inbound Integration Endpoint. For more information, refer to the Import Manager (here) and Inbound Integration Endpoints (here) sections of the Data Exchange documentation.
Note: Files containing resolved tables, which are exported by selecting Include Tables in the Export Manager, cannot be imported into STEP. They can be used for downstream purposes, such as translation of free text contained within table cells, but serve no purpose for a STEP import, as importing table definitions dynamically creates resolved tables.
Considerations and Limitations for Tables Imports
General
Both the target and source systems must be on the same version of STEP, and both systems must be on version STEP 8.3 or above.
Duplicate Data Setups
The setup data should be identical across test, QA, and production STEP systems when tables are being exported from one system and imported onto another. Considerations for mismatched setups are as follows:
- Object types (product and/or classification): Table object types must be resolvable on at least one product or classification object type. If these object types are missing in the target system, the table object types can still be created, but they will not be resolvable on any product / classification objects until those objects are created in the target system.
- Product and/or classification object hierarchy: It is recommended to use a dedicated 'test' node (or nodes) to define tables on the source system, then use an identical node on the target system, which uses the same STEP IDs, to import the definitions into. Once the definitions are applied to the dedicated node on the target system, the definitions can be copied from this node and pasted onto the table definition on another node in the same target system.
- Assets: Must have the same IDs and be linked to product objects using the same asset reference types on both source and target system.
- Contexts / dimensions: Since table types can be dimension dependent, for the purpose of free text, if a context does not exist on the target system, an error occurs on import. Table definitions themselves are context independent, so this is not a concern for definitions only, but if a context is present in the import file that does not exist in the target system, an error will still be thrown on import.
- Table types, row types, and column types should have the same ID on the source and target systems. If these types already exist on the target system, care must be taken before importing to ensure that the settings for these table type objects are the same in the import file, as the settings on the target system will be overridden and could potentially cause existing table layouts to be destroyed.
- Attributes, attribute transformations, and lookup tables must exist on both systems and have the same IDs.
- Table Transformations: The same table transformations should be present on both systems. A custom transformation on a source system cannot be created on a target system through import. If the transformation does not exist on the target system, an error will be raised in the background process execution report.
Table Type Imports
- It is not recommend to change column and row type IDs manually in the exported XML file since there are numerous places within the file where the ID must be changed.
- A table types import file should not be edited to create new colors. However, if a color already exists in the target system with the same name, the number associated with the color (the RGB definition of the color in integer form) will overwrite the color's RGB definition on the target system.
- Since rules do not use IDs, if there is a difference in width or color for a table rule with the same name on the source and target system, the incoming rule definitions will overwrite those on the target system.
Table Definitions Imports
Table definitions files cannot be edited by users, since all table configurations in a tables definitions file are contained in encoded strings.
Note: Table Type, Row Type, and Column Type definitions cannot be imported into STEP via Advanced STEPXML.
Error Handling
Even if some objects, attributes, transformations, and so forth are missing on a target system, an import of table types and/or table definitions can be successful, but with errors. Some errors will display in the Execution Report of the completed background process on the BGProcesses tab. In other instances, a table definition can import with no errors appearing in the BGP execution report, but the errors will be visible when viewing the table definition and/or preview on the product or classification object in the Tree.
This section shows a few common examples of errors that can occur with the import of table types and table definitions and how to troubleshoot them, but it is not a comprehensive list of every potential error. It is recommended to always run an import of table types and table definitions in test mode first to catch errors in the BGP Execution Report.
Errors Displayed in Background Processes
The following screenshot shows an example of errors thrown in a table types import that had table types that were resolvable (valid) on object types that are not present in the target system. The table types were created in the target system, but the errors inform users that these object types must be created in the target system before the configurations of the table types will match that of the source system.
Errors Displayed in Table Definitions and Previews
This example shows the display of an imported definition where a column type is not valid for the table type. the column type has been applied, but it is in red since it is not valid for this table type. Either the column type must be made valid for the table type, or another column type must be used.
The following screenshots show another set of errors, using before and after examples. The import was successful overall, but a few items were missing on the target system that required troubleshooting to correct.
Source Definition
Target Definition
In the target system, the table definition has been mostly recreated by the import of the definitions, but an attribute that was present in the source system (Product Name) is missing in the target system.
Source Preview
Target Preview
When viewing the table preview in the target system, additional errors are noticeable. The numbers in the screenshot correspond with the errors listed in the numbered list below the image.
- The first column of the table is missing because of the missing 'Product Name' attribute. Since the column is empty, the 'Remove Empty Rows/Columns' transformation has removed the column altogether, so now the first column in the table is 'Part No.'.
- 'Retail Price' is highlighted in red because the commercial terms list from the source table is missing on the target system.
- Even though the IDs display in the Part No. column, the values do not match those in the source table due to a missing attribute transformation that appends '-A' to the ID.
