Power Query Connector Certification

Nota

En este artículo se describen los requisitos y el proceso para enviar un Power Query conector personalizado para la certificación. Lea todo el artículo con atención antes de iniciar el proceso de certificación.

Introducción

La certificación de Power Query conector personalizado hace que el conector esté disponible públicamente, de forma automática, dentro de Power BI Desktop. Los conectores certificados se admiten PowerBI.com y todas las versiones de Power BI Premium, excepto los flujos de datos. La certificación se rige por el Programa de certificación de conectores de Microsoft, donde Microsoft trabaja con desarrolladores de asociados para ampliar las funcionalidades de conectividad de datos de Power BI.

Los conectores certificados son:

  • Mantenido por el desarrollador asociado

  • Compatible con el desarrollador asociado

  • Certificado por Microsoft

  • Distribuido por Microsoft

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

Los conectores certificados se incluyen de serie en Power BI Desktop. Los conectores personalizados deben cargarse en Power BI Desktop, como se describe en Carga de la extensión en Power BI Desktop. Ambos se pueden actualizar a través de Power BI Desktop o Power BI Service mediante el uso de una puerta de enlace de datos local mediante la implementación de testConnection.

Los conectores certificados con una implementación también admiten la actualización de un extremo a otro a través de la nube (Power BI Service) sin necesidad de una puerta de enlace TestConnection de datos local. El Power BI de servicio local hospeda básicamente una "puerta de enlace en la nube" que se ejecuta de forma similar a la puerta de enlace local. Después de la certificación, implementaremos el conector en este entorno para que esté disponible para todos Power BI clientes. Hay requisitos adicionales para los conectores que necesitan usar componentes adicionales, como un controlador basado en ODBC. Asegúrese de ponerse en contacto con su contacto de Microsoft si el conector requiere el uso de componentes adicionales.

Seguridad y firma del conector personalizado

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

Desde la perspectiva de un desarrollador, los desarrolladores deben firmar automáticamente su conector personalizado y proporcionar a sus usuarios la información (huella digital) para cargarlo de forma segura.

Desde la perspectiva de un usuario, los usuarios deben usar 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 su configuración de seguridad para permitir la carga de código no certificado por Microsoft u otro desarrollador, pero esto no se recomienda.

Introducción a la certificación

Requisitos previos

Para garantizar la mejor experiencia para nuestros clientes, solo tenemos en cuenta los conectores que cumplen un conjunto de requisitos previos para la certificación:

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

  • El conector debe considerarse código completo para una versión de lanzamiento inicial. El programa permite iteraciones y actualizaciones frecuentes. Tenga en cuenta que Microsoft no ofrece directamente consultoría técnica para el desarrollo de conectores personalizados. Sin embargo, como parte del programa, Microsoft puede recomendar recursos para que los desarrolladores se impliquen aún más con ellos. Una vez registrado con el programa siguiente, póngase en contacto con su contacto de Microsoft para obtener más información.

  • El desarrollador debe proporcionar una estimación del uso. Se recomienda que los desarrolladores de conectores para productos muy específicos usen nuestras funcionalidades de firma propia del conector para proporcionarlas directamente al cliente.

  • El conector debe estar ya disponible para los clientes directamente para satisfacer una necesidad del usuario o un escenario empresarial. Esto se puede hacer mediante un programa de versión preliminar privada mediante la distribución del conector completado directamente a los usuarios finales y las organizaciones a través de la firma propia. Cada usuario u organización debe ser capaz de proporcionar comentarios y validar que hay una necesidad empresarial para el conector y que el conector está trabajando correctamente para satisfacer sus 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 Power BI Ideas dirigido por los clientes para indicar la demanda de que el conector esté disponible públicamente en Power BI Desktop. No hay ningún umbral establecido de compromiso. Sin embargo, cuanto mayor sea la interacción, mayor será la demanda evidenciada para el conector.

Estos requisitos previos existen para asegurarse de que los conectores que se someten a la certificación tienen una importante necesidad de uso del cliente y de la empresa y se admite la posterior a la certificación.

Proceso y escalas de tiempo

Los conectores certificados se lanzan con versiones Power BI Desktop mensuales, por lo que las fechas límite de cada versión se reecuer tienen lugar a partir Power BI Desktop fecha de lanzamiento. La duración esperada del proceso de certificación desde el registro hasta el lanzamiento varía en función de la calidad y complejidad del envío del conector, y se describe en los pasos siguientes:

  • Registro: notificación de intención para certificar el conector personalizado. Esto debe ocurrir el día 15 del mes, dos meses antes de la versión de escritorio Power BI destino.

    • Por ejemplo, para la versión de Power BI Desktop abril, la fecha límite sería el 15 de febrero.
  • Envío: envío de archivos de conector para revisión de Microsoft. Esto debe ocurrir antes del 1 de mes antes de la versión de escritorio Power BI destino.

    • Por ejemplo, para la versión de Power BI Desktop abril, la fecha límite sería el 1 de marzo.
  • Revisión técnica: finalización de los archivos del conector, pasando la revisión y certificación de Microsoft. Esto debe ocurrir el día 15 del mes anterior a la versión Power BI Desktop destino.

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

