Overview

Features

During the import, all data imported to Perfion is related to features and thus, it is important to understand what features are, how they are created and what properties they may have.

Features are data objects in Perfion, which has specific base data type, general properties, data properties and may have various advanced properties. Features can also have different configurations, which allows creating relations from one feature to another.

Feature Base Data Types

Feature base data types are related to the type of the data stored within feature. The type can be Number, Date, Text, etc. In case feature data is imported, then it is important to define data so, that each data is valid based on its base data type. When importing feature data Perfion will validate incoming data based on each feature’s data type and will reject data, which have incorrectly defined values or even stop the import.

Table below shows feature base data types supported by feature data import.

Compound data type is considered as deprecated and it is not supported.

Feature data import support only simple data types. Table and Search data types are complex types and require more than one value to be created and thus are not supported.

Specifications for data types are shown in the table below.

Refer to Figure 1 to see how feature base types are organized in Perfion.

Date and Number Data Format

The import data formats for Number and Date type features when defined in the import data will be handled based on how they are defined and which culture is used to run the import.

The import can run directly from Perfion Windows client, but it could also be executed from Actions, Web Client, Application Server and other external sources. The local PC culture settings will be used by default based on where the import runs, so it is important to match the import data to that PC culture or to define the custom import data culture.

The Date and Number type feature data can be defined in several ways using different types of import data files and there is also a special import parameter which allows overwriting the current PC culture.

• String/text data. If the import data for Number and Date type features is defined as a simple string/text, then the import will use the culture to parse string/text values in order to convert data to actual values which will be used in the import. The string/text values in this case should match the formatting supported by the chosen culture:

  • Using local PC culture. If the custom import data culture is not defined, then by default the local PC culture will be used where the import is running from.

  • Using custom culture defined via import parameter. If the custom import data culture is defined, then it will be used for all incoming data when parsing it.

• Strong type data. If the import data for Number and Date type features is imported from XML file with schema which defines number and date values as ‘double’ and ‘date’ accordingly, then the import will take this into account and will handle the incoming data in culture invariant way. In this case local PC culture or culture defined via import parameter will not have any effect on this data and it will be imported correctly. Note that when importing data from Excel file it should work in a similar way like using XML file with schema, e.g. if the data in the Excel is defined correctly to be of numeric and date types accordingly.

Open

Figure 1: Simple features, base feature and stage feature

Feature General Properties

Feature general properties defines feature ID, unique name, caption, how and where feature will be shown in Perfion, etc. Refer to Figure 2 to see available feature properties.

The most important property to know for feature data import is feature’s unique name. Unique name will be used to identify features in the import data.

Open

Figure 2: “Feature Definition” window

Feature Data Properties

Feature data properties define how features will behave, how and where the actual feature data will be stored, etc. Refer to Figure 2 to see available feature data properties.

There are many data properties and several can be chosen for the same feature. For example, feature can be selectable with sortable multi-value data and that data can also be localizable. The terminology used when describing features will be derived from data property names and therefore, the before mentioned feature, can be called “selectable” feature, “multi-value” feature, “localizable” feature, etc.

Feature data import depends on data properties and will use different methods to correctly handle incoming data. Therefore, it is important to understand how to define import data in order to import it correctly. Not all data properties can be used in feature data import. The table below shows which data properties are supported.

Feature Remote Properties

Remote properties allows changing feature type from a normal feature to a remote feature. One can also specify remote feature data source and other parameters.

Remote features are read only features, which have data retrieved from remote data sources. Data can be obtained from remote web service, database or OData service. These features cannot be used to import data into, because their data does not exist in Perfion. Each time remote feature data should be shown anywhere in Perfion, the data is retrieved from remote data source. One can know if the feature is remote by checking “Remote” section in “Feature Definition” window (refer to Figure 2). If data fields are blank, then the feature is not a remote feature.

Feature data importer does not support remote features.

Import Feature

Import feature is a feature selected to import data or configurations to. Import feature can be a simple or a base feature. Import feature selection defines the scope of import for data import. By choosing a feature, which will be used to import data to, one can achieve different import goals. For example, by selecting a simple selectable feature as import feature one can import default values to selectable feature. If base feature is selected as import feature, one can import data to multiple features at the same time e.g. to import data into import feature items.

Note that only selectable features can be used as an import feature.

In Figure 3 it is shown how base feature “Product” is selected as import feature.

Import Feature Items

Import feature items are data records for that feature.

If import feature is a simple feature, then it will have only one value per item, which will be import feature’s value.

If import feature is a base feature, then item will have import feature’s value, as it was with simple feature, and additionally it will also have one value per each feature related to base feature. For example, from Figure 3 the Import feature “Product” items will consist of: “Product” feature value (this is import feature’s value), “Item Number” feature value, “Image” feature value, etc.

Item Hierarchy

Feature items may have hierarchy and only lowest level hierarchy items will be used as feature items (normal items). All other (higher hierarchy level) items are called virtual items. Virtual items have the same properties and may have the same values as normal items, but they are only used for configuration of normal items and in most cases with inheritable features. For example, one can define default value common for several normal items by using only one virtual item and inherited feature. Refer to Figure 4 to see how this works.

Import allows configuring item hierarchy levels by using “_parent” keyword in feature data import. Refer to Parent feature for details.

Item Inheritance

Item inheritance is used to allow easier definition of item values, where multiple items may have the same value. For example, from Figure 4 items “Normal item 2” and “Normal item 3” could be described as two variants of the same product (e.g. car). Since all variants of the same product are made by the same manufacturer, the value could be defined only once by grouping all product variants under higher hierarchy item (“Virtual item 2” item) and specifying value there instead of doing this for each product variant item.

Inheritable feature value from higher hierarchy will overwrite any feature values for lower hierarchy level items, even if they had some values before. Moreover, if inherited feature value is specified for higher hierarchy level item, then one cannot define inherited feature values for lower hierarchy level items. The values will be always taken from higher hierarchy level items. The same rules applies also in feature data import. One cannot import values to lower hierarchy level items, if there exist higher level hierarchy items with existing not empty value for selected feature.

The only exception is when higher hierarchy level item does not have any value specified, e.g. the value is empty. Then all lower hierarchy level items will not be overwritten to empty values, but instead one will get possibility to specify independent values for each item, like if it was not inherited feature.

Read more: