Home > Models

Tables, Filters and Selection Nodes

webMethods MDM supports the features of relational-databases tables with a high volume of records and primary key identification.

Table Definition

An element declaration with maxOccurs > 1 is declared as a table by adding the following annotation:

 <xs:annotation> 

               <xs:appinfo> 

                   <mdm:table> 

                       <primaryKeys>/pathToRub1 /pathToRub...n</primaryKeys> 

                   </mdm:table> 

               </xs:appinfo> 

           </xs:annotation>

A table record may be of various types:

A root record has no parent (hence it cannot inherit any of its values from another record).
An overwriting record may inherit any of its values from a parent record. Its parent has the same primary key and it is looked up in the parent table (recursively, up to the root instance).
An occulting record specifies that if a parent with same primary key is defined, this parent won't be seen in table descendants.
A deriving record inherits its values from a parent that has not the same primary key.

Notes :

1. Deriving records is an advanced concept whose implications may be difficult to understand for a Manager user. So we do not advise to activate it (see table below).

2. A specific whitespaces management has been defined for primary keys of type xs:string.

Element	Description	Required
`primaryKeys`	the primary keys of the table. Each element in primary key is denoted by its absolute XPath notation that starts just under the table root element. If there are several elements in the primary key, the list is white-space delimited.	Yes.
`mayCreateRoot`	expression that specifies when a root record may be created.	No, default is "always".
`mayCreateOverwriting`	expression that specifies when an overwriting record may be created.	No, default is "always".
`mayCreateOcculting`	expression that specifies when an occulting record may be created.	No, default is "always".
`mayCreateDeriving`	expression that specifies when a deriving record may be created.	No, default is "never".
`mayDuplicate`	expression that specifies when a record may be duplicated.	No, default is "always".
`mayDelete`	expression that specifies when a record may be deleted.	No, default is "always".

The may... expressions specify when the action is possible, however the user access rights may restrict this possibility independently. The expressions have the following syntax:

expression ::= always | never | <condition>*
condition ::= [root:yes | root:no]
condition ::= [agreement:yes | agreement:no]
condition ::= [agreementAscendant:yes | agreementAscendant:no]
"always" : the creation is "always" possible (but user rights may restrict this).
"never" : the creation is never possible.
"root:yes" : the creation is possible if the record is in a root instance.
"root:no" : the creation is not possible if the record is in a root instance.
"agreement:yes" : the creation is possible if the record is in a agreement instance.
"agreement:no" : the creation is not possible if the record is in an agreement instance.
"agreementAscendant:yes" : the creation is possible if the record is in a agreement descendant instance.
"agreementAscendant:no" : the creation is not possible if the record is in a agreement descendant instance.

If the record does not verify any condition, then default is taken.

Below is an example of a product catalog as a table:

<xs:element name="product" minOccurs="0" maxOccurs="unbounded"> 

               <xs:annotation> 

                   <xs:documentation> 

                       <mdm:label>Product Table </mdm:label> 

                       <mdm:description>List of products in Catalog </mdm:description> 

                   </xs:documentation> 

               </xs:annotation> 

               <xs:complexType> 

               <xs:annotation> 

                   <xs:appinfo> 

                       <mdm:table> 

                           <primaryKeys>/productRange /productCode</primaryKeys> 

                       </mdm:table> 

                   </xs:appinfo> 

               </xs:annotation> 

                   <xs:sequence> 

                       <xs:element name="productRange" type="xs:string"/><!-- key --> 

                       <xs:element name="productCode" type="xs:string"/><!-- key --> 

                       <xs:element name="productLabel" type="xs:string"/> 

                       <xs:element name="productDescription" type="xs:string"/> 

                       <xs:element name="productWeight" type="xs:int"/> 

                   </xs:sequence> 

               </xs:complexType> 

          </xs:element>

Constraints on table (primary key reference) are defined in schema using extended facets.

Tables have a dedicated editor in webMethods Master Data Manager:

Specifying Filters on a Table

