Mes: octubre 2006

A TOPE, El jueves 26, se celebro la Segunda conferencia de usuarios de SharePoint, en donde intervine durante la mañana (un poco nervioso, como es lógico ya que había 300 personas y no estoy acostumbrado a una audiencia tan numerosa), quiero dar las gracias a Rafael Sanchez, jefe de producto de SharePoint y como no a los fenómenos de preventa, Oscar y Pablo por su ayuda.

Por la tarde di una sesión sobre SharePoint Designer, y como vi que íbamos un poco justos de tiempo me salte la presentación de powerpoint y me fui directo a la demo. Como algunos me habéis preguntado por ella intentaré realizar un webcast para que os lo podáis descargar.

El viernes por la mañana me dirigí al Escorial donde se celebraba el Train The Trainers y el CodeCamp durante el fin de semana. En donde además de trabajar tuvimos tiempo de pasarlo bien.

 

Tengo un montón de emails, por contestar, paciencia.

El Jueves día 26 se celebra la Segunda edición de C.E.U.S., El C.E.U.S. pretende consolidar un marco de reunión anual donde, los responsables de IT y responsables de tecnología de diferentes organizaciones, puedan intercambiar experiencias y profundizar en las múltiples posibilidades de Microsoft SharePoint Server.

Para más información e inscripciones : http://www.microsoft.com/spain/office/ceus/

 

Today in the Javier Castle in Navarra we celebrated an informal SharePoint meeting very interesting.

Talking about MOSS 2007 and migration scenarios from SPS 2003, and of course other things.

In the photo Rolf Eleveld [right], Gustavo Velez [center]  (both from Winvision, Holland) and me [left] in a break.

El viernes hablando con Miguel Jimenez me comentó que estaba en Bilbao dando un curso, y no se muy bien, alguien que estaba con el me conocía. Me conocía por una BBS que tuve hace ya algunos años (1992-1995).

Esta mañana he madrugado para ver las carreras (G.P de Suzuka) “Una victoria inesperada, sorprendente.” Y después he buscado pro ahí a ver que tenía guardado de aquel BBS.

Que sorpresa cuando me he encontrado un CD con una copia de la BBS, así que echando mano de una maquina virtual he instalado un msdos y volcado la copia ….

Os juro que ha sido un viaje de lo más alucinante. En un momento he recordado aquellos tiempos y hasta se me ha puesto la carne de gallina. Remote Access, FrontDoor (el frodo), AllFix, las Nodelists, Mailer Daemon …. (¡Que magníficos programas!)

Incluso tenía un esquema sensacional (ASCII art-deco) de infraestructura, que tiempos, si bajo al trastero y encuentro mi US Robotics HST V.All me hecho a llorar.

Que pasada…

Para terminar con el BDC, nos queda ver dos cosas impresionantes (por lo menos a mi juicio). La posibilidad de usar columnas del BDC dentro de las listas y como integrar el BDC en las búsquedas de SharePoint.

Uso del catálogo de datos en las listas

Una vez que hemos importado nuestros definiciones LOB, cuando creamos una lista nueva tendremos disponible, un nuevo tipo de datos «Datos profesionales» a través del cual vamos a poder relacionar un elemento de una lista con el BDC.

Además podemos traernos otras columnas que formarán parte de la lista.

En este momento, y con la B2TR no es posible añadir los «Datos profesionales» a los tipos de contenido, pero sugerí esta posibilidad al equipo de desarrollo ya que en cierta manera se pierde coherencia y quedaría coja nuestra estructura de datos en SharePoint.

Si  no pudiéramos usar los datos profesionales dentro de los tipos de contenido y por ende, poder usar estos en los paneles de información o como un metadato en cualquier lugar, por ejemplo un tipo de contenido donde es necesario especificar un Cliente o un proyecto que proviene del BDC, el poder usar los datos del BDC solo en las listas sería resolver el problema a medias.

La respuesta:

Submitted: Sep 25 2006 5:06AM
Hi Carlos,
This perfectly reproes in the Beta 2 TR build and I am forwarding the same to the Product team for consideration.
Thanks and keep the feedback coming!

Submitted: Sep 25 2006 2:15PM
Fixed for RTM.

Resolution:  This issue has be fixed in a newer build of Office 12 
Changed Date: 9/25/2006 2:15:24 PM 

 

Búsqueda de datos dentro del BDC

Para integrar el BDC con las búsquedas, debemos realizar tres pasos importantes.

1.- Debemos implementar un método en el LOB para recuperar los elementos que indexará SharePoint. Por ejemplo un método para recuperar los ID de una de las entidades que debe a su vez implementar una instancia de tipo IdEnumerator.

2.- Una vez creado el método, debemos reimportar el LOB y crear un nuevo origen de contenido, dicho origen de contenido será del tipo «Datos Profesionales» y podemos elegir entre seleccionar el catalogo de datos profesionales completo o solo aquellas aplicaciones que nos interese. Una vez creado el origen de contenido, realizaremos un rastreo completo.

3.- Ahora debemos seleccionar los metadatos que nos interese mostrar en las búsquedas y asignarles un tipo de datos existente. Esto se realiza con las Asignaciones de propiedades a metadatos.

Ya solo nos queda realizar la búsqueda

Bueno ¿que os a parecido el BDC? Estos días hay pocos comentarios …

Continuando con las características del BDC, vamos a ver el resto de webparts que podemos usar:

(Business Data Related List) Lista relacionada con datos profesionales

Este webpart nos permite mostrar datos relacionados con una tabla. Una vez que hemos definido en el LOB, las asociaciones / relaciones de nuestras entidades, podemos usar este webpart conectándolo con el webpart  Business Data List  (Lista de datos profesionales),  de este modo, una vez que seleccionemos un elemento en la lista de elementos profesionales, podemos ver los elementos relacionados.

(Business Data Item Builder) Generador de elemento de datos profesionales

Este es un webpart invisible, que se encarga de recoger parámetros (querystring) de la Url actual y enviarlos a otros webparts que se encuentran conectados. Por ejemplo podemos crear una acción dentro del LOB para mostrar los pedidos de un cliente, está acción se realiza a través de una Url como vimos antes Url=»http://spsbeta/SiteDirectory/bdc/Pages/VerPedidos.aspx?CustomerID={0}»  bien, este webpart va ha recoger el CustomerId y enviarlo a otro webpart, como por ejemplo, la lista relacionada con datos profesionales ó el elemento de datos profesionales que veremos a continuación.

(Business Data Item) Elemento de datos profesionales

El elemento de datos profesionales, nos permite ver un elemento de una entidad, dicho elemento se puede especificar a mano o bien puede venir dado por una conexión con otro webpart. Además podemos personalizar la vista sobre como será mostrado dicho elemento. Otra cosa interesante es que podemos mostrar una barra de herramientas con las acciones disponibles para la entidad y seleccionar cuales queremos mostrar.

  

(Bussines Data Actions) Acciones para datos profesionales

Este webpart nos presentará una lista / lista con viñetas ó barra de herramientas con las distintas acciones que podemos llevar acabo con un elemento de la entidad, al igual que con otros de los webparts, podemos seleccionar el elemento ó tomarlo vía conexión.

Como comentaba anteriormente, los filtros especificados en el LOB, serán los que nos permitirán realizar búsquedas dentro del Business Data List WebPart (Lista de datos profesionales) [Yo hubiera preferido la traducción de Bussines por Negocio en vez de Profesionales], como comenté en el post anterior, para poder realizar estas búsquedas dentro del webpart, debemos especificar estos campos en el LOB.

Lo primero que debemos hacer es añadir a nuestra sentencia SQL, los nexos necesarios en la clausula WHERE :

SELECT CustomerID, CompanyName, ContactName, ContactTitle, Address, City, Region, PostalCode, Country, Phone, Fax 

