This topic introduces the reader to some fundamental STEP concepts that provide a foundation for the rest of the material in the Getting Started documentation, as well as the System Setup documentation. The focus of this topic is on data structures and data management, and is not intended to be an introduction to the full capabilities of a STEP system.
Object Types Overview
Technically, nearly everything in STEP is an object, and object types must be defined for which instances of objects can exist. Object types provide a specific label for levels within a taxonomy, given to different elements within the system. Nearly every object in STEP is labeled with an object type to help identify what it is (i.e., a product or entity rather than an image, a TIF rather than a PDF, etc.). This includes entities, products, product categories, alternate hierarchies, images and other assets, attributes, and LOVs. Through the use of object types, system administrators can control how rigid or loosely defined the database will be in terms of object creation and where objects are allowed to "live" and/or be used. This labeling also becomes very important when working with exported data so that each type of object in STEP can be identified for special handling in web applications or other uses outside of STEP. Object types in STEP can largely be divided into two categories:
- Tree Object Types: Object types that make up the standard STEP hierarchies accessible on the Tree tab in workbench. Many of these object types can be further grouped into five categories of object types, referred to as the super types. Tree object types are defined in System Setup, but instances of the object types are accessed within the Tree.
- System Setup Object Types: Also referred to as Basic Object Types. This category encompasses all of the remaining object types that make up a STEP system. Among many other things, this includes attributes, users, integration endpoints, workflows, and business rules. System Setup object types are defined in System Setup, and instances of the object types are also accessed within System Setup.
More information on object types in general, including how to create and maintain object types, can be found in the Object Types and Structures section of the System Setup documentation.
Object Super Types
Each super type has specific characteristics that make it suitable for modeling particular types of data. For example, inheritance of data is available within the Product super type so objects that share data based on common characteristics are typically modeled using this super type. Alternatively, digital media files are housed using the Asset super type, which allows for automatic reading and storing of asset properties such as size and format. Any number of individual object types within each super type can be created. For example, a system may use both an 'Icon' object type and an 'Illustration' object type (along with any number of others) within the Asset super type.
The object super types are:
More information on the characteristics of the various super types can be found in the Object Super Types topic within this guide.
Object Types Versus Object Instances
Two core capabilities for managing data in STEP are the Tree tab and the System Setup tab. In order to successfully use STEP, it is critical to understand the differences between the functions available in these two areas, specifically in relation to types of objects versus instances of objects.
Technically, everything in STEP is an object, including workflows, attributes, business rules, export and import configurations, products, classifications, images, etc. However, the term "objects" is more generally used to mean assets, classifications, entities, products, and publications. In other words, the super types are also all things that you can find on the Tree tab in STEP. This section focuses on the differences between object types and object instances for Tree objects, specifically those that fall into the super types.
For example:
The objects and structures available in the Tree will vary based on your particular data model, but the concepts described can be applied across any data model. Regardless of the specific names or structures, each node on the Tree tab is an individual object that has a defined "place to live" within a hierarchy. A user can right-click on many of these objects and have a 'New...' option, such as 'New Product' or 'New Classification', allowing them to create a new node in the hierarchy. For example, when right-clicking on the 'Apparel' object and selecting 'New Product', a dialog appears with an option to create a 'Level 2' object.
Typing a Name and clicking Create would create a new object as a child to the Apparel node. But what defines that a 'Level 2' object can be created on this node? And that it is a Product (blue) object rather than an Entity (gray) or Classification (yellow)?
The allowable structure of objects and hierarchies that are accessed in the Tree are defined in System Setup. To continue with the above example, we can observe that the defined object types and structures include a Primary Product Classification that has a number of levels. A Level 1 can only have a Level 2 child, which in turn can only have a Level 3 child. However, a Level 3 object type can have a number of child object types, including an Item Folder, Level 4, and a Sales Item Folder. A Sales Item Folder is a child of a Level 3 object type, as mentioned, but can also be a child to a Level 4. Similarly, a Sales Item can be child to multiple things, including a Sales Item Folder and a Sales Item Family.
The object types defined in System Setup provide the "skeleton" for the allowable instances of objects that can be created in the Tree. It is important to understand that it is only the structure and types of objects that are defined in System Setup, but any number of instances of the defined types can be created in Tree. This is best illustrated by viewing System Setup and Tree side by side, as shown below. Object instances are displayed in Tree, with red text indicating the corresponding object type designations from System Setup.
Notice in the above screenshots that a Level 2 object exists in System Setup only once, but there are multiple instances of it in Tree.
The same principles described for the Primary Product Hierarchy apply to all other hierarchies in STEP. For example, an entity hierarchy could have a Customer object type with allowable children of Address and Contact object types. The object types and structures are defined in System Setup, and instances of these objects can then be created in Tree.
Note that object super types can only exist within their designated hierarchy types. To clarify, a product hierarchy (blue hierarchy) can only contain object types of the product super type, while an entity hierarchy (gray hierarchy) can only contain objects of the entity super type. It is possible to have the visual appearance of mixed hierarchies, but this is accomplished via references rather than actual data structures. For example, products may appear in the Tree to be within a classification hierarchy, but this is due to references on the object, as shown below.
Notice that the corresponding System Setup structure for the above does not include the product object types.
The true residence of the product objects is within the Primary Product Classification, with a visual display of the product references into various classification hierarchies being just that: a visual display of references. However, assets are an exception to this concept. Assets are not part of the Classification structure in System Setup, but do in fact exist within this structure in Tree. Each asset must be linked in to one or more classifications, and this is the only location in which they "live" in STEP. Each asset automatically has a reference applied to each classification in which it is linked. More information on references can be found in the Reference and Link Types topic in the System Setup documentation. More information on the various object super types and their characteristics can be found in the Object Super Types topic within this guide.
Using the above information, the questions posed earlier in this topic can now be answered:
Why can we only create a Level 2 object under the Apparel node? Because in this particular data model configuration the Apparel node is a Level 1 object type, and only Level 2 object types are allowed to be created under a Level 1 object type.
Why can we not create an Entity or Classification under the Apparel node? Because only object types within the same super type can exist within the same hierarchy. And even if this was not the case, the structure defined in System Setup in this particular hierarchy only allows a Level 2 object type (of the product super type) under a Level 1 object type.
Note: All text data is saved in the system in Unicode UTF-8. All standard data exports from the system are also in UTF-8. Some system extensions may use a different character set on export, but the standard is UTF-8.
UTF-8 can define more than one million characters. To do so, it uses up to 4 bytes of storage. Regardless of whether it uses one, two, three, or four bytes, it is still one character and as such any character counts that are imposed on text attribute’s length is specified and counted in characters and not bytes.
As a standard, the Microsoft Arial Unicode font is used for display. Its character set supports most languages of the Americas, and Western and Eastern Europe (including Cyrillic and Greek). In some cases, as in the case with some Asian languages, additional fonts must be loaded onto the PC or MACs. But for most cases, the character set provided by Arial Unicode MS is sufficient.
For more information on Unicode UTF-8 the reader is advised to refer to the various web sites that describe its functionality, such as the Wikipedia site: https://en.wikipedia.org/wiki/UTF-8.