Debido a la complejidad de las revisiones técnicas y los posibles retrasos, la nueva arquitectura y los problemas de prueba, se recomienda encarecidamente enviar pronto con un tiempo de ejecución largo para la versión inicial y la certificación. Si cree que el conector es importante para entregarlo a algunos clientes con una sobrecarga mínima, se recomienda la firma propia y proporcionarlo de esa manera.

Requisitos de certificación

Tenemos un determinado conjunto de requisitos para la certificación. Somos conscientes de que no todos los desarrolladores pueden cumplir estos requisitos y esperamos introducir un conjunto de características que controle las necesidades de los desarrolladores en orden breve.

Archivos de envío (Artifacts)

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

  • Archivo de conector (.mez)

    • El archivo .mez debe seguir los estándares de estilo y debe tener un nombre similar al nombre del producto o servicio. No debe incluir palabras como "Power BI", "Connector" o "API".
    • Asigne al archivo .mez el nombre : ProductName.mez
  • Power BI Desktop archivo (.pbix) para pruebas

    • Se requiere un informe Power BI 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 hay ningún esquema establecido (por ejemplo, bases de datos), el informe debe incluir una consulta para cada "tipo" de tabla que el conector pueda controlar.
  • Prueba de la cuenta en el origen de datos

    • Usaremos la cuenta de prueba para probar y solucionar problemas del conector.
    • Proporcione una cuenta de prueba que sea persistente, por lo que podemos usar la misma cuenta para certificar las actualizaciones futuras.
  • Instrucciones de prueba

    • Proporcione cualquier documentación sobre cómo usar el conector y probar su funcionalidad.
  • 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 un estándar de facilidad de uso coherente con otros conectores certificados.

  • El conector DEBE:

  • Debe FunctionName tener sentido para el dominio (por ejemplo, "Contenido", "Tablas", "Documento", "Bases de datos", y así sucesivamente).

  • El conector DEBE:

    • Tener iconos.
    • Proporcione una tabla de navegación.
    • Coloque cadenas en un resources.resx archivo. Las direcciones URL y los valores deben codificarse de forma rígida en el código del conector y no colocarse en el resources.resx archivo.

Seguridad

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

  • Si Extension.CurrentCredentials() se usa:

    • ¿Es necesario el uso? Si es así, ¿a dónde se envían las credenciales?
    • ¿Se garantiza que las solicitudes se realizan a través de HTTPS?
    • Si las credenciales se envían mediante Web.Contents() GET:
      • ¿Se puede cambiar a POST?
      • Si se requiere GET, el conector DEBE usar el CredentialQueryString registro del registro de opciones para pasar credenciales Web.Contents() confidenciales.
  • Si se usan funciones diagnostics.*:

    • Valide lo que se está haciendo seguimiento; los datos no deben contener PII ni grandes cantidades de datos innecesarios.
    • Si implementó un seguimiento significativo en el desarrollo, debe implementar una variable o una marca de característica que determine si el seguimiento debe estar en. Debe desactivarse antes de enviar para la certificación.
  • Si Expression.Evaluate() se usa:

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

Registro para la certificación

Si está interesado en conseguir la certificación del conector personalizado, asegúrese de que el escenario y el conector cumplen los requisitos previos y los requisitos descritos en este artículo. Si no lo hace, se producirán retrasos en la certificación, ya que nuestro equipo le exigirá que corrija cualquier problema o incoherencia antes de avanzar con la certificación.

Asegúrese de que el conector está completo y se ha probado tanto en la creación en Power BI Desktop como en la actualización y el consumo en Power BI Service. Asegúrese de que ha probado la actualización completa de un extremo a otro en Power BI Service mediante el uso de una puerta de enlace de datos local.

Para empezar, complete nuestro formulario de registro yun contacto de Microsoft se pondrá en contacto con para comenzar el proceso.

Una vez que haya desarrollado un conector para un origen de datos, considere la posibilidad de ayudar a los clientes a empezar a ejecutarse rápidamente mediante la creación de una aplicación de plantilla. Una aplicación de plantilla proporciona a los clientes un informe precompilado conectado a sus datos que pueden usar de forma predeterminada o personalizar según sea necesario.

Nota

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