Certificación de conectores de Power Query

  • Artículo

Nota:

En este artículo se detallan los requisitos y el proceso para enviar un conector personalizado de Power Query para la certificación. Lea detenidamente el artículo completo antes de iniciar el proceso de certificación.

Introducción

Con el SDK de Power Query, todos los usuarios pueden crear un conector de Power Query personalizado para conectar un origen de datos de Power Query. En estos momentos, los conectores personalizados solo se admiten en modelos semánticos de Power BI (Power BI Desktop y servicio Power BI) y requieren el uso de una puerta de enlace de datos local para actualizar a través del servicio Power BI. El desarrollador debe distribuir los conectores personalizados de forma individual.

Es posible que los propietarios de orígenes de datos que desarrollan un conector personalizado para su propio origen de datos quieran distribuirlo de forma más amplia a los usuarios de Power Query. Una vez que un conector personalizado se haya creado y los usuarios finales lo hayan usado y validado, el propietario del origen de datos podrá enviarlo para la certificación de Microsoft.

La certificación de un conector personalizado de Power Query dará como resultado que el conector esté disponible públicamente, de forma predeterminada, en modelos semánticos de Power BI (Power BI Desktop y servicio Power BI), flujos de datos de Power BI y datamarts de Power BI. Los conectores certificados se admiten en PowerBI.com y en todas las versiones de Power BI Premium.

Los conectores certificados:

  • Son mantenidos por el desarrollador del partner

  • Son compatibles con el desarrollador del partner

  • Están certificados por Microsoft

  • Son distribuidos por Microsoft

Trabajamos con asociados para intentar asegurar de que tengan soporte técnico en mantenimiento, pero los problemas del cliente con el conector se dirigirán al desarrollador asociado.

Diferencias de conector certificado y conector personalizado

Los conectores certificados se agrupan de forma integrada en Power BI Desktop y se implementan en el servicio Power BI, los flujos de datos de Power BI y los datamarts de Power BI. Los conectores personalizados solo se admiten en modelos semánticos de Power BI y deben cargarse en Power BI Desktop, como se describe en Carga de la extensión en Power BI Desktop. Los conectores certificados y personalizados se pueden actualizar a través de Power BI Desktop o el servicio Power BI mediante una puerta de enlace de datos local con la implementación de TestConnection. La puerta de enlace de datos local es necesaria para conectores personalizados.

Los conectores certificados en Power BI Desktop con una implementación TestConnection también admiten la actualización de un extremo a otro a través de la nube (servicio Power BI) sin necesidad de una puerta de enlace de datos local. El entorno del servicio Power BI básicamente hospeda una "puerta de enlace en la nube" que se ejecuta de forma similar a la puerta de enlace local. Una vez realizada la certificación, se implementará el conector en este entorno para que esté disponible para todos los clientes de Power BI.

Los conectores personalizados y certificados con componentes adicionales (por ejemplo, el controlador ODBC) requieren la instalación del componente adicional en la máquina del usuario final y exigen la puerta de enlace de datos local, a menos que el componente adicional se implemente en la nube de Power BI. En la actualidad, no se certifica ni implementa ningún componente adicional nuevo en la nube de Power BI, por lo que la certificación de conectores con una dependencia en un componente adicional no eliminará el requisito de puerta de enlace de datos local.

Distribución del conector personalizado

Los conectores personalizados pueden y deben distribuirse a los usuarios finales con anterioridad a la certificación.

Debido a que M es un lenguaje versátil que, tal como se ve en Control de la autenticación tiene la capacidad de interactuar con las credenciales almacenadas, es necesario ofrecer a los usuarios una manera de permitir que solo se ejecuten conectores de confianza.

Desde la perspectiva de un desarrollador, los desarrolladores deben registrar el conector personalizado y proporcionar a los usuarios la información (huella digital) para cargarlo de forma segura.

Desde la perspectiva del usuario, se debe utilizar la huella digital del desarrollador para confiar de forma segura y cargar el conector personalizado para su uso. Como alternativa, los usuarios pueden optar por reducir la configuración de seguridad para permitir la carga de código no certificado por Microsoft u otro desarrollador, pero esta opción no se recomienda.

Información general sobre certificaciones

Requisitos previos

