Partager via

Création d’un fournisseur de conteneurs Windows PowerShell

Ce sujet décrit comment créer un fournisseur Windows PowerShell capable de fonctionner sur des entrepôts de données multi-couches. Pour ce type de stockage de données, le niveau supérieur du magasin contient les éléments racines et chaque niveau suivant est appelé un nœud d’éléments enfants. En permettant à l’utilisateur de travailler sur ces nœuds enfants, l’utilisateur peut interagir hiérarchiquement via le stockage de données.

Les fournisseurs capables de travailler sur des réservoirs de données multi-niveaux sont appelés fournisseurs de conteneurs Windows PowerShell. Cependant, sachez qu’un fournisseur de conteneurs Windows PowerShell ne peut être utilisé que lorsqu’il y a un conteneur (sans conteneurs imbriqués) contenant des éléments. S’il existe des conteneurs imbriqués, alors vous devez implémenter un fournisseur de navigation Windows PowerShell. Pour plus d’informations sur la mise en œuvre du fournisseur de navigation Windows PowerShell, voir Créer un fournisseur de navigation Windows PowerShell.

Note

Vous pouvez télécharger le fichier source C# (AccessDBSampleProvider04.cs) de ce fournisseur en utilisant le Microsoft Windows Software Development Kit for Windows Vista et les composants d’exécution de .NET Framework 3.0. Pour les instructions de téléchargement, consultez Comment installer Windows PowerShell et télécharger le SDK Windows PowerShell. Les fichiers sources téléchargés sont disponibles dans le <répertoire PowerShell Samples> . Pour plus d’informations sur les autres implémentations de fournisseurs Windows PowerShell, voir Designing Your Windows PowerShell Provider.

Le fournisseur de conteneurs Windows PowerShell décrit ici définit la base de données comme son unique conteneur, les tables et lignes de la base de données étant définies comme des éléments du conteneur.

Caution

Sachez que cette conception suppose une base de données avec un champ avec l’ID du nom, et que le type du champ est LongInteger.

Définition d’une classe de fournisseur de conteneurs Windows PowerShell

Un fournisseur de conteneurs Windows PowerShell doit définir une classe .NET dérivée de la classe de base System.Management.Automation.Provider.ContainerCmdletProvider . Voici la définition de classe pour le fournisseur de conteneurs Windows PowerShell décrit dans cette section.

[CmdletProvider("AccessDB", ProviderCapabilities.None)]
public class AccessDBProvider : ContainerCmdletProvider

Remarquez que dans cette définition de classe, l’attribut System.Management.Automation.Provider.CmdletProviderAttribute inclut deux paramètres. Le premier paramètre spécifie un nom convivial pour le fournisseur utilisé par Windows PowerShell. Le second paramètre spécifie les capacités spécifiques à Windows PowerShell que le fournisseur expose à l’exécution Windows PowerShell lors du traitement des commandes. Pour ce fournisseur, aucune fonctionnalité spécifique à Windows PowerShell n’est ajoutée.

Définition de la fonctionnalité de base

Comme décrit dans Designing Your Windows PowerShell Provider, la classe System.Management.Automation.Provider.ContainerCmdletProvider dérive de plusieurs autres classes qui offraient différentes fonctionnalités de fournisseurs. Un fournisseur de conteneurs Windows PowerShell doit donc définir toutes les fonctionnalités fournies par ces classes.

Pour implémenter des fonctionnalités permettant d’ajouter des informations d’initialisation spécifiques à chaque session et de libérer les ressources utilisées par le fournisseur, voir Créer un fournisseur Windows PowerShell de base. Cependant, la plupart des fournisseurs (y compris celui décrit ici) peuvent utiliser l’implémentation par défaut de cette fonctionnalité fournie par Windows PowerShell.

Pour accéder au stockage de données, le fournisseur doit implémenter les méthodes de la classe de base System.Management.Automation.Provider.DriveCmdletProvider . Pour plus d’informations sur la mise en œuvre de ces méthodes, voir Créer un fournisseur de disques Windows PowerShell.

