Core - Administration Guide : Data Sets

21 March 2016

1. Data Sets

Data sets allows an administrator to define complex data retrievals within XML format. This feature was initially developed for use in the report generator but due to its power and flexibility, the support for using data-sets has increased into most of the TVC Components nowadays.

A data set can either be a structure consisting of objects and connections or a "flat" list of objects (each row in a flat list can also be associated with a connection).

A data set can typically be used to load data in several places across the TVC components. Some examples of use are:

  • Loading data into a Structure Browser

  • Loading data into a Grid Browser

  • Loading data within the image flow

  • Loading data into a chart / dashboard.

  • Loading data into a Report

A data set is defined in XML and is stored as a "resource" below the /WEB-INF/tvc folder within the ENOVIA web-application. The type of this resource is called "dataset". Below is a table showing some examples of the paths and their corresponding resource name to a particular data set.

File System Path (Relative from the root dir of your application) Resource Name

/WEB-INF/tvc/dataset/MyDataSet.xml

tvc:dataset/MyDataSet.xml

/WEB-INF/tvc/tvx/enc/dataset/MyDataSet.xml

tvc:dataset:tvx:enc/MyDataSet.xml

/WEB-INF/tvc/dataset/test/MyDataSet.xml

tvc:dataset/test/MyDataSet.xml

/WEB-INF/tvc/tvx/enc/dataset/test/MyDataSet.xml

tvc.dataset:tvx:enc/test/MyDataSet.xml

1.1. XML Format

The root element of the XML data structure is <DataSet>.

Below the root element, you will declare a so called loader.

There exist a number of different loaders, some of them require "input", which either comes from the "caller" such as object-ids provided in request parameters or from a "child" loader, while some loaders doesn’t require input.

The table below describes the built-in loaders together with a short description and reference to the chapter where they are described in more detail.

Loader XML Element Description Requires Input

Expand

<Expand>

Performs an expansion. The way the expansion is done, is configured through child elements.

Yes

Inquiry

<Inquiry>

Executes an inquiry. Either the inquiry is defined "inline" in the XML, or you reference an existing inquiry.

No

Query

<Query>

Performs a temp query. The query parameters are configured as child elements.

No

Java Program Object

<JPO>

Executes a Java Program Object.

No

Select

<Select>

Performs a "select" to retrieve the desired objects.

Yes

Flatten

<Flatten>

Converts a structure into a flat list. E.g. removes all hierarchy information

Yes

End Items

<EndItems>

Removes all nodes except the leafs from a structure.

Yes

Remove Duplicate Objects

<RemoveDuplicates>

Ensures that each object only appears once.

Yes

Filter

<Filter>

Performs a filtering of the rows based upon an expression.

Yes

Java

<Java>

Defines a loader implemented in Java

No

Source

<Source>

Explicitly obtains the objects provided by the client; typically the values either from the "emxTableRowId" parameter or the "objectId" parameter.

No

PersonObject

<PersonObject>

Gives the object-id of the person object associated with the current user.

No

CompanyObject

<CompanyObject>

Gives the object-id of the company object associated with the current user.

No

RemoveRoots

<RemoveRoots>

Removes the root nodes from a structure.

Yes

DataSetRef

<DataSetRef>

Includes the content from another data-set

No

Structure

<Structure>

Converts a flat list of objects into a structure, where the root nodes of the structure originate from the rows in the flat list.

Yes

Union

<Union>

Combines the result from several loaders into one flat list OR one structure.

Yes

Intersection

<Intersection>

Takes the id’s that are present in all child loaders.

Yes

Complement

<Complement>

Loads data from one or more child loaders, and exclude data by defining other child loaders that defines what to exclude.

Yes

DoPrivileged

<DoProvileged>

Runs the child loaders with system privileges

Yes

LatestInState

<LatestInState>

Finds the latest revision of the object in a particular state.

Yes

ExaleadQuery

<ExaleadQuery>

Performs a query against Exalead. The query parameters are configured as child elements.

No

