Estas son algunas respuestas a preguntas comunes que pueden producirse al desarrollar conectores personalizados de Power Query.
Más allá de los patrones de advertencia documentados, actualmente no proporcionamos una manera de devolver advertencias fuera de banda, como una advertencia de tabla grande o de metadatos grandes.
¿Es posible presentar información de partición de tabla agregando otro nivel a la jerarquía de navegación y permitir que los usuarios seleccionen una o varias particiones?
Es posible si los usuarios finales a menudo desean recuperar una sola partición de datos. Sin embargo, esta funcionalidad no se puede agregar a un conector ya existente. En esencia, este cambio estropearía un conector ya existente.
El conector personalizado que he estado desarrollando funciona bien en Power BI Desktop. Pero cuando intento ejecutarlo en el servicio Power BI, no puedo establecer credenciales ni configurar el origen de datos. ¿Qué ocurre?
Puede haber varias razones por las que observa este comportamiento. Algunos errores comunes que pueden producirse al ejecutar el conector en el servicio Power BI son:
- Error al actualizar las credenciales del origen de datos
- Se produjo una excepción al intentar obtener
OAuthProvider
deDataSourceReference
- No se admite el tipo de origen de datos especificado
Antes de empezar a solucionar este comportamiento, recopile una copia del conector personalizado (archivo .pq o .mez). Si tiene un archivo .mez, cambie el nombre del archivo a .zip y extraiga el archivo .pq.
Para solucionar problemas del conector personalizado:
Abra el archivo de conector personalizado (.pq) en un editor de texto de su elección.
Busque la función
TestConnection
. La funciónTestConnection
es necesaria para la actualización programada en el servicio Power BI, pero no se usa en Power BI Desktop. Compruebe el archivo .pq de una implementación deTestConnection
y confirme que los parámetros coinciden con la función del origen de datos del conector. Más información: Control de compatibilidad con puerta de enlaceSi el conector usa OAuth, compruebe el parámetro
state
. Una causa común de errores de solo servicio es que falta un parámetrostate
en la implementación del conectorStartLogin
. Este parámetro no se usa en Power BI Desktop, pero es necesario en el servicio Power BI. El parámetrostate
debe pasarse a la llamada a Uri.BuildQueryString. En el siguiente ejemplo se muestra la implementación correcta destate
.
StartLogin = (resourceUrl, state, display) =>
let
authorizeUrl = authorize_uri & "?" & Uri.BuildQueryString([
response_type = "code",
client_id = client_id,
state = state, //correct implementation
redirect_uri = redirect_uri,
resource = resource
])
in
[
LoginUri = authorizeUrl,
CallbackUri = redirect_uri,
WindowHeight = 720,
WindowWidth = 1024,
Context = null
];
Cuando se abre un esquema o una base de datos en el navegador de Power Query, comienza a obtener inmediatamente todas las tablas de la base de datos en lugar de esperar a que se seleccione una tabla. ¿Qué causa este comportamiento?
Este comportamiento podría ser un efecto secundario de la forma en que crea la tabla de navegación. Si va a crear nuevos registros con Table.TransformRows, este uso suele provocar una evaluación diligente de las tablas de datos. Sin embargo, los valores generados por Table.AddColumn se producen de forma diferida. Por lo tanto, en el código de ejemplo siguiente, "each GetSchemas(url, [name])" no se evaluará a menos que la consulta del usuario haga referencia a estos datos.
GetShares = (server_host as text) as table =>
let
url = server_host & "/shares",
shares = GetItems(url),
withData = Table.AddColumn(shares, "Data", each GetSchemas(url, [name])),
withItemKind = Table.AddColumn(withData, "ItemKind", each "Folder"),
withItemName = Table.AddColumn(withItemKind, "ItemName", each "Folder"),
withIsLeaf = Table.AddColumn(withItemName, "IsLeaf", each false),
renamed = Table.RenameColumns(withIsLeaf, {{"name", "Name"}, {"key", "Key"}}),
navTable = Table.ToNavigationTable(renamed, {"Key"}, "Name", "Data", "ItemKind", "ItemName", "IsLeaf")
in
navTable;
Una sola tabla puede constar de varios archivos con particiones. La implementación actual descarga todos los archivos antes de mostrar una versión preliminar. ¿Hay alguna manera de evitar la descarga de todos los archivos y solo descargar archivos hasta que haya suficientes filas para la versión preliminar?
Este comportamiento es un efecto secundario del uso de Table.Combine. Un método alternativo consiste en crear una "tabla de tablas" y usar la función Table.ExpandTableColumn. Este método expande de forma diferida las particiones según sea necesario. Por ejemplo:
GetFiles = (tables_url as text, table_name as text) as table =>
let
// parse raw ndjson and get the list of parquet files
// resp format: line 1: protocol, line 2: schema, line 3..:file info
resp = Lines.FromBinary(SendRequest(tables_url & "/" & table_name & "/query", [
Headers= [#"Content-Type"="application/json"],
Content= Text.ToBinary("{}")
]), null, null, 1252),
protocol = resp{0}, // TODO: Add protocol version check
schema = Json.Document(Json.Document(resp{1})[metaData][schemaString])[fields],
columnNames = List.Transform(schema, each [name]),
fileInfos = List.Range(resp, 2),
fileUrls = List.Transform(fileInfos, each Json.Document(_)[file][url]),
numFiles = List.Count(fileUrls),
toTable = Table.FromList(fileUrls, Splitter.SplitByNothing(), {"FileUrl"}),
processPartition = Table.AddColumn(toTable, "Data", each Parquet.Document(Binary.Buffer(ProtectSensitiveQueryParameters([FileUrl], [ManualCredentials = true])))),
removeFileUrl = Table.RemoveColumns(processPartition, {"FileUrl"}),
expanded = Table.ExpandTableColumn(removeFileUrl, "Data", columnNames)
in
if numFiles = 0 then #table(columnNames, {}) else expanded;
ProtectSensitiveQueryParameters = (url as text, options as record) =>
let
uriParts = Uri.Parts(uri),
uriWithoutQuery = Uri.FromParts(uriParts & [Query = []]),
modifiedOptions = options & [
CredentialQuery = uriParts[Query],
]
in
Web.Contents(uriWithoutQuery, modifiedOptions);
Nota
Los problemas de desarrollo de conectores personalizados se encuentran fuera del ámbito y experiencia del Soporte técnico de Microsoft. Si necesita ayuda para desarrollar el conector personalizado o tiene comentarios, sugerencias o errores que le gustaría notificar, visite nuestro repositorio público oficial en GitHub o consulte a su contacto de Microsoft si está interesado en participar en un consultor de desarrolladores de conectores personalizados externos recomendados.