By default, tables present all occurrences in webMethods Master Data Manager. However, the user has the ability to add filters and display only the occurrences corresponding to given criteria.

In order to do that, you must follow the steps below:

Define the filter in the schema
Implement the class in charge of the filtering, that extends com.softwareag.mdm.ui.UITableFilter

As a result, a filter option will appear in the user screen, given the opportunity to refine your search.

An implementation example can be found in the following Tutorial.

Selection Nodes

An element declaration may define a dynamic and contextual XPath selection. In this case Manager User Interface provides a link so that the user can navigate to the pre-filtered table that corresponds to the selection.

A selection node is useful for materializing an association between two entities, in GUI and also for validation purpose. For example, the Tutorial library schema specifies that a book is written by an author (this is made explicit by a foreign key in 'Book' complex type definition). The opposite relation (that an author has written some books) cannot be expressed easily in XML Schema, unless we define the following selection node in the 'Author' complex type definition:

<xs:element name="linkToAuthorTitles" minOccurs="0" maxOccurs="0" > 

                 <xs:annotation> 

                   <xs:appinfo> 

                     <mdm:select> 

                       <minOccurs>1</minOccurs> 

              <xpath>/root/Titles[au_id =${../au_id}]</xpath> 

                     </mdm:select> 

                   </xs:appinfo> 

                 </xs:annotation> 

         </xs:element>

The element minOccurs specifies that, for being valid, an author must have written at least one book.

Note: the "official" cardinality constraints (minOccurs="0" maxOccurs="0") are required because from an external XML point of view (that is, an instance of XML Schema), the corresponding node is absent. In other words, a selection node is a "virtual" element regarding XML and XML Schema.

Element Description Required

xpath

Specifies the selection to perform relatively to the current node.

Examples : /root/Titles[au_id =${../au_id}] or //Titles[au_id =${../au_id}] or ../Titles[au_id =${../au_id}].

The path up to the predicate (for example ../Titles) specifies the target table to filter. This part of the path is resolved relatively to the current table root.

If the selection depends on the local state, the XPath expression predicate must include references to the node it depends on with this notation:

${ <relative-path> }

where relative-path is a path that locates the element relatively to the node that holds the selection link.

For XPath syntax, see webMethods Master Data Manager XPath supported syntax.

Yes.

minOccurs Specifies an additional validation constraint : the selection must be at least of the size specified. No, default is 0.

Thus by double-clicking on 'Franck Herbert' 'on this Author table in webMethods Master Data Manager:

And by selecting the [linkToAuthorTitles]:

One can navigate to the filtered view of the author titles:

Tables, filtres et noeuds de sélection

webMethods MDM supporte les caractéristiques des tables de bases de données relationelles en terme de volume élevé d'occurrences et d'identification par clé primaire.

Définition de table

La déclaration d'un élément dont l'attribut maxOccurs est supérieur à 1 est déclaré en tant que table en ajoutant l'annotation qui suit :

 <xs:annotation> 

               <xs:appinfo> 

                   <mdm:table> 

                       <primaryKeys>/pathToRub1 /pathToRub...n</primaryKeys> 

                   </mdm:table> 

               </xs:appinfo> 

           </xs:annotation>

Une occurrence de table est d'un des types suivants :

Une occurrence racine n'a pas de parent, c'est à dire qu'elle ne peut pas hériter ses valeurs d'une autre occurrence (uniquement des éventuelles valeurs par défaut du schéma).
Une occurrence de surcharge hérite ses valeurs d'un parent qui a la même clé primaire. Ce parent est toujours dans la table parent (la recherche est récursive, jusqu'à l'instance racine).
Une occurrence d'occultation spécifie que si un parent de même clé primaire est défini, ce parent ne sera pas vu dans les tables descendantes.
Une occurrence de dérivation hérite d'un parent qui n'a pas la même clé primaire.

Notes :