Pour manipuler les éléments d’un magasin de données, tels que l’obtention, la mise en place et la compensation des éléments, le fournisseur doit implémenter les méthodes fournies par la classe de base System.Management.Automation.Provider.ItemCmdletProvider . Pour plus d’informations sur la mise en œuvre de ces méthodes, voir Créer un fournisseur d’éléments PowerShell Windows.

Récupération des objets enfants

Pour récupérer un élément enfant, le fournisseur de conteneurs PowerShell Windows doit passer outre la méthode System.Management.Automation.Provider.ContainerCmdletProvider.GetChildItems* afin de prendre en charge les appels depuis le Get-ChildItem cmdlet. Cette méthode récupère les éléments enfants du magasin de données et les écrit dans le pipeline sous forme d’objets. Si le recurse paramètre du cmdlet est spécifié, la méthode récupère tous les enfants quel que soit leur niveau. Si le recurse paramètre n’est pas spécifié, la méthode ne récupère qu’un seul niveau d’enfants.

Voici l’implémentation de la méthode System.Management.Automation.Provider.ContainerCmdletProvider.GetChildItems* pour ce fournisseur. Remarquez que cette méthode récupère les éléments enfants dans toutes les tables de la base de données lorsque le chemin indique la base de données Access, et récupère les éléments enfants dans les lignes de cette table si le chemin indique une table de données.

protected override void GetChildItems(string path, bool recurse)
{
    // If path represented is a drive then the children in the path are 
    // tables. Hence all tables in the drive represented will have to be
    // returned
    if (PathIsDrive(path))
    {
        foreach (DatabaseTableInfo table in GetTables())
        {
            WriteItemObject(table, path, true);

            // if the specified item exists and recurse has been set then 
            // all child items within it have to be obtained as well
            if (ItemExists(path) && recurse)
            {
                GetChildItems(path + pathSeparator + table.Name, recurse);
            }
        } // foreach (DatabaseTableInfo...
    } // if (PathIsDrive...
    else
    {
        // Get the table name, row number and type of path from the
        // path specified
        string tableName;
        int rowNumber;

        PathType type = GetNamesFromPath(path, out tableName, out rowNumber);

        if (type == PathType.Table)
        {
            // Obtain all the rows within the table
            foreach (DatabaseRowInfo row in GetRows(tableName))
            {
                WriteItemObject(row, path + pathSeparator + row.RowNumber,
                        false);
            } // foreach (DatabaseRowInfo...
        }
        else if (type == PathType.Row)
        {
            // In this case the user has directly specified a row, hence
            // just give that particular row
            DatabaseRowInfo row = GetRow(tableName, rowNumber);
            WriteItemObject(row, path + pathSeparator + row.RowNumber,
                        false);
        }
        else
        {
            // In this case, the path specified is not valid
            ThrowTerminatingInvalidPathException(path);
        }
    } // else
} // GetChildItems

Choses à retenir concernant la mise en œuvre de GetChildItems

Les conditions suivantes peuvent s’appliquer à votre implémentation de System.Management.Automation.Provider.ContainerCmdletProvider.GetChildItems* :

Attacher des paramètres dynamiques au Get-ChildItem cmdlet

Parfois, le Get-ChildItem cmdlet qui appelle System.Management.Automation.Provider.ContainerCmdletProvider.GetChildItems* nécessite des paramètres supplémentaires spécifiés dynamiquement à l’exécution. Pour fournir ces paramètres dynamiques, le fournisseur de conteneurs Windows PowerShell doit implémenter la méthode System.Management.Automation.Provider.ContainerCmdletProvider.GetChildItemsDynamicParameters* . Cette méthode récupère les paramètres dynamiques de l’élément sur le chemin indiqué et renvoie un objet ayant des propriétés et des champs avec des attributs d’analyse similaires à une classe cmdlet ou à un objet System.Management.Automation.RuntimeDefinedParameterDictionary . L’exécution PowerShell de Windows utilise l’objet retourné pour ajouter les paramètres au Get-ChildItem cmdlet.

Ce fournisseur de conteneurs Windows PowerShell n’implémente pas cette méthode. Cependant, le code suivant est l’implémentation par défaut de cette méthode.

Récupération des noms d’objets enfants

