Function Categories

For each template there are two mandatory functions, a Get get_representing_part) function and a Create function (create_representing_part). The Copy and Delete functions are implemented on demand if needed.

For target data models, which are implicitly opened for write, a simple call to initTemplateAPI is used for initialization. If the ‘with_rdl’ parameter is set to ‘FALSE’ no RDL is needed. This means that the converter is on its own with respect to correctness of the classifications it uses. If the ‘with_rdl’ parameter is set to ‘TRUE’, the templateAPI looks for an RDL with the name <target_model_name>_RDL or an RDL named plcsrdl as the default.

Source models are implicitly opened for read. The initTemplateAPI function will generate template extension instances if that has been done already. Therefore, when the source model is a PLCS population, it must temporarily be opened for write during the initialization stage. Afterwards the model should be reopened for read only again, in order to prevent accidental (faulty) updates of the source model.

xpxChangeOpenMode(XPXSOURCEMODELID,xpxRW);

PLCSMODELID := XPXSOURCEMODELID;

initTemplateAPI(TRUE);

xpxChangeOpenMode(XPXSOURCEMODELID,xpxRO);

PLCSMODELID is the identifier of the model addressed by the templateAPI. By default PLCSMODELID is set to XPXTARGETMODELID. In case the source model is a PLCS population, the PLCSMODELID must be switched to XPXSOURCEMODELID during initialization. XPXSOURCEMODELID and XPXTARGETMODELID are EDMxpx built in variables.

The init function does not only initialize the templateAPI itself, but also the model (PLCS population) on which the API operates. The representing_part instances are initialized with the following call:

This call will return an aggregate of all representing_part instances. The representing_part instances will be generated, if that has not been done before. Instances of other template extension entity types are initialized in a similar way. Since many templates are layered on top of other ones, some get_xxxxx functions may call other ‘get functions’. Due to these dependencies the order of the initialization calls is significant. For the same reason some of the templates have their own private initialization flag in addition to the global one (initialized).

The following applies to Get functions:

• When all arguments are indeterminate (the value is ? which is similar to null in Java) all instances of that template type are returned (can be none).

• When some of the arguments are supplied a Get function behaves as a search. In this case a function invocation returns an aggregate of those instances that match the input parameters (can also be none).

If template extension instances have been initialized before (private or global flag is checked), the search section is entered. There is not any one recommended method/way to implement the search. The implementation all depends on the structure of the template.

Section 2 is entered if template extension instances have not been initialized so far. If you look at get_representing_part, Section 2 starts with:

xpxGetEntityExtentBN (PLCSMODELID,'Part_view_definition',prod_def_bag);

REPEAT i := 1 TO SIZEOF(prod_def_bag);

.......

For example a loop over all instances of 'Part_view_definition' in the population. This is the “root” in the template, and there shall be one representing_part instance for each 'Part_view_definition' instance. Other template types have similar one-to-one correspondences between the “root” and the extension entity.

'Part_view_definition' instances that are not properly instantiated are silently skipped. If the population has been validated correctly beforehand such an event should never occur. An exception should have been thrown, or at least the instance should have been logged as a faulty one.

A part may have many alias identifications (like Part_name) in addition to the principal Part_identification_code, but in this context the list returned from get_assigning_identification is iterated over in order to find an identification that is classified as Part_identification_code or a possible subtype.

A Part_version can have no more than one identification (one version id). Therefore the utility helper_get_one_assigning_identification is used to get this single version if any.

The classifications attached to Part_view_definition.initial_context (View_definition_context) are obtained using the get_assigning_reference_data function. The one that is Discipline_domain (or subtype of it) are assigned to domain.

The classifications attached to Part_view_definition.initial_context (View_definition_context) are obtained using the get_assigning_reference_data function. The one that is Life_cycle_stage (or subtype of it) are assigned to life_cycle_stage.