SecurityContext

<SecurityContext>

Obtains the security context for the current user

No

ConditionallyInclude

<ConditionallyInclude>

Conditionally includes the child loader based upon the presence or non-presence of a parameter

Yes

PathQuery

<PathQuery>

Performs a query on path. The path query parameters are configured as child elements.

No

Label

<Label>

Label for dataset.

No

1.1.1. Nesting of Loaders

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:

<DataSet>
    <RemoveDuplicates>(5)
        <Filter usesBusinessObject="true">(4)
            <Expression>attribute[Unit of Measure] == kg</Expression>
            <EndItems>(3)
                <Expand>(2)
                    <Inquiry>(1)
                        <Name>tvc:inquiry/MyInquiry</Name>
                    </Inquiry>
                </Expand>
            </EndItems>
        </Filter>
    </RemoveDuplicates>
</DataSet>

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

What this example actually does is:

1 Use an inquiry to load some objects
2 The objects loaded from the inquiry is expanded according to the Expand definition
3 All rows except the end items within the structure is removed
4 A filter is applied to the objects, which will remove all objects that doesn’t fulfil the filter-expression
5 Finally, all objects appearing more than once are removed.

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.

1.1.2. Expansion

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

<DataSet>
    <Expand>
        <From>true</From>
        <To>false</To>
        <Depth>1</Depth>
        <TypePattern>
            <Type>type_Part</Type>
            <Type>...</Type>
        </TypePattern>
        <RelationshipPattern>
            <Relationship>relationship_SparePart</Relationship>
            <Relationship>...</Relationship>
        </RelationshipPattern>
        <ObjectWhere>...expression...</ObjectWhere>
        <RelWhere>...expression...</RelWhere>
        <LoadRootInquiry>name of inquiry that provides the root objects</LoadRootInquiry>
    </Expand>
</DataSet>

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

The "LoadRootInquiry" element can be used to specify an inquiry that loads the root nodes. This would be the same as doing: 
<Expand>
    <Inquiry>
        <Name>name of inquiry</Name>
    </Inquiry>
</Expand>

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

1.1.3. Inquiry

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.

<Inquiry>
    <Name>name of inquiry to run</Name>
</Inquiry>

Alternatively, you can also say:

<Inquiry name="name of inquiry"/>

Or by defining the inquiry inline:

<Inquiry>
    <Code>temp query bus Part * * limit 100</Code>
    <Pattern>*|*|*|${OID}</Pattern>
    <Format>${OID}</Format>
</Inquiry>

1.1.4. Query

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

<Query>
    <ExpandType>true</ExpandType> <!-- whether or not to find sub-types -->
    <FindLimit>0</FindLimit> <!-- the find limit -->
    <TypePattern>
        <Type>type_Part</Type>
        <Type>type_AnotherType</Type>
    </TypePattern>
    <NamePattern>
        <Name>A*</Name>
        <Name>B*</Name>
    </NamePattern>
    <RevisionPattern>
        <Revision>A</Revision>
        <Revision>B</Revision>
        <Revision>C</Revision>
    </RevisionPattern>
    <OwnerPattern>
        <Owner>A user</Owner>
    </OwnerPattern>
    <VaultPattern>
        <Vault>A vault</Vault>
        <Vault>Another vault</Vault>
    </VaultPattern>
    <Where>$&lt;attribute[attribute_Weight]&lt; &gt; 100</Where>
</Query>

1.1.5. JPO

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

<JPO>
    <Name>MyJPO</Name>
    <Method>myMethod</Method>
</JPO>

Alternatively, you can also say:

<JPO name="MyJPO" method="myMethod"/>

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

1.1.6. Select

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

<Select>
    <Statement>from[Documents].to.revisions.id</Statement>
    <Statement>from[Specs].to.revisions.id</Statement>
</Select>

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:

<Select selectFromConnections="true">
    <Statement>to.id</Statement>
</Select>

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

<Select selectReturnsConnections="true">
    <Statement>to.id</Statement>
</Select>

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