Pour récupérer les noms des éléments enfants, le fournisseur de conteneurs PowerShell Windows doit passer outre la méthode System.Management.Automation.Provider.ContainerCmdletProvider.GetChildNames* afin de supporter les appels depuis le Get-ChildItem cmdlet lorsque son Name paramètre est spécifié. Cette méthode récupère les noms des éléments enfants pour le chemin spécifié ou les noms d’éléments enfants pour tous les conteneurs si le returnAllContainers paramètre du cmdlet est spécifié. Un nom d’enfant est la partie feuille d’un chemin. Par exemple, le nom enfant du chemin C:\windows\system32\abc.dll est «abc.dll». Le nom enfant du répertoire C :\windows\system32 est « system32 ».

Voici la mise en œuvre de la méthode System.Management.Automation.Provider.ContainerCmdletProvider.GetChildNames* pour ce fournisseur. Remarquez que la méthode récupère les noms des tables si le chemin spécifié indique la base de données Access (disque) et les numéros de lignes si le chemin indique une table.

protected override void GetChildNames(string path,
                              ReturnContainers returnContainers)
{
    // If the path represented is a drive, then the child items are
    // tables. get the names of all the tables in the drive.
    if (PathIsDrive(path))
    {
        foreach (DatabaseTableInfo table in GetTables())
        {
            WriteItemObject(table.Name, path, true);
        } // foreach (DatabaseTableInfo...
    } // if (PathIsDrive...
    else
    {
        // Get type, table name and row number from path specified
        string tableName;
        int rowNumber;

        PathType type = GetNamesFromPath(path, out tableName, out rowNumber);

        if (type == PathType.Table)
        {
            // Get all the rows in the table and then write out the 
            // row numbers.
            foreach (DatabaseRowInfo row in GetRows(tableName))
            {
                WriteItemObject(row.RowNumber, path, false);
            } // foreach (DatabaseRowInfo...
        }
        else if (type == PathType.Row)
        {
            // In this case the user has directly specified a row, hence
            // just give that particular row
            DatabaseRowInfo row = GetRow(tableName, rowNumber);

            WriteItemObject(row.RowNumber, path, false);
        }
        else
        {
            ThrowTerminatingInvalidPathException(path);
        }
    } // else
} // GetChildNames

Choses à retenir concernant la mise en œuvre de GetChildNames

Les conditions suivantes peuvent s’appliquer à votre implémentation de System.Management.Automation.Provider.ContainerCmdletProvider.GetChildItems* :

Attacher des paramètres dynamiques au Get-ChildItem cmdlet (nom)

Parfois, le Get-ChildItem cmdlet (avec le Name paramètre) nécessite des paramètres supplémentaires spécifiés dynamiquement à l’exécution. Pour fournir ces paramètres dynamiques, le fournisseur de conteneurs Windows PowerShell doit implémenter la méthode System.Management.Automation.Provider.ContainerCmdletProvider.GetChildNamesDynamicParameters* . Cette méthode récupère les paramètres dynamiques de l’élément sur le chemin indiqué et renvoie un objet possédant des propriétés et des champs avec des attributs d’analyse similaires à une classe cmdlet ou à un objet System.Management.Automation.RuntimeDefinedParameterDictionary . L’exécution PowerShell de Windows utilise l’objet retourné pour ajouter les paramètres au Get-ChildItem cmdlet.

Ce fournisseur ne met pas en œuvre cette méthode. Cependant, le code suivant est l’implémentation par défaut de cette méthode.

Renommage des objets

Pour renommer un élément, un fournisseur de conteneurs Windows PowerShell doit passer outre la méthode System.Management.Automation.Provider.ContainerCmdletProvider.RenameItem* afin de supporter les appels depuis le Rename-Item cmdlet. Cette méthode modifie le nom de l’élément sur le chemin spécifié pour le nouveau nom fourni. Le nouveau nom doit toujours être relatif à l’élément parent (conteneur).

Ce fournisseur ne supprime pas la méthode System.Management.Automation.Provider.ContainerCmdletProvider.RenameItem* . Cependant, voici l’implémentation par défaut.

Choses à retenir concernant la mise en œuvre de RenameItem

Les conditions suivantes peuvent s’appliquer à votre implémentation de System.Management.Automation.Provider.ContainerCmdletProvider.RenameItem* :

Attacher des paramètres dynamiques au Rename-Item cmdlet

