Create Functions

The main behavior of Create functions is simple in the sense that the client application (converter) always calls the Create function without the need to check beforehand whether an instance matching the input parameter already exists or not. The Create function does that for you by calling the corresponding Get function. So the Create function either creates and returns a new instance or returns the instance identifier of an already existing one.

A create function has two main sections.

Apart from checking the input parameters, the first section of a Create function simply consist of a call to the corresponding Get function. If an instance that matches the actual parameters given exists, the function returns with the instance identifier of the instance. Otherwise section-2 of the function is entered.

In section two the main template instance (REPRESENTING_PART) is created. Actually that is what takes place at the end of the function. As depicted in the template layers diagram, template entities are layered on top of pure PLCS entities and normally on top of other template entities as well. Not all instances belonging to a template instance structure are created. To reduce the volume/size of the population as much as possible, redundancy is avoided by reusing already existing instances whenever possible. Using the create_representing_part as example the steps in section-2 are described.

There should be only one single Product_category (name = part) in a population. It is reused and linked to all Parts through the Product_category_assignment.products aggregate. The xpxGetEntityExtentBN returns all instances of a given type. Normally there is a performance penalty when iterating through the aggregate of instances returned. In this case, however, this function can safely be used, since there is maximum one single instance of Product_category_assignment in the whole population.

The get_assigning_identification function is used to find out if a Part with the given identification already exists. If that is the case, that Part is reused. Otherwise a new Part is created, and its identification is attached using the create_assigning_identification function.

A list of all Part_versions for the Part is obtained. (this list is of course empty if the Part was newly created) . For each Part_version in the list the get_assigning_identification function is used to find out whether one of them has an identification that matches the given input. If that is the case that Part_version is reused. Otherwise a new Part_version is created and connected to the Part. Its identification is attached, as well, using the create_assigning_identification function.

There are a very limited number if View_definiton_context instances in the population. Therefore the aggregate returned by xpxGetEntityExtentBN can safely be iterated over without any performance penalty. A View_definiton_context is identified by means of two classifications (life_cycle_stage and domain). If a View_definiton_context instance with both classifications already exists, it is reused. Otherwise a new View_definiton_context instance is created, and the create_assigning_reference_data function is used to attach the two classifications.

A new Part_view_definition is always is always created (as a consequence of that a new representing_part instance is created. The Part_version and the View_definiton_context are attached.

Finally the extension instance representing_part is created. Forward references to subordinate levels are put in place. These forward references make life easier for a programmer. One can for instance obtain the identification of a Part directly. In PLCS many relations are “incoming” ones (e.g. Identification_assignment, Classification_assignment, Assigned_property). Therefore the Express function Usedin has to be used in order find the identification(s) connected to a specific Part. Therefore the forward references from representing_part and other extension entities are convenient.

Population of the representing_part attributes :

Copy functions are not relevant when converting back and forth between legacy data or proprietary format such as the Windchill Express schema. The Copy functions are applicable when a DEX source population is merged into a target DEX population. A prerequisite is that the source and target schema are the very same one.

Copy functions consist of two rather simple steps. Copy functions take a source (representing_part) instance as input. The input parameters required for the create (create_representing_part) function are extracted from the source instance. Then the create (create_representing_part) function is invoked. The create function will either return an already existing instance or create a new one. So applying the copy functions to all instances in a source population, the resulting target population will become a union (or merge) of the source population and the original target population.

Delete functions are normally not relevant when converting back and forth between legacy data or proprietary format such as the Windchill Express schema. Such functions are applicable when a DEX database is maintained over time. For instance in connections with applications like TruePLM.