FROM dbo.Customers 

WHERE (CustomerID LIKE @CustomerID) AND (CompanyName LIKE @CompanyName) AND (ContactName LIKE @ContactName)

En el ejemplo superior he añadido CompanyName y ContactName. Una vez que hemos extendido nuestra cláusula WHERE debemos añadir los FilterDescriptor en la sección FilterDescriptors de nuestro LOB.

  <FilterDescriptors>

    <FilterDescriptor Type=»Wildcard» Name=»CustomerID»>

      <Properties>

        <Property Name=»UsedForDisambiguation« Type=»System.Boolean»>true</Property>

      </Properties>

    </FilterDescriptor>

     <FilterDescriptor Type=»Wildcard» Name=»CompanyName« />

     <FilterDescriptor Type=»Wildcard» Name=»ContactName« />

  </FilterDescriptors>

El mecanismo que usaremos para el filtro dependerá del tipo de nexo que estemos usando en la cláusula WHERE,  si quisiéramos localizar un registro por igualdad, deberíamos usar ExactMacth. Los tipos posibles son:

• Limit – Para especificar el número de filas que devolverá la consulta (SELECT TOP)
  
• ExactMatch – Para igualdades entre terminos.
  
• Wildcard – Para las similitudes.
  
• Range – Para especificar rangos, desde hasta (WHERE Unidades > mínimo AND Unidades < máximo)
  
• UserContext – Pasa el dominiousuario del usuario que realiza la consulta
  
• Username – El nombre del usuario identificado en el Single-Sign-On (SSO)
  
• Password – La clave del usuario identificado por el SSO
  
• LastId – El último id usado
  
• SsoTicket – El ticket completo de SSO.

Por último hay que añadir los filtros como parámetros de entrada obviamente, al igual que hicimos con el CustomerID para recuperar los datos de un cliente en particular.

<Parameter Direction=»In» Name=»@CompanyName«>

  <TypeDescriptor TypeName=»System.String» AssociatedFilter=»CompanyName« Name=»CompanyName»>

    <DefaultValues>

      <DefaultValue MethodInstanceName=»ClientesFinder» Type=»System.String»>%</DefaultValue>

      <DefaultValue MethodInstanceName=»ClientesSpecificFinder» Type=»System.String»>%</DefaultValue>

    </DefaultValues>

  </TypeDescriptor>

</Parameter>

<Parameter Direction=»In» Name=»@ContactName«>

  <TypeDescriptor TypeName=»System.String» AssociatedFilter=»ContactName« Name=»ContactName»>

    <DefaultValues>

      <DefaultValue MethodInstanceName=»ClientesFinder» Type=»System.String»>%</DefaultValue>

      <DefaultValue MethodInstanceName=»ClientesSpecificFinder» Type=»System.String»>%</DefaultValue>

    </DefaultValues>

  </TypeDescriptor>

</Parameter>

Para estos parámetros  también debemos incluir los valores por defecto que se usará para recuperar los datos, aquí entre en juego un apartado de los filtros que es importante aunque sea opcional, se trata del UsedForDisambiguation, que indicará el campo que diferenciará los resultados cuando una búsqueda retorne múltiples respuestas.

Una cosa más para terminar con el LOB, se trata de las relaciones. En el LOB se corresponden con el elemento Associations, que viene definido después de las entidades.

<Associations>

    <Association AssociationMethodEntityName=»Clientes» 

		 AssociationMethodName=»PedidosDeCliente» 

                 AssociationMethodReturnParameterName=»Orderss» 

                 Name=»Pedidos de Cliente» 

                 IsCached=»true»>

      <SourceEntity Name=»Clientes» />

      <DestinationEntity Name=»Pedidos» />

    </Association>

</Associations>