Parfois, le Rename-Item cmdlet nécessite des paramètres supplémentaires spécifiés dynamiquement à l’exécution. Pour fournir ces paramètres dynamiques, le fournisseur de conteneurs Windows PowerShell doit implémenter la méthode System.Management.Automation.Provider.ContainerCmdletProvider.RenameItemDynamicParameters* . Cette méthode récupère les paramètres de l’élément sur le chemin indiqué et renvoie un objet ayant des propriétés et des champs avec des attributs d’analyse similaires à une classe cmdlet ou à un objet System.Management.Automation.RuntimeDefinedParameterDictionary . L’exécution PowerShell de Windows utilise l’objet retourné pour ajouter les paramètres au Rename-Item cmdlet.

Ce fournisseur de conteneurs n’implémente pas cette méthode. Cependant, le code suivant est l’implémentation par défaut de cette méthode.

Création de nouveaux objets

Pour créer de nouveaux éléments, un fournisseur de conteneurs doit implémenter la méthode System.Management.Automation.Provider.ContainerCmdletProvider.NewItem* pour supporter les appels depuis le New-Item cmdlet. Cette méthode crée un élément de données situé sur le chemin spécifié. Le type paramètre du cmdlet contient le type défini par le fournisseur pour le nouvel élément. Par exemple, le fournisseur du système de fichiers utilise un type paramètre avec la valeur « fichier » ou « répertoire ». Le newItemValue paramètre du cmdlet spécifie une valeur spécifique au fournisseur pour le nouvel élément.

Voici la mise en œuvre de la méthode System.Management.Automation.Provider.ContainerCmdletProvider.NewItem* pour ce fournisseur.

protected override void NewItem( string path, string type, object newItemValue )
{
    // Create the new item here after
    // performing necessary validations
    //
    // WriteItemObject(newItemValue, path, false);

    // Example
    //
    // if (ShouldProcess(path, "new item"))
    // {
    //      // Create a new item and then call WriteObject
    //      WriteObject(newItemValue, path, false);
    // }

} // NewItem