1. Les occurrences de dérivation sont un concept avancé, dont les implications peuvent être difficiles à maîtriser pour un utilisateur du Manager. En conséquence, nous préconisons de ne pas l'activer (voir ci-dessous).

2. Une gestion spécifique des espaces a été définie pour les clés primaires de type xs:string.

Element	Description	Requis
`primaryKeys`	Définit les clés primaires de la table. Chaque champ de la clé est dénoté au moyen de la notation XPath d'un chemin absolu qui débute juste sous l'élément racine de la table. Si la clé est composite, la liste des champs doit être séparée par des espaces.	Oui.
`mayCreateRoot`	Expression qui spécifie sous quelles conditions il est possible de créer une occurrence racine. L'expression doit suivre la syntaxe ci-dessous.	Non, par defaut est "always".
`mayCreateOverwriting`	Expression qui spécifie sous quelles conditions il est possible de créer une occurrence de surcharge. L'expression doit suivre la syntaxe ci-dessous.	Non, par defaut est "always".
`mayCreateOcculting`	Expression qui spécifie sous quelles conditions il est possible de créer une occurrence d'occultation. L'expression doit suivre la syntaxe ci-dessous.	Non, par defaut est "always".
`mayCreateDeriving`	Expression qui spécifie sous quelles conditions il est possible de créer une occurrence de dérivation. L'expression doit suivre la syntaxe ci-dessous.	Non, par defaut est "never".
`mayDuplicate`	Expression qui spécifie sous quelles conditions il est possible de dupliquer une occurrence. L'expression doit suivre la syntaxe ci-dessous.	Non, par defaut est "always".
`mayDelete`	Expression qui spécifie sous quelles conditions il est possible de supprimer une occurrence. L'expression doit suivre la syntaxe ci-dessous.	Non, par defaut est "always".

Les expressions may... définissent sous quelles conditions l'action est possible. Cependant, les droits d'accès peuvent restreindre ces conditions de manière indépendante. Les expressions ont la syntaxe suivante :

expression ::= always | never | <condition>*
condition ::= [root:yes | root:no]
condition ::= [agreement:yes | agreement:no]
condition ::= [agreementAscendant:yes | agreementAscendant:no]
"always" : la création est toujours possible (mais les droits d'accès peuvent restreindre cela).
"never" : la création n'est jamais possible.
"root:yes" : la création est possible si l'occurrence est dans une instance racine.
"root:no" : la création n'est pas possible si l'occurrence est dans une instance racine.
"agreement:yes" : la création est possible si l'occurrence est dans une instance de type accord.
"agreement:no" : la création n'est pas possible si l'occurrence est dans une instance de type accord.
"agreementAscendant:yes" : la création est possible si l'occurrence est dans une instance descendante d'un accord.
"agreementAscendant:no" : la création n'est pas possible si l'occurrence est dans une instance descendante d'un accord.

Si l'occurrence ne vérifie aucune des conditions spécifiées dans l'expression, la valeur par défaut est adoptée.

Ci-dessous figure un exemple de table produit dans un catalogue.

<xs:element name="product" minOccurs="0" maxOccurs="unbounded""> 

               <xs:annotation> 

                   <xs:documentation> 

                       <mdm:label>Product Table </mdm:label> 

                       <mdm:description>List of products in Catalog </mdm:description> 

                   </xs:documentation> 

               </xs:annotation> 

               <xs:complexType> 

               <xs:annotation> 

                   <xs:appinfo> 

                       <mdm:table> 

                           <primaryKeys>/productRange /productCode</primaryKeys> 

                       </mdm:table> 

                   </xs:appinfo> 

               </xs:annotation> 

                   <xs:sequence> 

                       <xs:element name="productRange" type="xs:string"/><!-- key --> 

                       <xs:element name="productCode" type="xs:string"/><!-- key --> 

                       <xs:element name="productLabel" type="xs:string"/> 

                       <xs:element name="productDescription" type="xs:string"/> 

                       <xs:element name="productWeight" type="xs:int"/> 

                   </xs:sequence> 

               </xs:complexType> 

          </xs:element>

Les contraintes sur clé primaire de table sont définies au moyen des facettes étendues.

Les tables disposent dans webMethods Master Data Manager d'un éditeur dédié:

Spécifier des filtres sur une table

Par défaut, les tables affichent toutes leurs occurrences dans webMethods Master Data Manager. Cependant, l'utilisateur a la possibilité d'ajouter des filtres et d'afficher seulement les occurrences correspondant à des critères donnés.

Pour ce faire, vous devez suivre les étapes suivantes :

Définir le filtre dans le schéma
Implémenter la classe en charge du filtre, qui étend com.softwareag.mdm.ui.UITableFilter

En résultat, nous obtenons un bouton qui apparaît à l'écran, qui donne la possibilité à l'utilisateur de filtrer sa recherche.

Un exemple d'implementation est présent dans la partie Tutoriel.

Noeud de sélection

Une déclaration d'élément peut définir une sélection XPath dynamique et contextuelle. Dans ce cas, l'interface utilisateur du Manager propose un lien de navigation qui permet d'accéder à une vue filtrée ou non.

Un noeud de sélection est entre autres utile pour matérialiser une association entre deux entités, d'une part dans l'interface utilisateur mais aussi potentiellement à des fins de validation. Par exemple, le schéma du tutoriel "bibliothèque" spécifie qu'un livre est écrit par un auteur (ce qui est rendu explicite au moyen d'une clé étrangère dans la définition du type complexe 'Book'). La relation inverse (un auteur a écrit certains livres) ne peut pas être exprimée facilement en schéma XML, sauf en insérant le noeud de sélection suivant dans la définition du type complexe 'Author' :

