Requêtes MDX de Notification Services
Le jeu de résultats d'une requête MDX (Multidimensional Expression) peut comporter plusieurs dimensions. Toutefois, ce fournisseur d'événements nécessite que ses requêtes MDX retournent un jeu de lignes plates, qui peut alors être envoyé en tant qu'ensemble d'événements à une application Notification Services.
La requête MDX doit renvoyer un jeu de résultats avec des colonnes qui correspondent aux champs de classe d'événements. La première colonne du résultat MDX doit correspondre au premier champ de classe d'événements, le deuxième résultat doit correspondre au deuxième champ de classe d'événements, etc.
Les requêtes MDX pour le fournisseur d'événements Analysis Services peuvent être statiques. Statique signifie que la requête complète est connue dès la création de l'application. Elles peuvent également être dynamiques. Dynamique signifie que les éléments de l'axe ROWS ou les éléments de l'axe de secteur MDX sont obtenus à l'aide de requêtes Transact-SQL. Les résultats de ces requêtes Transact-SQL sont utilisés pour générer la requête MDX finale à l'aide d'une transformation XSL.
Requêtes MDX statiques
Lorsque vous connaissez la requête exacte requise pour obtenir les données pour votre application Notification Services, vous pouvez écrire une requête statique. Notification Services exécutera cette requête exacte selon la planification de quanta spécifiée dans la définition d'application.
Examinez la définition de classe d'événement suivante :
<EventClass>
<EventClassName>KPIEvents</EventClassName>
<Schema>
<Field>
<FieldName>Employee</FieldName>
<FieldType>varchar(100)</FieldType>
</Field>
<Field>
<FieldName>ProfitMargin</FieldName>
<FieldType>varchar(10)</FieldType>
</Field>
<Field>
<FieldName>OrderQuantity</FieldName>
<FieldType>int</FieldType>
</Field>
<Field>
<FieldName>SalesAmount</FieldName>
<FieldType>money</FieldType>
</Field>
</Schema>
</EventClass>
Voici un exemple d'une requête statique MDX qui renvoie un résultat approprié, correspondant à cette classe d'événement :
SELECT
{[Measures].[Reseller Gross Profit Margin],
[Measures].[Reseller Order Quantity],
[Measures].[Reseller Sales Amount]} ON COLUMNS,
{[Employee].[Employees].[Ken J. Snchez],
[Employee].[Employees].[Amy E. Alberts]} ON ROWS
FROM [Adventure Works]
WHERE [Date].[Calendar].[CY 2002]
Cette requête sélectionne trois mesures dans le cube Adventure Works. Ces mesures correspondent aux colonnes du jeu de résultats. La requête comporte une restriction supplémentaire pour sélectionner les lignes qui appartiennent uniquement à deux employés, Ken J. Sánchez et Amy E. Alberts.
Il existe des tuples multiples dans la dimension Order Time. Ainsi, la requête se limite davantage afin de n'afficher que l'année 2002.
Le jeu de résultats final est une table qui montre les valeurs de Reseller Gross Profit Margin, Reseller Order Quantity, et les valeurs Reseller Sales Amount, correspondant à l'employé sélectionné pour l'année 2002.
| Reseller Gross Profit Margin | Reseller Order Quantity | Reseller Sales Amount | |
|---|---|---|---|
Ken J. Sánchez |
1.34% |
58,241 |
$24,144,429.65 |
Amy E. Alberts |
4.68% |
10,546 |
$3,457,549.94 |
Lorsque Notification Services exécute cette requête, le jeu de résultats à deux dimensions est envoyé en tant que lot d'événements à une classe d'événement.
Requêtes MDX dynamiques
Pour une application Notification Services, vous pouvez sélectionner uniquement les données des employés qui sont abonnés à l'application. Cependant, étant donné que les employés peuvent ajouter et supprimer des abonnements, vous n'obtiendrez pas de liste fixe pour une requête statique lors de la création de l'application.
Vous pouvez écrire une requête statique qui retourne un enregistrement pour chaque employé, qu'il soit abonné ou non. Cependant, si le cube compte des dizaines de milliers d'employés, cette requête statique retourne une ligne par employé. Ceci représente un lot d'événements volumineux comportant des données non pertinentes.
Vous pouvez effectuer des améliorations de performances significatives sur l'application en écrivant une requête MDX dynamique. Examinez une classe d'abonnement avec le schéma suivant :
<SubscriptionClass>
<SubscriptionClassName>KPISubscriptions</SubscriptionClassName>
<Schema>
<Field>
<FieldName>DeviceName</FieldName>
<FieldType>nvarchar(255)</FieldType>
<FieldTypeMods>NOT NULL</FieldTypeMods>
</Field>
<Field>
<FieldName>SubscriberLocale</FieldName>
<FieldType>nvarchar(10)</FieldType>
<FieldTypeMods>NOT NULL</FieldTypeMods>
</Field>
<Field>
<FieldName>EmployeeFullName</FieldName>
<FieldType>varchar(100)</FieldType>
</Field>
<Field>
<FieldName>ProfitMargin</FieldName>
<FieldType>varchar(10)</FieldType>
</Field>
</Schema>
...
</SubscriptionClass>
Vous écrivez d'abord une requête Transact-SQL qui sélectionne la liste des éléments qui vous intéressent, en l'occurrence, les employés :
SELECT EmployeeFullName as Employee
FROM NSKPISubscriptionsView
Cette requête suppose que l'initiale intermédiaire est intégrée au prénom.
Le fournisseur d'événements Analysis Services obtient le résultat de cette requête Transact-SQL dans le formulaire XML, où chaque nom de colonne sélectionné est retourné en tant qu'attribut d'un élément de ligne :
<rows>
<row Employee="Ken J. Snchez" />
<row Employee="Amy E. Alberts" />
<row Employee="Terry Lee Duffy" />
<row Employee="Brian S. Welcker" />
</rows>
Vous écrivez ensuite une transformation XSL pour mettre en forme la liste de résultats dans la requête MDX complète. Par exemple, la transformation peut écrire les parties connues de la requête dans match="rows". Ensuite, pour chaque ligne, transformez la valeur en un élément dans la spécification ON ROWS de la requête MDX. Pour transformer le XML, utilisez la transformation XSL suivante :
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text" />
<xsl:template match="rows">
SELECT
{ [Measures].[Total Product Cost],
KPIValue([Gross Profit Margin]),
KPIGoal([Gross Profit Margin]),
KPIStatus([Gross Profit Margin]),
KPITrend([Gross Profit Margin]) } ON COLUMNS,
{ <xsl:apply-templates select="row"/> } ON ROWS
FROM [Adventure Works]
WHERE [Date].[Calendar Time].[2002]
</xsl:template>
<xsl:template match="row">
<xsl:apply-templates select="@Employee" />
<xsl:if test="not(position()=last())">,
</xsl:if>
</xsl:template>
<xsl:template match="@Employee">[Employee].[Employees].[<xsl:value-of select="."/>]</xsl:template>
</xsl:stylesheet>
Le résultat de cette transformation est une requête MDX complète :
SELECT
{[Measures].[Reseller Gross Profit Margin],
[Measures].[Reseller Order Quantity],
[Measures].[Reseller Sales Amount]} ON COLUMNS,
{ [Employee].[Employees].[Ken J. Snchez],
[Employee].[Employees].[Amy E. Alberts],
[Employee].[Employees].[Brian S. Welcker] } ON ROWS
FROM [Adventure Works]
WHERE [Date].[Calendar].[CY 2002]
Le fournisseur d'événements Analysis Services utilise cette requête, générée dynamiquement à chaque exécution du fournisseur d'événements, pour rechercher les données d'événements dans le cube.
Dans cette transformation XSL, le découpage [Date]. [Calendar].[CY 2002]) est codé de manière irréversible dans la transformation. La requête Transact-SQL peut être transmise au fournisseur d'événements Analysis Services en utilisant l'argument SlicerQuery pour créer dynamiquement la clause WHERE.
Les résultats de la requête de ligne et de la requête de découpage sont combinés en un résultat XML unique :
<rows>
<row Employee="Ken J. Snchez" />
<row Employee="Amy E. Alberts" />
<row Employee="Brian S. Welcker" />
</rows>
<slicers>
<slicer Calendar="CY 2002"/>
</slicers>
Votre transformation XSL est appliquée à ce XML pour générer la requête MDX dynamique.
Voir aussi
Concepts
Définition du fournisseur d'événements Analysis Services
Autres ressources
Fournisseur d'événements Analysis Services
Définition des fournisseurs d'événements
Fournisseurs d'événements standard
Concepts clés dans MDX (MDX)