Para garantizar la mejor experiencia para los clientes, solo se tendrán en cuenta los conectores que cumplan un conjunto de requisitos previos para la certificación:

  • El conector debe ser para un producto público.

  • El conector debe considerarse de código completo para una versión inicial. El programa permite iteraciones y actualizaciones frecuentes. Debe tenerse en cuenta que Microsoft no ofrece asistencia técnica ni consultoría de desarrollo de conectores personalizados. Se recomienda utilizar los recursos públicos, como la documentación de SDK y el repositorio de ejemplos. Si necesita más ayuda, podemos compartir una lista de consultores de desarrollo de conectores personalizados de terceros, que son conocidos en el sector y que podrá contratar directamente, al margen de cualquier programa o asociación de Microsoft. Tenga en cuenta que Microsoft no está afiliado a ninguno de estos consultores y no es responsable del uso de sus servicios. Microsoft proporciona la lista para comodidad del cliente y sin garantías ni recomendaciones. Para obtener más información, comuníquese con su contacto de certificación de Microsoft.

  • El desarrollador debe proporcionar una estimación del uso. Se recomienda que los desarrolladores de conectores para productos estrella utilicen nuestras funcionalidades de registro de conectores y las ofrezcan directamente al cliente.

  • El conector ya debe estar disponible para los clientes de forma directa para satisfacer la necesidad de un usuario o un escenario empresarial. Estos criterios se pueden cumplir mediante un programa de versión preliminar privada a través de la distribución directa del conector completado a los usuarios finales y las organizaciones a través del registro. Cada usuario u organización debe ser capaz de brindar comentarios y validar la existencia de una necesidad empresarial del conector y que este funcione correctamente para cumplir los requisitos empresariales.

  • El conector debe funcionar correctamente en un nivel previsto de uso por parte de los clientes.

  • Debe haber un subproceso en el foro de ideas de Power BI impulsado por los clientes que indique la petición de que el conector esté disponible públicamente en Power BI Desktop. No hay ningún umbral establecido de involucración. No obstante, a mayor involucración, más fuerte será la petición evidenciada del conector.

Estos prerrequisitos existen para garantizar que los conectores que se sometan a la certificación cuenten con una necesidad significativa por parte del cliente y de la empresa de ser utilizados y admitidos tras la certificación.

Procesos y escalas de tiempo

Los conectores certificados se lanzan con las versiones mensuales de Power BI Desktop, por lo que los plazos para cada versión se remontan a la fecha del lanzamiento de Power BI Desktop. La duración esperada del proceso de certificación desde el registro hasta el lanzamiento varía en función de la calidad y la complejidad del envío del conector. Microsoft no proporciona ninguna garantía de escala de tiempo específica con respecto a las revisiones y aprobaciones del conector. Las fechas límite para cada revisión del conector se describen en los pasos a continuación, pero Microsoft no garantiza el cumplimiento de dichas escalas de tiempo.

  • Registro: notificación de intención de certificar el conector personalizado. Este registro debe producirse el día 15 del mes, dos meses antes del lanzamiento de Power BI Desktop.

    • Por ejemplo, para la versión de abril de Power BI Desktop, la fecha límite sería el 15 de febrero.

  • Envío: envío de archivos de conector para revisión de Microsoft. El envío debe producirse el primer día del mes antes del lanzamiento de Power BI Desktop.

    • Por ejemplo, para la versión de abril de Power BI Desktop, la fecha límite sería el 1 de marzo.

  • Revisión técnica: finalización de los archivos del conector, posterior a la revisión y la certificación de Microsoft. La revisión debe producirse hasta el día 15 del mes antes del lanzamiento de Power BI Desktop.

    • Por ejemplo, para la versión de abril de Power BI Desktop, la fecha límite sería el 15 de marzo.

Debido a la complejidad de las revisiones técnicas y posibles retrasos, rediseño y problemas con las pruebas, se recomienda enviar con una antelación de largo plazo para la versión inicial y la certificación. Si considera que es importante entregar el conector a algunos clientes con una sobrecarga mínima, se recomienda el registro y proporcionarlo de esa manera.

Requisitos de certificación

Tenemos un conjunto de requisitos establecidos para la certificación. Reconocemos que no todos los desarrolladores pueden cumplir dichos requisitos y esperamos introducir en breve un conjunto de características que controle las necesidades del desarrollador.

Archivos de envío (artefactos)

Asegúrese de que los archivos del conector que envíe incluyan lo siguiente:

  • Archivo (.mez) de conector

    • El archivo .mez debe seguir los criterios de estilo y tener un nombre similar a aquel del producto o servicio. No debe incluir palabras como "Power BI", "Connector" o "API".
    • Asigne al archivo .mez el nombre: ProductName.mez

  • Archivo de Power BI Desktop (.pbix) para pruebas

    • Es necesario un informe de Power BI de ejemplo (.pbix) con el que probar el conector.
    • El informe debe incluir al menos una consulta para probar cada elemento de la tabla de navegación.
    • Si no existe ningún esquema establecido (por ejemplo, bases de datos), el informe deberá incluir una consulta para cada "tipo" de tabla que el conector pueda controlar.

  • Prueba de la cuenta en el origen de datos

    • Se utilizará la cuenta de prueba para probar y solucionar problemas del conector.
    • Proporcione una cuenta de prueba que sea persistente, a fin de que podamos utilizarla para certificar las actualizaciones futuras.

  • Instrucciones de prueba

    • Proporcione cualquier documentación sobre el uso del conector y pruebe la funcionalidad del mismo.

  • Vínculos a dependencias externas (por ejemplo, controladores ODBC)