AssociationMethodEntityName es el método de la entidad que tiene la relación, en este caso Clientes, el método de la entidad que devolverá datos de la relación es AsssociationMethodName, PedidosDeCliente en este caso, los parámetros que son devueltos por dicho método y que contienen el resultado de la relación, el nombre de la relación «Pedidos de Cliente» y dentro de la asociación, se especifican que entidades dentro del LOB, se están relacionando. En este caso la entidad de Clientes con la entidad de Pedidos.

 

Antes de continuar viendo el resto de webparts y la cantidad de cosas que se pueden hacer con el BDC, volvamos por un momento al archivo de configuración del LOB.

Para poder utilizar las acciones, debemos definirlas antes (esto se puede hacer dentro de la administración central de manera sencilla) pero como voy a dedicar esta parte al archivo de definición XML que usamos para configurar el LOB, veremos como se hace en XML.

Cada una de las entidades tiene los siguientes elementos básicos:

AccessControlList – Lista de control de acceso (también se encuentra en otros elementos como los métodos «Methods»)

Identifiers – Que representan elementos clave (id)

<Identifiers>

  <Identifier TypeName=»System.String» Name=»CustomerID« />

</Identifiers>

Methods – La forma en que recuperaremos datos de la base de datos, una entidad puede como es lógico tener más de un método para devolver datos. Aunque a priori pueda parecer que hay una correspondencia entre tabla y method, no es así. Cada method debe ser visto como un procedimiento que tenemos para recuperar datos de la base de datos asociados con una entidad. De modo que dichos datos no tienen por que ser de la misma tabla. 

En esta primera parte definimos como vamos a recuperar los datos, para bases de datos podemos usar  Text, StoredProcedure, ó TableDirect. En este caso, es una sentencia SQL con lo que el tipo de comando es text y el comando la sentencia SQL.
 

<Method Name=»Clientes»>

  <Properties>

    <Property Name=»RdbCommandType» 

	      Type=»System.Data.CommandType, ….»>

		Text

    </Property>

    <Property Name=»RdbCommandText» Type=»System.String»>

          SELECT CustomerID, CompanyName, ContactName, ContactTitle, Address, City, Region, PostalCode, Country, Phone, Fax

	  FROM dbo.Customers

	  WHERE CustomerID LIKE @CustomerID

    </Property>

  </Properties>

Después tenemos que definir los campos que queremos utilizar en los filtros, si un campo no está aquí definido, no podremos usarlo para filtrar. Existen distintos mecanismos para filtrar los datos, Wildcard, Comparision, Limit, UserContext, Username, Password (les dedicaremos una sección más adelante)
 

  <FilterDescriptors>

    <FilterDescriptor Type=»Wildcard» Name=»CustomerID«>

      <Properties>

        <Property Name=»UsedForDisambiguation» Type=»System.Boolean»>true</Property>

      </Properties>

    </FilterDescriptor>

  </FilterDescriptors>

Los parámetros, las entradas y salidas de cada uno de los métodos. En este ejemplo se usa CustomerID, como una entrada, observar que el nombre coincide con el parámetro de nuestra sentencia SQL, que el identificador (esto es importante) debe estar definido y que este parámetro se usará en el filtro del mismo nombre. Y por último vemos que tienen asociados dos valores por defecto cuando este parámetro se usa con determinados métodos. Esos métodos en concreto Finder y SpecificFinder hay que definirlos siempre que queramos usar nuestra definición de datos con el Business Data List Webpart.

  <Parameters>

    <Parameter Direction=»In» Name=»@CustomerID«>

      <TypeDescriptor TypeName=»»System.String» IdentifierNameCustomerID« AssociatedFilter=»CustomerID« Name=»CustomerID»>

        <DefaultValues>

          <DefaultValue MethodInstanceName=»ClientesFinder« Type=»»System.String»>%</DefaultValue>

          <DefaultValue MethodInstanceName=»ClientesSpecificFinder« Type=»»System.String»>%</DefaultValue>

        </DefaultValues>

      </TypeDescriptor>

    </Parameter>