<xs:element name="linkToAuthorTitles" minOccurs="0" maxOccurs="0" > 

                 <xs:annotation> 

                   <xs:appinfo> 

                     <mdm:select> 

                       <minOccurs>1</minOccurs> 

              <xpath>/root/Titles[au_id =${../au_id}]</xpath> 

                     </mdm:select> 

                   </xs:appinfo> 

                 </xs:annotation> 

         </xs:element>

L'élément minOccurs précise que pour être valide un auteur doit avoir écrit au moins un livre.

A noter que nous devons conserver les contraintes de cardinalité "officielles" du noeud (minOccurs="0" maxOccurs="0") : elles sont nécessaires car d'un point de vue XML externe (document instance du schéma XML), le noeud n'a aucune occurrence. Autrement dit, un noeud de sélection est un élément "virtuel" vis à vis de XML et XML Schema.

Element Description Required

xpath

Specifies the selection to perform relatively to the current node.

Examples : /root/Titles[au_id =${../au_id}] or //Titles[au_id =${../au_id}] or ../Titles[au_id =${../au_id}].

Le chemin jusqu'au prédicat (par exemple ../Titles) spécifie la table cible à filtrer. Cette partie du chemin est résolue relativement à la racine de la table contenant.

Si la sélection dépend de l'état de l'occurrence à laquelle la sélection est attachée, les expressions primaires du prédicat feront référence aux valeurs de l'occurrence locale en utilisant la notation :

${ <relative-path> }

où relative-path est un chemin qui localise l'élément relativement au noeud qui détient le lien de sélection.

Pour la syntaxe XPath, voir : webMethods Master Data Manager XPath supported syntax.

Yes.

minOccurs Specifies an additional validation constraint : the selection must be at least of the size specified. No, default is 0.

A l'aide de cette sélection, si on double-clique sur 'Franck Herbert' ' dans la table des Auteurs ci-dessous :

on obtient le lien [linkToAuthorTitles] ci-après dans le formulaire de l'auteur sélectionné et si on sélectionne ce lien,

on est redirigé sur la vue filtrée des titres de cet auteur :

Home > Models

Copyright © Software AG 2000-2007. All rights reserved.
Trademarks and brand names referred to in this web site relating to organizations
other than Software AG are the property of those organizations
and Software AG makes no claims to such property.