{
    case 1:
        {
            string name = pathChunks[0];

            if (TableNameIsValid(name))
            {
                tableName = name;
                retVal = PathType.Table;
            }
        }
        break;

    case 2:
        {
            string name = pathChunks[0];

Points à retenir concernant la mise en œuvre de NewItem

Les conditions suivantes peuvent s’appliquer à votre implémentation de System.Management.Automation.Provider.ContainerCmdletProvider.NewItem* :

Attacher des paramètres dynamiques au New-Item cmdlet

Parfois, le New-Item cmdlet nécessite des paramètres supplémentaires spécifiés dynamiquement à l’exécution. Pour fournir ces paramètres dynamiques, le fournisseur du conteneur doit implémenter la méthode System.Management.Automation.Provider.ContainerCmdletProvider.NewItemDynamicParameters* . Cette méthode récupère les paramètres de l’élément sur le chemin indiqué et renvoie un objet ayant des propriétés et des champs avec des attributs d’analyse similaires à une classe cmdlet ou à un objet System.Management.Automation.RuntimeDefinedParameterDictionary . L’exécution PowerShell de Windows utilise l’objet retourné pour ajouter les paramètres au New-Item cmdlet.

Ce fournisseur ne met pas en œuvre cette méthode. Cependant, le code suivant est l’implémentation par défaut de cette méthode.

Suppression des éléments

Pour supprimer des éléments, le fournisseur Windows PowerShell doit passer outre la méthode System.Management.Automation.Provider.ContainerCmdletProvider.RemoveItem* afin de supporter les appels depuis le Remove-Item cmdlet. Cette méthode supprime un élément du stockage de données sur le chemin spécifié. Si le recurse paramètre du Remove-Item cmdlet est défini à true, la méthode supprime tous les éléments enfants, quel que soit leur niveau. Si le paramètre est fixé à false, la méthode ne retire qu’un seul élément sur le chemin spécifié.

Ce fournisseur ne supporte pas le retrait d’articles. Cependant, le code suivant est l’implémentation par défaut de System.Management.Automation.Provider.ContainerCmdletProvider.RemoveItem*.

Choses à retenir concernant la mise en œuvre de RemoveItem

Les conditions suivantes peuvent s’appliquer à votre implémentation de System.Management.Automation.Provider.ContainerCmdletProvider.NewItem* :

Attacher des paramètres dynamiques au Remove-Item cmdlet

Parfois, le Remove-Item cmdlet nécessite des paramètres supplémentaires spécifiés dynamiquement à l’exécution. Pour fournir ces paramètres dynamiques, le fournisseur du conteneur doit implémenter la méthode System.Management.Automation.Provider.ContainerCmdletProvider.RemoveItemDynamicParameters* pour gérer ces paramètres. Cette méthode récupère les paramètres dynamiques de l’élément sur le chemin indiqué et renvoie un objet possédant des propriétés et des champs avec des attributs d’analyse similaires à une classe cmdlet ou à un objet System.Management.Automation.RuntimeDefinedParameterDictionary . L’exécution PowerShell de Windows utilise l’objet retourné pour ajouter les paramètres au Remove-Item cmdlet.

Ce fournisseur de conteneurs n’implémente pas cette méthode. Cependant, le code suivant est l’implémentation par défaut de System.Management.Automation.Provider.ContainerCmdletProvider.RemoveItemDynamicParameters*.

Requête pour les éléments enfants

Pour vérifier si des éléments enfants existent sur le chemin spécifié, le fournisseur de conteneurs PowerShell de Windows doit écraser la méthode System.Management.Automation.Provider.ContainerCmdletProvider.HasChildItems* . Cette méthode revient true si l’élément a des enfants, et false sinon. Pour un chemin nul ou vide, la méthode considère tous les éléments du magasin de données comme étant des enfants et renvoie true.

Voici la dérogation pour la méthode System.Management.Automation.Provider.ContainerCmdletProvider.HasChildItems* . S’il y a plus de deux parties de chemin créées par la méthode d’aide ChunkPath, la méthode retourne false, puisque seuls un conteneur de base de données et un conteneur de table sont définis. Pour plus d’informations sur cette méthode d’assistance, voir la méthode ChunkPath expliquée dans Créer un fournisseur d’éléments PowerShell Windows.

protected override bool HasChildItems( string path )
{
    return false;
} // HasChildItems

        ErrorCategory.InvalidOperation, tableName));
}

return results;

Choses à retenir concernant la mise en œuvre de HasChildItems

Les conditions suivantes peuvent s’appliquer à votre implémentation de System.Management.Automation.Provider.ContainerCmdletProvider.HasChildItems* :

Copie des objets

Pour copier les éléments, le fournisseur du conteneur doit implémenter la méthode System.Management.Automation.Provider.ContainerCmdletProvider.CopyItem pour supporter les appels depuis le Copy-Item cmdlet. Cette méthode copie un élément de données de l’emplacement indiqué par le path paramètre du cmdlet à l’emplacement indiqué par le copyPath paramètre. Si le recurse paramètre est spécifié, la méthode copie tous les sous-conteneurs. Si le paramètre n’est pas spécifié, la méthode ne copie qu’un seul niveau d’éléments.

Ce fournisseur ne met pas en œuvre cette méthode. Cependant, le code suivant est l’implémentation par défaut de System.Management.Automation.Provider.ContainerCmdletProvider.CopyItem.

Choses à retenir concernant la mise en œuvre de CopyItem

Les conditions suivantes peuvent s’appliquer à votre implémentation de System.Management.Automation.Provider.ContainerCmdletProvider.CopyItem :

Attacher des paramètres dynamiques au Copy-Item cmdlet

Parfois, le Copy-Item cmdlet nécessite des paramètres supplémentaires spécifiés dynamiquement à l’exécution. Pour fournir ces paramètres dynamiques, le fournisseur de conteneurs PowerShell Windows doit implémenter la méthode System.Management.Automation.Provider.ContainerCmdletProvider.CopyItemDynamicParameters* pour gérer ces paramètres. Cette méthode récupère les paramètres de l’élément sur le chemin indiqué et renvoie un objet ayant des propriétés et des champs avec des attributs d’analyse similaires à une classe cmdlet ou à un objet System.Management.Automation.RuntimeDefinedParameterDictionary . L’exécution PowerShell de Windows utilise l’objet retourné pour ajouter les paramètres au Copy-Item cmdlet.

