Conceptos principales para la escritura de cmdlets de la Consola de administración de SharePoint
Última modificación: jueves, 01 de octubre de 2009
Hace referencia a: SharePoint Foundation 2010
En este artículo
Parámetros de cmdlet
Canalizaciones
Objetos PipeBind
Existen varios conceptos principales que son decisivos al escribir cmdlets de Windows PowerShell para SharePoint. El contenido que se muestra a continuación no es exhaustivo, pero enumera algunos de los conceptos importantes que admiten la implementación de Windows PowerShell para SharePoint.
Parámetros de cmdlet
Aunque los usuarios escriben los valores del parámetro como cadenas, Windows PowerShell intenta convertir estos valores de cadena en el tipo correcto, en función de la definición de parámetro. Por lo tanto, los cmdlets que escriba deben proporcionar un modo de comprobar que los valores del parámetro que se pasan al cmdlet son de un tipo de datos válido.
Evite pasar parámetros de tipo cadena o entero a menos que todos los valores de ese tipo sean válidos para el parámetro. En su lugar, defina una clase que restrinja en mayor medida el intervalo y el formato de los parámetros. Además, valide los parámetros mediante el método Parse(String) del tipo de parámetro. Windows PowerShell admite el uso del método Parse() para convertir un tipo de cadena en otros tipos de datos.
Canalizaciones
Entre las mejoras más significativas que ofrece Windows PowerShell, además de las funcionalidades de Cmd.exe, se incluye la capacidad nativa de Windows PowerShell de combinar una serie de cmdlets simples en una canalización, es decir, una serie o secuencia de comandos. La canalización permite que los objetos de salida de un comando se pasen (o canalicen) como objetos de entrada a comandos subsiguientes. Las canalizaciones de comandos permiten a los programadores de cmdlets crear canalizaciones de comandos complejas y flexibles cuyos objetos de salida puedan guardarse y volver a usarse.
El proceso de canalización se basa en el comportamiento del cmdlet donde se escriben los objetos de salida en una canalización de objetos controlada por Windows PowerShell. Esto permite a Windows PowerShell intentar adecuar el objeto en la canalización que tenga los parámetros del cmdlet subsiguiente.
Para que la canalización funcione, debe haber una correspondencia explícita entre la salida del cmdlet anterior y la entrada de los cmdlets siguientes. Esta correspondencia puede llevarse a cabo en el nivel del objeto, donde el objeto anterior en la canalización debe coincidir con un parámetro del cmdlet subsiguiente. (Esto se denomina canalización por valor.) Como alternativa, la correspondencia puede llevarse a cabo en el nivel de la propiedad, donde las propiedades del objeto anterior en la canalización debe coincidir con los parámetros del cmdlet subsiguiente.
Canalización por valor
Canalización por valor significa que un cmdlet de canal de bajada consumirá un objeto completo de la canalización, siempre y cuando el objeto sea del tipo correcto. La canalización por valor se lleva a cabo comúnmente mediante cmdlets Set, ya que al pasar un objeto completo se guarda una operación de lectura de los datos de origen, y mediante cmdlets New que admiten la clonación. La canalización por valor también se usa en casos en que el cmdlet de canal de bajada no puede volver a leer el objeto que produjo el cmdlet de canal de subida.
Objetos PipeBind
Los objetos PipeBind son objetos especiales exclusivos de Windows PowerShell para SharePoint y proporcionan un segundo nivel de conjuntos de parámetros especializados optimizados para SharePoint Foundation.
Al usar objetos de SharePoint Foundation 2010 como parámetros de cmdlets, debe usar el objeto PipeBind adecuado en lugar del objeto de SharePoint. Esto es esencial, ya que permite al usuario del cmdlet especificar el valor del parámetro de manera adecuada. El objeto PipeBind realmente representa un nivel ubicado entre la entrada del usuario para un parámetro y el propio objeto de parámetro.
Por ejemplo, un cmdlet que toma un parámetro SPSite puede tomar el propio objeto SPSite o el identificador GUID de esa colección de sitios, o bien la dirección URL de la colección de sitios. La tarea del objeto SPSitePipeBind consiste en garantizar que, independientemente de la representación que presente el tiempo de ejecución de Windows PowerShell, el propio cmdlet se presente con el objeto SPSite real.
Nota
Las clases PipeBind no deben enlazarse con cmdlets específicos sino entre todos los cmdlets. Al escribir un cmdlet PipeBind, asegúrese de que no tenga requisitos específicos del implementador del cmdlet.
Implementación de un objeto PipeBind
Al implementar un objeto PipeBind, debe derivar de la clase base SPCmdletPipeBind<TCmdletObject>. Para implementar esta clase, realice el siguiente procedimiento:
Implemente el constructor de clase.
Invalide el método Read() del objeto.
La clase PipeBind debe tener al menos un constructor, aunque puede tener más de uno. Cuando Windows PowerShell intenta enlazar parámetros, itera en el conjunto de constructores públicos de un parámetro especificado e intenta hacer coincidir la entrada de parámetro con un constructor de PipeBind. Esto significa que para cada tipo de entrada posible que represente un parámetro debe haber un constructor correspondiente.
El método Read() del objeto SPCmdletPipeBind<TCmdletObject> devuelve el tipo de objeto definido en el modelo de objetos de SharePoint Foundation: public virtual TCmdletObject Read().
Tenga en cuenta que el método Read() debe invalidarse para cada implementación de objeto PipeBind para garantizar que el objeto del modelo de objetos se recupere correctamente. Puede crear invalidaciones adicionales del método Read(), según sea necesario, para proporcionar los parámetros requeridos.
Atomicidad e identidad de cmdlet
Los cmdlets deben tener un parámetro Identity que especifique el objeto en el que van a actuar. Al escribir cmdlets, debe especificar un identificador único como valor para el parámetro Identity. Tenga en cuenta, sin embargo, que los nuevos cmdlets no tendrán un identificador inicialmente, ya que el identificador puede existir sólo después de la instalación del objeto que identificará.
La ejecución del cmdlet debe simular la atomicidad. Es decir que un cmdlet debe lograr su objetivo y cambiar el estado del sistema, o bien sencillamente dar error y devolver el sistema al estado en el que se encontraba antes de la ejecución. En otras palabras, los cmdlets deben proporcionar un método de restaurar el estado del sistema en caso de error.