Características y estilo

El conector debe seguir un conjunto de reglas de características y estilo para cumplir unos criterios de facilidad de uso coherentes con otros conectores certificados.

  • El conector DEBE:

  • El FunctionName debe tener sentido para el dominio (por ejemplo, "Contenido", "Tablas", "Documento", "Bases de datos", etc.).

  • El conector DEBE:

    • Tener iconos.
    • Ofrecer una tabla de navegación.
    • Colocar las cadenas en un archivo resources.resx. Las direcciones URL y los valores deben codificarse en el código del conector y no se deben colocar en el archivo resources.resx.

Seguridad

Existen consideraciones de seguridad específicas que el conector debe controlar.

  • Si se utiliza Extension.CurrentCredentials():

    • ¿Es necesario el uso? Si es así, ¿hacia dónde se envían las credenciales?
    • ¿Se garantiza que las solicitudes se realicen a través de HTTPS?
    • Si las credenciales se envían mediante Web.Contents() a través de GET:
      • ¿Se puede convertir en un POST?
      • Si es necesario GET, el conector DEBE utilizar el registro CredentialQueryString en el registro de opciones de Web.Contents() para pasar credenciales confidenciales.

  • Si se utilizan funciones Diagnostics.*:

    • Valide lo que se rastrea; los datos no deben contener PII ni grandes cantidades de datos innecesarios.
    • Si se implementó un seguimiento significativo en el desarrollo, se debe implementar una variable o una marca de característica que determine si el seguimiento debe activarse. Este seguimiento debe estar desconectado antes del envío para la certificación.

  • Si se utiliza Expression.Evaluate():

    • Valide de dónde procede la expresión y de qué se trata (es decir, puede construir dinámicamente llamadas a Extension.CurrentCredentials() y así sucesivamente).
    • El Expression no debe facilitarlo el usuario ni tomar la entrada de usuario.
    • El Expression no debe ser dinámico (es decir, recuperado de una llamada web).

Registro para certificación

Si está interesado en realizar la certificación del conector personalizado, asegúrese de que el escenario y el conector cumplan los prerrequisitos y requisitos que se detallan en este artículo. Si no lo hace, se producirán retrasos en la certificación, ya que nuestro equipo le solicitará que corrija los problemas o incoherencias antes de avanzar con la certificación.

Asegúrese de que el conector tenga el código completo y que se haya probado tanto en la creación en Power BI Desktop como en la actualización y el consumo en el servicio Power BI. Asegúrese de haber probado la actualización completa en el servicio Power BI a través del uso de una puerta de enlace de datos local.

Para empezar, rellene nuestro formulario de registro y un contacto de Microsoft se pondrá en contacto para comenzar el proceso.

Después de la certificación

Una vez certificado y lanzado el conector a través de Power BI Desktop y servicio Power BI, hay algunas cosas que debe hacer para asegurarse de que puede usar correctamente el conector certificado disponible públicamente.

  • Los usuarios finales y usted deben usar la versión del conector certificado incluida en Power BI Desktop y la puerta de enlace de datos local, y eliminar los archivos .mez o .pqx existentes (conectores personalizados) usados antes de la certificación. Si no lo hace, es posible que Power Query use accidentalmente el conector personalizado de prueba en lugar del conector recién certificado.
  • Los conectores personalizados solo se deben usar para probar las nuevas versiones del conector.
  • Al trabajar con los usuarios finales y los clientes, asegúrese de que comprenden que la versión del conector personalizada que se usa en las pruebas anteriores a la certificación debe eliminarse una vez completada la prueba y la nueva versión del conector certificado está disponible.

Una vez que haya desarrollado un conector para un origen de datos, tenga en cuenta la posibilidad de ayudar a los clientes a ponerse en marcha rápidamente a través de la creación de una aplicación de plantilla. Una aplicación de plantilla ofrece a los clientes un informe preelaborado que está conectado a sus datos y que pueden utilizar directamente o personalizar según sea necesario.

Nota:

Las aplicaciones de plantilla no admiten conectores que requieran una puerta de enlace.