Los parámetros de vuelta en este caso llevan asociados dos elementos importantes que son el TypeReflectorTypeName y el TypeName estos se encargarán de instanciar los elementos devueltos, IDataReader que será una colección de IDataRecords., el resto es simplemente la definición de cada uno de los tipos que son devueltos dentro del CustomerDataRecord.

    <Parameter Direction=»Return» 

       TypeReflectorTypeName=»Microsoft.Office.Server.ApplicationRegistry.Infrastructure.DotNetTypeReflector» Name=»Customerss«>

      <TypeDescriptor 

       TypeName=»System.Data.IDataReader, ….» IsCollection=»true» Name=»CustomersDataReader«>

        <TypeDescriptors>

          <TypeDescriptor TypeName=»System.Data.IDataRecord, ….» Name=»CustomersDataRecord«>

            <TypeDescriptors>

              <TypeDescriptor TypeName=»System.String» IdentifierName=»CustomerID« Name=»CustomerID» />

              <TypeDescriptor TypeName=»System.String» Name=»CompanyName» />

              <TypeDescriptor TypeName=»System.String» Name=»ContactName» />

              <TypeDescriptor TypeName=»System.String» Name=»ContactTitle» />

              <TypeDescriptor TypeName=»System.String» Name=»Address» />

              <TypeDescriptor TypeName=»System.String» Name=»City» />

              <TypeDescriptor TypeName=»System.String» Name=»Region» />

              <TypeDescriptor TypeName=»System.String» Name=»PostalCode» />

              <TypeDescriptor TypeName=»System.String» Name=»Country» />

              <TypeDescriptor TypeName=»System.String» Name=»Phone» />

              <TypeDescriptor TypeName=»System.String» Name=»Fax» />

            </TypeDescriptors>

          </TypeDescriptor>

        </TypeDescriptors>

      </TypeDescriptor>

    </Parameter>

  </Parameters>

Aquí están esos dos métodos, Finder y SpecificFinder que son necesarios para que nuestro método pueda ser usado con el Business Data Viewer webpart, el Finder es una instancia que usará el webpart para devolver datos de manera genérica, y SpecificFinder para devolver una única instancia.

   <MethodInstances>

    <MethodInstance Type=»Finder» 

	ReturnParameterName=»Customerss« 

	ReturnTypeDescriptorName=»CustomersDataReader« 

	ReturnTypeDescriptorLevel=»0″ Name=»ClientesFinder«>

    </MethodInstance>

    <MethodInstance Type=»SpecificFinder» 

	ReturnParameterName=»Customerss« 

	ReturnTypeDescriptorName=»CustomersDataReader« 

	ReturnTypeDescriptorLevel=»0″ Name=»ClientesSpecificFinder«>
    </MethodInstance>

  </MethodInstances>

</Method>

Actions – Las acciones que se pueden llevar a cabo en una entidad, aquí podemos asociar a unos determinados campos una serie de acciones posibles. Este mecanismo se realiza pasando los parámetros en la Url. (Más adelante veremos tambien como recojer esos parametros).

Position, indica la posición de esa acción en el menú. Url, la url en donde se lleva acabo la acción. ImageUrl es el icono que tendrá la acción. Cada acción lleva asociados los parámetros que necesita pasar en la url, como se ve es del tipo String.Format, de manera que el elemento Index=0 será {0} y así sucesivamente y como es lógico se pueden pasar todos los parámetros que sean necesarios. 

<Actions>

  <Action Position=»1″ 

	  IsOpenedInNewWindow=»false» 

	  Url=»http://spsbeta/SiteDirectory/bdc/Pages/VerCliente.aspx?CustomerID={0}» 

          ImageUrl=»/_layouts/3082/images/viewprof.gif» 

          Name=»Ver Cliente» 

          DefaultDisplayName=»Ver cliente»>

   <ActionParameters>

          <ActionParameter Index=»0″ Name=»CustomerID» />

   </ActionParameters>

  </Action>

</Actions>