Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

FUNCTION xpxConvertModelsWithParameters (sourceModelsName, schemaMapName    : STRING;
                                         targetModelName, declarationsToLog : STRING;
                                         sourceLinesToLog, logFile          : STRING;
                                         maxLogFileSize                     : INTEGER;
                                         userOutputFile                     : STRING;
                                         options, numberOfUserParameters    : INTEGER;
                                         userPar1, userPar2, ... userParN   : GENERIC)
                                         status                             : INTEGER;

The xpxConvertModelsWithParameters function invokes the EDMmodelConverter to convert one or more existing data models (source models) in the EDMdatabase. The result of the conversion will normally be a new data model (target model) in the EDMdatabase. Optionally the result of this operation can be added to an existing data model. This operation can be used for model merging, i.e., merge more models to a new model or add the merge result to an existing model. This function is similar to the xpxConvertModels function, except that a possibility exists for the client application to supply a certain number of parameters to the conversion process to make the Express-X schema parameterized. From the conversion process the number of parameters is obtained by a call to the xpxGetNumberOfUserParameters function, and each of the parameters is obtained by a call to the xpxGetUserParameter function.

Note: The invocation of a xpxConvertModelsWithParameters operation will not immediately activate the new ?conversion/merging? process. The actual operation will be inserted in a queue and then immediately execution is resumed after the xpxConvertModelsWithParameter call in the calling process. The actual queue of ?conversion/merging? processes will be handled when the current active EDMexpressVM process is terminated.

The underlying schema of the target model (target schema) must exist as a dictionary model in the EDMdatabase before the EDMmodelConverter is invoked by this function. Likewise the Express-X schema that defines the conversion process must exist as an Express-X dictionary model before this function can be successfully executed. The functions edmiDefineSchema or xpxDefineSchema can be used to create a dictionary model of an Express schema in the EDMdatabase and the functions edmiDefineSchemaMap or xpxDefineSchemaMap can be used to create an Express-X dictionary model in the EDMdatabase. The source model will be unchanged when the conversion process is terminated. The EDMmodelConverter is utilizing the EDMexpressVM to perform the conversion process. To facilitate debugging of the conversion process, many options to trace the conversion process and to log events during the conversion process have been included. Express-X can be used as a programming language for creating, manipulating, and deleting data in any data model in the EDMdatabase that can be accessed by the caller, hence the specified Express-X schema can be successfully interpreted without creating in a new data model. An optional filter controls the logging of the conversion process. This filter is defined by the <declarationsToLog>, <sourceLinesToLog> and <options> arguments. The filter defines the following:

  •     What should be logged
  •     Which part of the Express-X schema should be logged

It is normally important to specify an appropriate logging filter to avoid the log output to fill up your disk.

Arguments


1TypeNameComment
2STRINGsourceModelsNameSpecifies the name of the source model. Model names are case sensitive. The source model can be open or closed. The calling EDMuser must have read access to this model.
3STRINGschemaMapNamename of the map schema
4STRINGtargetModelName

Specifies the name of the target model to populate with the result from the conversion. The <targetModelName> must be unique within the repository specified by the <targetModelRepositoryName> argument.There are tree states of the target model:

  1. Not existing - the target model will be created and populated.
  2. Existing - dependent of options, the result of the conversion will be added to the existing target model.
  3. Existing - dependent of options, the target model will be deleted and a new target model will be created and populated by the conversion process.

The model name must start with a letter and the rest of the model name can be any mix of alphanumeric characters and the underscore character. Model names are case sensitive.

5STRINGdeclarationsToLogSpecifies the Express-X declarations that should be executed when logging should be performed, i.e. the part of the schema defined in the <sourceLinesToLog> argument will only be logged when those parts are executed on behalf of the declarations specified in the <declarationsToLog> argument.Legal Express-X declarations are: Map, Compose and Statements. An Express-X declaration can be specified by the name, i.e., map name, function name, etc., or by the line number in the source schema where the actual construct is declared. The names of the Express-X constructs are case insensitive.Any number of declarations can be specified. White space and comma can be used as delimiter between each declaration in this argument. The order of the declarations in the input field is insignificant.This argument and the <sourceLinesToLog> argument specifies that only the parts of the schema defined by these arguments should be logged, otherwise the complete schema would be logged when logging is enabled.This argument can be set to NULL meaning that the part of the schema defined in the <sourceLinesToLog> argument should always be logged.
6STRINGsourceLinesToLog 
7STRINGlogFileSpecifies the name of the file that will hold the log information. This file can be an existing file or the name of a file that will be created by the conversion process. Default file extension is ".log". This argument is only valid when the option [LOG_TO_FILE] is set.
8INTEGERmaxLogFileSizeSpecifies an integer value that is the maximum number of bytes the specified <logFile> can hold before the logFile is closed. Specifying the value 0 (zero) means that no size limit for the l<logFile> is defined. This argument is only effective when the <logFile> argument is specified and the [LOG_TO_FILE] option is set.
9STRINGuserOutputFileSpecifies the name of the file that will hold the log information. This file can be an existing file or the name of a file that will be created by the conversion process. Default file extension is ".log". This argument is only valid when the option [LOG_TO_FILE] is set.
10INTEGERoptionssee below
11INTEGERnumberOfUserParametersSpecifies the number of userPars the function supplies.
12GENERICuserPar(N)user parameters supplied to the current running process

Return Value


Error rendering macro 'excerpt-include' : User 'null' does not have permission to view the page 'US:_r_XPX_Return_Value'.

Options


OptionComment
XPXOptioncomment

 

Example


<Missing Example>

 

See also

Filter by label

There are no items with the selected labels at this time.

 

  • No labels