<Select statement="from[Documents].to.id"/>

1.1.7. Flatten

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:

<Flatten>
    <Expand>
    ...
    </Expand>
</Flatten>

1.1.8. End Items / Leafs

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:

<EndItems>
    <Expand>
    ...
    </Expand>
</EndItems>

1.1.9. Remove Duplicates

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:

<RemoveDuplicates>
    <EndItems>
        <Expand>
            ...
        </Expand>
    </EndItems>
</RemoveDuplicates>

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

<RemoveDuplicates ignoreConnectId="false">
    <EndItems>
        <Expand>
            ...
        </Expand>
    </EndItems>
</RemoveDuplicates>

1.1.10. Filter

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.

<Filter>
    <Expression>$&lt;attribute[attribute_Classification]&gt; == ABC</Expression>
    <Flatten>
        <Expand>
            ...
        </Expand>
    </Flatten>
</Filter>

Alternatively, you can also say:

<Filter expression="$&lt;attribute[attribute_ABC]&gt; == 'DEF'"/>

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:

<Expression>attribute[Attribute 1] == Value1 || attribute[Attribute 2] == Value2</Expression>

Might need to be rewritten as shown below:

<Expression>attribute[Attribute 1] == Value1 *OR* attribute[Attribute 2] == Value2</Expression>

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

To verify your expressions, you can from MQL do:

<MQL> pri bus T N R select evaluate[attribute[Attribute 1] == Value1];

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:

<Filter usesBusinessObject="false" ...>

1.1.11. Java

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

<Java className="com.acme.MyDataLoader"/>

The class specified must implement one of the interfaces below:

  • com.technia.tvc.core.db.dataset.loader.DataLoader

  • com.technia.tvc.core.db.dataset.loader.DataLoaderWithInput

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

1.1.12. Source

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:

<Filter>
    <Expression>...</Expression>
    <Source/>
</Filter>

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.

<Source useParameter="parentOID"/>

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.

<Source checkPhysicalId="true"/>

1.1.13. Person Object

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:

<EndItems>
    <Expand>
        ...
        <PersonObject/>
    </Expand>
</EndItems>

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

1.1.14. Company Object

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:

<EndItems>
    <Expand>
        ...
        <CompanyObject/>
    </Expand>
</EndItems>

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

1.1.15. Remove Roots

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

<RemoveRoots>
    <Expand>
        ...
    </Expand>
</RemoveRoots>

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

1.1.16. Dataset Reference

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

<DataSetRef name="tvc:dataset/MyDataSet.xml">

1.1.17. Structure

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:

Attribute Description

ignoreRelIds

A Boolean specifying if to exclude any relationship information as provided by the child loader.

Default is false.

Example:

<Structure ignoreRelIds="false">
    <Query>
        ...
    </Query>
</Structure>

1.1.18. Union

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

<DataSet>
    <Union>
        <DataSetRef name="tvc:dataset/Example.xml"/>
        <Query>
            <TypePattern>
                <Type>type_SomeType</Type>
            </TypePattern>
            <FindLimit>10</FindLimit>
            <Where>current == Obsolete</Where>
        </Query>
        <Query>
            <TypePattern>
                <Type>type_AnotherType</Type>
            </TypePattern>
            <FindLimit>10</FindLimit>
            <Where>current == Create</Where>
        </Query>
        <Query>
            <TypePattern>
                <Type>type_ThirdType</Type>
            </TypePattern>
            <Where>current == Release</Where>
            <FindLimit>10</FindLimit>
        </Query>
    </Union>
</DataSet>

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.

<DataSet>
    <Union forceFlat="true">

1.1.19. Intersection

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

<DataSet>
    <Intersection>
        <DataSetRef name="tvc:dataset/First.xml"/>
        <DataSetRef name="tvc:dataset/Second.xml"/>
    </Intersection>
</DataSet>

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:

<DataSet>
    <Intersection useRelationship="true">

1.1.20. Complement

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.

