Catalog Modeler

Introduction

Users often need a way of storing and classifying the many objects they have at their disposal, whether they be screws, ball bearings or computer parts. These objects may number tens of thousands, each with its own specific characteristics such as shape, color, size, diameter, length, etc. To facilitate fast and easy retrieval of such objects and avoid time-wasting redesign, Version 5 offers the possibility of creating catalogs. 

A catalog is a V5 document and is in the form of a tree structure made up of: 

1. Components: it is a reference to an external entity such as feature (e.g. User Feature, Power Copy), V5 documents (e.g. Part, Product) 
2. Families (end chapters): it is a set of components  
3. Chapters: a chapter references others chapters and families. It is a way of classifying the elements it refers to
4. Keywords: a keyword describes the chapter and the family content. You can associate keywords to chapters and families and thus, perform searches by keyword value to filter their contents.

This external catalog view is internally described by three object types:

1. Keyword:  it is like a property represented by a simple type (integer, real, double) or a knowledge type ( Length, Mass, Volume, Time ...)
2. Description: it contains a reference to an object (chapter, file, description, feature) and keyword values 
3. Chapter : it contains descriptions and keywords

This article presents the Catalog Architecture in the first paragraph to place the Catalog document in the V5 architecture, and so explains how you can you integrate in this architecture.

The rest of the article is to describe the internal view of the Catalog document: 

• The Catalog Document description 
• The Part Family description
• The Persistent Query description

Before reading it, it is important to already be familiar with the basic Catalog notions, see the referenced article [1], and with the basic Knowledge notions, see the referenced Knowledge home page [2]

Catalog Architecture

The Catalog architecture is the following [Fig.1]: a common API, two different user interfaces (CATIA and ENOVIA) and two storage modes (file and data base). You can use the same API to work on CATIA catalogs (file based) or on Enovia catalogs (stored in data base).

Fig.1: Catalog Architecture

The Catalog API is defined in the ComponentsCatalogsInterfaces framework. There are several domains coveraged by these interfaces:

• CATICatalogChapterFactory to create a chapter
• CATICatalogChapter, CATICatalogDescription and CATICatalogKeyword to handle the features of the catalog document
• CATICatalogQuery and CATICatalogQueryResult to do and obtain a query on a chapter
• CATICatalogPersistentQuery for the Persistent Query 
• CATICatalogBrowserFactory to create a Catalog Browser and CATICatalogBrowse to handle it
• CATICatalogInstantiation, CATICatalogSynchronize and  CATICatalogEnable to link a new type of component to a description.

Catalog Document Model Description

A catalog is made up of chapters, keywords and descriptions.

Definition

Fig.2: Catalog Model Description

The root container of the catalog document implements the CATICatalogChapterFactory interface. As usual, to retrieve the root container of a document, use the CATInit interface and its GetRootContainer method. 

All the chapters, created by the CATICatalogChapterFactory are in the same root container. 

The description has a link to an object (_ReferencedObject) which can be 

• a file (Part, Product,...), 
• a feature (User Feature, Power copy,...),  
• a chapter ( to create a chapters tree structure)
• a description (See the persistent query model)

This object can be retrieved by the GetObject method of the CATICatalogDescription interface. In the chapter's case, see the "Description" sub-section in the Catalog Overview article [1] to have details about this method.

The keyword has a name (_Name) and has a type (_Type). The type is a knowledge type [2]. For the keyword value see the next paragraph.

Prototype/Instance Mechanism for Descriptions

This mechanism [3] enables to kept on the reference description, at least, the keywords default value. Although the reference description is not visible by CAA API the default values are accessible through the chapter API.

Fig.3: Prototype/Instance Mechanism for Description

The keyword value management is the following:

• an own value set on the instance description 
• otherwise, the default value set  on the Ref. description
• oherwise, the keyword is "Unset"

The QueryResult Object

The QueryResult object does not appear in Fig.2 because it does not exist in a catalog document. It is a temporary object to filter a chapter. This object is used in three cases:

1. When the description contains a link to a chapter, the GetObject method on a CATICatalogDescription interface returns such object,
2. When a persistent query is associated with a chapter, 
3. As result of a query on a chapter.

Fig.4: QueryResult Model Description

The QueryResult object has a chapter behavior (it implements CATICatalogChapter). Its descriptions are a sub-set of the filtered chapter's descriptions. Notice its link to the filtered chapter (the red arrow). 

Part Family Model Description

A Part family is a set of descriptions coming from the design table of a document (only Part document are now integrated).  

Fig.5: Part Family Model Description

The family is a chapter and its keywords come at least from the headers of its design tables [2]. Those keywords are automatically created when you add a Part family in a chapter. You can also add keywords on such family. 

• Reference Description contents
  • Not directly visible by CAA API
  • One for each Part with design table
  • Could be synchronized with design table through the Edit/Links command to add/remove the generated descriptions (the instance descriptions)
  • _KeywordValue: The keyword  of the chapter. The keyword values are the default values.
• Instance Description contents
  • Visible by CAA API
  • For a Reference Description, there are as many instance descriptions as configuration rows in the design table. 
  • _KeywordValue:The keyword values are those of one row of the design table if the keywords come from the design table, otherwise it is the value of the keyword set by CAA API or by the end user through the Catalog Editor.
  • It keeps the PartNumber value (mandatory to retrieve the appropriate design table row for instantiation)
  • _ReferencedObject: It has a link to the resolved part (part updated with the appropriate configuration of the design table if the resolution has been launched)

Persistent Query Model Description

Another way of creating descriptions in a chapter is using persistent queries. It is a query done on an external chapter (chapter from an another catalog). 

Fig.6: Persistent Query Model Description

The chapter has keywords but in opposite to the Part family case, it is only end user keywords. 

• Ref Description contents
  • Not directly visible by CAA API
  • One for each persistent query associate with the chapter
  • Could be synchronized by the Edit/Links command. A synchronization will re-launch all recursive queries on the pointed chapter. The instance descriptions are updated.
  • _KeywordValue: The keyword of the chapter. The values of these keywords are those that you set using the CATICatalogPersistentQuery interface. 
• Instance Description contents
  • Visible by CAA API
  • For a Ref Description (so for each persistent query), there are as many descriptions as descriptions matching the query in the external catalog.
  • For a Ref Description, its resulting instance descriptions are generated only if the query is solved (ResolveQuery method)
  • _KeywordValue: As usual, the keywords of the chapter can be valuated
  • _ReferencedObject: The external description 

The keyword value management is the following:

• an own value set on the instance description 
• otherwise, the default value set by the persistent query on the Ref description
• otherwise, the default value set by the family on an object not represented on the previous schema Fig.6
• oherwise, the keyword is "Unset"

[Top]

In Short

This article describes the catalog architecture and the internal view of a catalog document. 

[Top]

References

History

Copyright © 2002, Dassault Systèmes. All rights reserved.