Obtener datos de la fuente ODATA con una llamada a la API: ¿por qué cada celda recibe una llamada a la API?

Hola @Mornagli,

¿Quería seleccionar varias tablas en el panel de navegación para obtener datos de la fuente de datos al mismo tiempo?

AFAIK, current power bi dividirá estas tablas en múltiples tablas de consulta y cada tabla incluye un conector de datos para obtener datos de su fuente de datos.

Para este escenario, puede intentar modificar su cadena de conexión para obtener datos del nivel principal para extraer la lista de la tabla para encender bi. Luego, puede crear tablas de consulta para hacer referencia a partir de las subtablas que se almacenaron en las listas de la tabla principal.

Saludos,

Xiaoxin Sheng

Hola @ v-shex-msft, el proceso que hago es:

– Con el conector MPBI a la alimentación ODATA, inserto la url msin de nuestra API y obtengo todas las tablas en Power Query.

– Entonces tengo una tabla específica – subtabla que quiero expandir.

– Si amplío esta subtabla, lleva algo de tiempo pero funciona, pero …

– Cuando hago clic en ‘cerrar y aplicar’, nuestro servidor tiene problemas y los datos no se cargan …

Quiero entender por qué veo que para cada celda, el MPBI envía una llamada a la API, por qué después de insertar la URL y obtengo mis tablas en Power Query, el MPBI no usa los valores de manera local, parece que MPBI envía una gran cantidad de API llamadas ….
En resumen, ¿puedo hacer solo dos llamadas a la API?

El primero con la URL y luego cargo las tablas que quiero Power Query.

Y la segunda llamada a la API, When i Expand.

El servidor API no puede manejar con 50,000 llamadas en un par de segundos …

Agrego mi código que cambié manualmente los datos, tal vez borre algunas cosas:

Gracias.

Hola @Mornagli,

>> El primero con la URL y luego cargo las tablas que quiero Power Query.

Desafortunadamente, no creo que puedas personalizar estas partes. Estas operaciones son procesadas por el propio motor de consulta de energía y no ha brindado las opciones para optimizarlas.

Para este escenario, me gustaría sugerirle que haga estas operaciones (coloque datos y expanda la tabla) fuera de power bi y solo use power bi para obtener datos de las tablas de datos de resultados.
Como sabe, power bi es una herramienta de informes, por lo que puede que no sea buena en todas las situaciones. En mi opinión, el uso de herramientas adecuadas para manejar las operaciones correspondientes debería ser simplemente la fuerza lograda por otras herramientas.

Saludos,

Xiaoxin Sheng

Gracias @ v-shex-msft.
Si primero cargaré la tabla sin Expandir la subtabla, haga clic en cerrar y aplicar.
abd, luego abriré nuevamente la consulta de energía y expandiré la subtabla.
¿Esto dividirá la cantidad de llamadas a la API en dos? ¿O en el segundo, la tabla principal también necesitará llamadas a la API nuevamente?

Y si encuentro una manera de extraer la tabla principal para cada año por separado, entonces tendré un par de tablas pequeñas cargadas y expandidas (de esta manera, creo que la API manejará las llamadas).
Y luego los combinará en uno grande, ¿es posible? o puede causar problemas en el futuro si deseo una actualización incremental y más …?

Gracias.

Hola @Mornagli,

# 1, estas operaciones de referencia de subconsultas también redirigirán a la tabla de datos principal y activarán las solicitudes a su base de datos.

# 2, si los registros de subnivel aún están comprimidos y almacenados en las tablas de datos de origen, es posible que no mejoren el rendimiento.
Aquí hay algunos comentarios detallados sobre mi sugerencia:

Puede dividir los pasos de obtención de datos para agregar una ‘capa de tránsito’ que extrae los datos de origen del origen de datos raíz y los almacena en archivos o fuentes de datos independientes. (esta parte debe ser transacciones programadas utilizadas para sincronizar datos automáticamente)
Luego, puede usar un conector de datos de consulta de energía para obtener datos de la ‘capa de tránsito’ en lugar de ‘nivel raíz’, esto debería reducir el acceso para equilibrar la carga de trabajo de su base de datos de origen.

En resumen, estos pasos se utilizan para dividir los procesos en una arquitectura simple de varios niveles. (power bi report <-refresh Scheduler-> fuente de datos independiente <-auto-sync-> base de datos)

Las solicitudes de Power Bi se bloquearán en la «capa de tránsito» y no afectarán directamente a la fuente de datos raíz. (aviso: estas operaciones pueden causar el retraso en la actualización de datos debido a la ‘capa de tránsito’ adicional)

Saludos,

Xiaoxin Sheng

Gracias ! @ v-shex-msft,
¿Puede dar más detalles sobre el proceso de la ‘capa de tránsito’? Suena como una buena idea para resolver mi problema, pero ¿cuáles son los pasos que debo seguir?

Gracias.

Hola @Mornagli,

El nivel medio debe ser una base de datos o un archivo independiente que pueda exportar datos de la base de datos sin procesar o crear un flujo de datos / servicio web para invocar la API para extraer datos de la base de datos y luego sincronizarlos con la base de datos de destino.
La forma más sencilla es exportar datos a Excel, CSV u otros tipos de archivos, luego puede usar power bi para obtener datos de estos archivos exportados.

Saludos,

Xiaoxin Sheng