<Complement>
    <Include>
        <Query>
            <TypePattern>
                <Type>type_Person</Type>
            </TypePattern>
        </Query>
    </Include>
    <Exclude>
        <PersonObject/>
    </Exclude>
</Complement>

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

1.1.21. DoPrivileged

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:

<DataSet>
    <DoPrivileged>
        <Query>
            ...
        </Query>
    </DoPrivileged>
</DataSet>

1.1.22. Latest in State

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:

<DataSet>
    <LatestInState>
        <State>Released</State> (1)
        <Query>
            <TypePattern>
                <Type>Part</Type>
            </TypePattern>
            ...
        </Query>
    </LatestInState>
</DataSet>
1 State definition

1.1.23. Exalead

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

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

  • The field which defines what to search on. The field name must match the exact name in the config.xml for Exalead.

  • The operator to use. The equal operator is used by default.

  • The value to search.

Criterion example:

<Criterion field="TYPES" operator="equal">Part</Criterion>

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.

<DataSet>
    <ExaleadQuery>
        <PageSize>1000</PageSize>
        <Criteria>
            <Criterion field="TYPE">Part</Criterion>
            <Criterion field="SPARE_PART">true</Criterion>
            <Criterion field="CURRENT" operator="in">
                <Value>Review</Value>
                <Value>Released</Value>
            </Criterion>
            <Criterion field="ORIGINATED" operator="between">
                <From>2015-01-01 00:00:00 AM</From>
                <To>2016-01-01 00:00:00 AM</To>
            </Criterion>
            <Criterion field="OWNER">Test Everything</Criterion>
            <Criterion field="DESCRIPTION">*ohm</Criterion>
        </Criteria>
    </ExaleadQuery>
</DataSet>

Operators:

Name Description

equal

The objects value must equals the searched value. Supports wild card searches to match parts of the value. This is the default operator.

not-equal

The objects values must not equal the searched value.

greater-than

The objects value must be greater than the searched value.

less-than

The objects value must be less than the searched value.

between

The objects value must be in a range. Use sub element <From> and <To> to specify the range.

in

The objects value must be any of the specified values. Use <Value> to specify the values.

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

Dates

The date to search on needs to:

  • Follow the configured format in ENOVIA

  • Include both date and time

Examples:

8/1/2016 10:00:00 AM
8/31/2016 11:59:59 PM
Searching for only the date (without the time) works for some fields, but not all. The time is by default set to midnight making the search result sometimes unpredictable from a user perspective.

1.1.24. Security Context

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

Example:

<DataSet>
    <SecurityContext project="true" organization="false" />
</DataSet>

1.1.25. Conditionally Inclusion

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:

<DataSet>
    <ConditionallyInclude if="param1">
          <Query ...>
          </Query>
    </ConditionallyInclude>
    <ConditionallyInclude unless="param1">
        <Expand ...>
          ...
        </Expand>
    </ConditionallyInclude>
</DataSet>
There is an additional attribute called trimWhitespace, which if set to true will treat empty parameter values as null/not-present. The default value for this parameter is true. Example below: 
    <ConditionallyInclude if="param1" trimWhitespace="false">
    ...
    </ConditionallyInclude>

1.1.26. Path Query

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

<PathQuery>
    <PathType>Proposed Activity.Where</PathType>
    <PathSelect>owner.to[Proposed Activities].from.to[Change Action].from.id</PathSelect>
    <Query>
        <TypePattern>
            <Type>type_Part</Type>
        </TypePattern>
        <Where>owner==context.user AND current=='In Work'</Where>
    </Query>
    <!--<ElementInquiry>PartQuery</ElementInquiry>-->
</PathQuery>

Settings:

Name Description Default

PathType

Type of Path to search for

PathSelect

expression to get the respective id

id

QueryKind

how the query will operate on subpath

containsany

vault

Vault to search for

where

Where clause to use

ElementInquiry

name of the inquiry to the elements for query

1.2. Parametrization

