Core - Administration Guide : Data Sets

A loader might require input, while some don’t. The loaders that requires input can either use input from a loader defined as a child element OR it can use the input as provided by the caller (typically from request parameters such as "emxTableRowIdParam" passed from selected rows in a table/structure page OR the "objectId" parameter that also is used to pass the id of one or more objects).

Below is an example how to "nest" the loaders:

Note that this example is not complete; some configuration details has been left out for readability purpose.

What this example actually does is:

This illustrates how to accomplish a quite complex data-retrieval just by using a combination of different loaders. If you would have implemented this code as for example a JPO, you would typically need to implement +100 rows of Java code.

A complete definition how to expand a structure is shown below. Note that some elements are optional.

Setting the depth to 0, you will expand as deep as possible. This can only be done in one direction.

The difference is that the first approach will execute slightly more efficient.

Executing an inquiry can be done in two different ways. Either you will reference an existing inquiry by its name, or you can define the inquiry inline. Below are two examples illustrating both ways.

Alternatively, you can also say:

Or by defining the inquiry inline:

A complete definition how to perform a query is shown below. Note that some elements are optional.

The JPO loader can be used to invoke a JPO. The example below illustrates how to configure such loader.

Alternatively, you can also say:

The JPO method must return a MapList where each Map in the list contains the "id" and optionally the "id[connection]" key.

The select loader selects id’s based upon the input to the select loader. Below is an example how to do so:

By default, the select loader assumes that you select on business objects, and the select returns other business object id’s. If you select on relationships, or your select clause returns connection id’s, see below for details.

Note 1: In this case, the select is done upon the implicit input objects as provided by the client. You can use a child-loader also; in that case, the select is based upon the objects provided by that loader.

Note 2: it is possible to have several statements. Each statement must of course return object-ids.

If you have select statements that operates on connection id’s; then you can specify so as shown below:

If your select statement would return connection id’s instead of object id’s, then you can specify so as shown below:

If you only have one select statement, this can be written as:

The flatten loader doesn’t have any configuration options. The only requirement is that the input to this loader is a structure; if not, nothing will be done by this loader.

Example:

The end items loader doesn’t have any configuration options. The only requirement is that the input to this loader is a structure; if not, nothing will be done by this loader.

Example:

The remove duplicates loader requires input, either a structure or a flat list. In case of a structure, the removal of duplicates is only made on the root-nodes in the structure.

Example:

If you need to retain occurrences of the same object if the connection id differs, specify so using the attribute "ignoreConnectId" as shown below:

The filter loader can be used to filter out objects based upon an expression. This loader requires input. The example below expands a structure, makes it flat, then applies the filter and removes all the rows not matching this filter.

Alternatively, you can also say:

NOTE 1: The expression is evaluated using the ENOVIA select statement "evaluate[${EXPRESSION}]". All rows returning TRUE will be accepted, others will be filtered out.

NOTE 2: If you need to combine criteria using AND/OR operators; you might in some cases need to use the AND or OR key words instead of using the && and || operators. This is due to a bug/behaviour of ENOVIA.

For example the expression shown below:

Might need to be rewritten as shown below:

E.g. the operators || and && could be changed to OR and AND.

To verify your expressions, you can from MQL do:

NOTE 3: If your expression should be evaluated against the connections instead of over the business objects, which is the default, then you can say so as shown below:

To use a custom loader within a data-set that is implemented in Java, this can be done through the example below:

The class specified must implement one of the interfaces below:

If your custom Java class supports load by a child loader, you need to implement the DataLoaderWithInput interface.

The source objects as provided by the client through for example request parameters will be used by the data-loaders that require input, but doesn’t have any input configured in the data-set XML file through any child loaders, implicitly.

To explicitly define that you will use the source objects, then you can define this in the Data set XML file like shown below:

If any other parameter needs to used in place of objectId then useParameter attribute could be used to pass the parameter name for source input.