Ce fournisseur ne met pas en œuvre cette méthode. Cependant, le code suivant est l’implémentation par défaut de System.Management.Automation.Provider.ContainerCmdletProvider.CopyItemDynamicParameters*.

Exemple de code

Pour un code d’exemple complet, voir AccessDbProviderSample04 Code Example.

Construire le fournisseur Windows PowerShell

Voir comment enregistrer les commandants, les fournisseurs et les applications hôtes.

Test du fournisseur Windows PowerShell

Lorsque votre fournisseur Windows PowerShell est enregistré auprès de Windows PowerShell, vous pouvez le tester en exécutant les cmdlets supportés en ligne de commande. Sachez que l’exemple suivant utilise une base de données Access fictive.

  1. Exécutez le Get-ChildItem cmdlet pour récupérer la liste des éléments enfants à partir d’une table Clients dans la base de données Access.

    Get-ChildItem mydb:customers

    La sortie suivante apparaît.

    PSPath        : AccessDB::customers
PSDrive       : mydb
PSProvider    : System.Management.Automation.ProviderInfo
PSIsContainer : True
Data          : System.Data.DataRow
Name          : Customers
RowCount      : 91
Columns       :

  2. Exécutez à nouveau le Get-ChildItem cmdlet pour récupérer les données d’une table.

    (Get-ChildItem mydb:customers).Data

    La sortie suivante apparaît.

    TABLE_CAT   : C:\PS\northwind
TABLE_SCHEM :
TABLE_NAME  : Customers
TABLE_TYPE  : TABLE
REMARKS     :

  3. Utilisez maintenant le Get-Item cmdlet pour récupérer les éléments à la rangée 0 dans la table de données.

    Get-Item mydb:\customers\0

    La sortie suivante apparaît.

    PSPath        : AccessDB::customers\0
PSDrive       : mydb
PSProvider    : System.Management.Automation.ProviderInfo
PSIsContainer : False
Data          : System.Data.DataRow
RowNumber     : 0

  4. Réutiliser Get-Item pour récupérer les données des éléments de la ligne 0.

    (Get-Item mydb:\customers\0).Data

    La sortie suivante apparaît.

    CustomerID   : 1234
CompanyName  : Fabrikam
ContactName  : Eric Gruber
ContactTitle : President
Address      : 4567 Main Street
City         : Buffalo
Region       : NY
PostalCode   : 98052
Country      : USA
Phone        : (425) 555-0100
Fax          : (425) 555-0101

  5. Utilisez maintenant le New-Item cmdlet pour ajouter une ligne à une table existante. Le Path paramètre spécifie le chemin complet vers la ligne, et doit indiquer un numéro de ligne supérieur au nombre existant de lignes dans le tableau. Le Type paramètre indique Row de spécifier ce type d’élément à ajouter. Enfin, le Value paramètre spécifie une liste délimitée par des virgules des valeurs de colonnes pour la ligne.

    New-Item -Path mydb:\Customers\3 -ItemType "Row" -Value "3,CustomerFirstName,CustomerLastName,CustomerEmailAddress,CustomerTitle,CustomerCompany,CustomerPhone, CustomerAddress,CustomerCity,CustomerState,CustomerZip,CustomerCountry"

  6. Vérifiez la justesse du fonctionnement du nouvel élément comme suit.

    PS mydb:\> cd Customers
PS mydb:\Customers> (Get-Item 3).Data

    La sortie suivante apparaît.

    ID        : 3
FirstName : Eric
LastName  : Gruber
Email     : ericgruber@fabrikam.com
Title     : President
Company   : Fabrikam
WorkPhone : (425) 555-0100
Address   : 4567 Main Street
City      : Buffalo
State     : NY
Zip       : 98052
Country   : USA

Voir aussi

Création de fournisseurs Windows PowerShell

Concevoir votre fournisseur Windows PowerShell

Implémentation d’un fournisseur Windows PowerShell d’élément

Implémentation d’un fournisseur PowerShell Windows pour la navigation

Comment enregistrer des commandants, des fournisseurs et des applications hôtes

Windows PowerShell SDK

Guide du programmeur Windows PowerShell

  • Last updated on