As of TVC 2015.3.0, support for parameterize values in a data set has been added. This feature can be used to let end users affect the result of a dataset, for example specify different type pattern in a query or change something in a where expression. Depending on how the data-set is being used, these parameters are resolved differently but typically in the web-environment these parameters originates from a request parameter.

By default, all data-sets are allowed to be parameterized. This behavior can be changed via a so called TVC init parameter. The name of this parameter is shown below and its default value is "TRUE".

tvc.core.dataSet.defaultParameterizable

The support for parametrization can be defined on a per-dataset basis also. See example below how to configure it.

<DataSet parameterizable="true | false">

The default value is controlled via the global parameter.

1.2.1. Parameter Syntax

The syntax of a parameter is:

$(paramName,options)

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:

Option Description Example

type

Specifies the datatype of the value. Supported types are:

  • string (default)

  • boolean

  • integer

  • number

  • date

  • type (ENOVIA object type)

  • relationship (ENOVIA relationship type)

Note 1: date is used to convert a ISO8601 date to a ENOVIA date

Node 2: The type value accepts symbolic names

type=integer

default

Specifies the default value to be used if omitted or value is empty and empty is "false"

default=type_Part

derivedFrom

If type is either type or relationship, this option may be used to specify that the value must represent a type that is derived from this type.

type=type,derivedFrom=type_ECO

empty

Defines if the empty string is allowed or not. Default is FALSE.

empty=true

multiple

Defines if multiple values are allowed. Default is FALSE

multiple=true

separator

If multiple values are allowed and there are multiple values present, these values are concatenated with a separator string. Default value is the comma character.

multiple=true,separator=

escape

If set to true, the resolved value will be searched for MQL sensitive chars to be escaped. The chars that are escaped are quote, double-quote and back-slash characters. Default is false.

escape=true

min

For integers or numbers: provided value must not be lower than min value

For strings: Length of string must be longer or equal to min.

min=1

max

For integers or numbers: provided value must not be greater than the max value.

For strings: Length of string must be shorter or equal as the max value.

max=5

allowWildcard

If set to true and type is string, the input string is considered invalid if it contains either a ? or * character.

1.2.2. Examples

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

Example where the expand properties are parameterized.

<DataSet parameterizable="true">
    <Expand>
        <From>$(param.expandFrom,type=boolean,default=false)</From>
        <To>$(param.expandTo,type=boolean,default=false)</To>
        <Depth>$(param.depth,type=int,default=3)</Depth>
        <TypePattern>
            <Type>$(param.type,multiple=true,default=type_Part,type=type,derivedFrom=type_Part)</Type>
        </TypePattern>
        <RelationshipPattern>
            <Relationship>$(param.rel,multiple=true,default=relationship_EBOM)</Relationship>
        </RelationshipPattern>
    </Expand>
</DataSet>

Another example using an inquiry.

<DataSet parameterizable="true">
    <Inquiry>
        <Code>temp query bus "$(typePattern,default=*,multiple=true)" * * limit 100 select id dump |</Code>
        <Pattern>*|*|*|${OID}</Pattern>
        <Format>${OID}</Format>
    </Inquiry>
</DataSet>

1.2.3. Support for Parametrization

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

Element Property

<DataSetRef>

Referenced data-set

<Expand>

  • Expand Depth

  • Relationship Pattern

  • Type Pattern

  • To

  • From

  • Relationship Where Clause

  • Object Where Clause

<Filter>

Filter expression

<Inquiry>

  • Inquiry reference

  • Code

  • Format

  • Pattern

  • Split-By

<JPO>

  • Program Name

  • Method Name

<LatestInState>

State value

<MQL>

Code

<Query>

  • Expand type or not

  • Type Pattern

  • Name Pattern

  • Revision Pattern

  • Owner Pattern

  • Vault Pattern

  • Where Expression

  • Find Limit

<ExaleadQuery>

  • Page Size

  • Criterion Values

1.2.4. Escaping

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:

<DataSet>
    <MQL>
    <Code>\$(something)</Code>

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

  • Presence of $(

  • Use of backslash