In some use cases, physical id is used as input which would not give a proper result with the combination of other datasets such as Complement, Intersection, Union, etc…​ In such a scenario, checkPhysicalId attribute could be used with a boolean value to check the use of physical id and convert the source inputs into object ids and connection-ids.

The id of the person object associated with the current user can in some cases be useful to start from when for example expanding a structure. Below is an example how to use it:

This example will expand the person object and finally filter out all rows in the structure except for the "end items".

The id of the company object associated with the current user can in some cases be useful to start from when for example expanding a structure. Below is an example how to use it:

This example will expand the company object and finally filter out all rows in the structure except for the "end items".

In some cases when you have expanded a structure, you only want to remove the root nodes. This can be accomplished as shown below:

The "RemoveRoots" element doesn’t have any configuration options.

A dataset might use the outcome from another dataset. This can be accomplished as shown below:

In conjunction with the Flatten loader, which converts a structure into a flat list, you can use the Structure loader to convert a flat list into a structure.

Each row in the flat list used as input to this loader will be set as root node in the returned structure.

Note that if the input to this loader is a structure, no change is made.

You can configure this loader with some additional attributes:

Example:

To combine the result from several loaders, you can use the "Union" loader. This can be accomplished as shown below:

In this example, we combine the result from three queries and the result from a referenced data-set.

If any of the loaders contains structural data, the outcome of this loader becomes a structure.

To force flat list, you can use the attribute "forceFlat" on the <Union> element and set the value to true. E.g.

This loader will return the ID’s that are part of all child loaders. Example:

The result from the example below will contain the objects that are in both the results from the specified data-sets.

By default, this loader uses the object-id’s. However, you can configure it to use the relationship id’s instead. This is accomplished as shown below:

To exclude data from a loader, you can use the Complement-loader. It allows you to define nested loaders, which defines the maximum objects/connections to be included. From this maximum set, you can exclude objects/connections.

See the example below which queries the system for all Person objects, but excludes the one representing the current user.

Both the <Include> and <Exclude> elements accepts multiple loaders.

By default, any data loader within a data set is run with the same context (credentials) as the user who is logged in. In some cases, you might want to run a query as a super user in order to by-pass any access checks that are expensive to evaluate. To do so, you can accomplish this as shown below:

This loader is used to get only the latest revision of the object which is in the specific state. For example this can be used to only get the latest "Released" revision of a part. Example of this scenario:

Uses the criteria specified in the configuration to find the objects of interest.

The criteria consists of one or more criterions. Each criterion specifies:

Criterion example:

The search uses AND logical operator when combining the criterions. This means that objects must match every criterion in order to be considered a match.

A complete definition searching for Parts in state Review / Released, marked as spare part, originating from 2015 and so on.

Operators:

This loader requires that you have Exalead installed and that your data is correctly indexed.

To get the organization business object and/or project business object representing the current user’s security context, use this element.

Example:

Parameters are made available to a data-set in different ways depending on how it is being used and invoked.

One can based upon the presence or absence of a parameter, conditionally include the content from the child loader’s.

Example:

Search for Path objects using a path query.

Example: list all COs by Parts which are in work state and owned by logged in user

Settings:

The syntax of a parameter is:

Options is a comma separated list of options. An option consists of a key and value separated with the equals character. The available options are listed below:

Below are some examples of how the parameterized values can be used.

Example where the expand properties are parameterized.

Another example using an inquiry.

Most but not all configuration parameters within the DataSet XML definition allows specifying parametrization macros. The table below shows the supported places.

Since the DataSet’s now may contain special macro references using $() keywords, you may in rare situations need to escape such keywords if you don’t intend to resolve it as a macro.

Fortunately you can either disable parametrization completely on that particular DataSet or escape these sensitive characters using the backslash key.

For example:

Note that if you today are using backslashes, these are now treated as escape chars and hence you would need to escape the backslash also. So be aware of the following