Direcciones URL de otros informes

[Syndicate_Admin]

Necesito a alguien más inteligente que yo para explicar lo que está sucediendo aquí y si hay alguna manera de resolverlo.

Estamos buscando crear un informe que se vincule a un montón de otros informes basados en datos que salen de RestAPI. Mi idea era crear direcciones URL concatenando las partes genéricas de la dirección URL de un informe con el espacio de trabajo y los identificadores de informe de otros informes. Esto funciona, hasta cierto punto, pero estoy confundido por los controles de seguridad que estoy recibiendo. Soy administrador, así que tengo acceso a todo lo que hay dentro del inquilino.

He estado jugando y estoy obteniendo resultados diferentes por razones aparentemente arbitrarias:

• Si construyo una URL dentro del Bloc de notas y la copio en la barra de direcciones, el informe se abre bien;
• Si abro un informe y cambio el espacio de trabajo y los ID de informe de la barra de direcciones por los de otro informe, se activa una comprobación de seguridad y me indica que necesito solicitar acceso, incluso si es mi informe;
• Si creo una columna personalizada que concatena datos para formar una dirección URL para cada informe de la tabla y asigno una dirección URL a un botón, se activa la comprobación de seguridad, de nuevo, incluso si es mi informe;
• Si creo una columna personalizada en la que cada entrada es la misma URL para un solo informe, pero copio y pego la URL en el generador de columnas, luego la asigno a un botón, el informe se abre bien.

¿Alguien puede explicar lo que está pasando? Sé que la página en la que se abre el informe puede cambiar la "ReportSection?" de una URL, pero eso no parece estar causando el problema.

[Syndicate_Admin]

Oh, Dios mío, ahora que lo mencionas, me encontré exactamente con lo mismo cuando intenté relacionar tablas en el ID del informe, con el caso que no coincide en varios lugares, ¡me olvidé totalmente de eso!

[Syndicate_Admin · Accepted solution]

LO ARREGLADO!!!!!! Fue un error estúpido en el formato, pero solo en el informe, no en los datos subyacentes. También fue un error estúpido de mi parte por no ser coherente.

Entonces, básicamente lo que estaba sucediendo es que todos los datos se extraían correctamente de RestAPI y la concatenación funcionaba bien. PERO, cuando los datos pasaban de PowerQuery al informe, la columna ReportID cambiaba todas las letras del identificador a mayúsculas. Esto significaba que las direcciones URL del informe eran visualmente diferentes de las de PowerQuery. Por ejemplo, en PQ, el ID del informe se veía así:

1a23bc4d-56gh...

Pero cuando llegó al informe real, se veía así:

1A23BC4D-56GH...

Esto significaba que cuando PBI intentaba abrir el informe tenía un espasmo porque la identificación del informe no era del todo correcta, a pesar de tener las mismas letras.

Mi error al tratar de entenderlo fue que, al probar qué demonios estaba pasando, estaba sacando las urls de diferentes lugares. Entonces, al probar el lado de Sharepoint, estaba extrayendo las urls del informe (las había cargado en una matriz) para que no funcionaran, pero cuando las estaba comparando (como en los ejemplos que di en mi respuesta anterior) las estaba extrayendo de PQ, que parecía correcto. Literalmente, acabo de notar en los últimos 10 minutos que el caso de la identificación del informe estaba equivocado en el informe.

¿Por qué está sucediendo? Ni idea. Pero, lo he solucionado simplemente agregando un paso 'Transformar>minúsculas' tanto en la columna ReportID como en la columna URL personalizada dentro de PQ. Nada cambia en PQ, pero ahora llega correctamente al informe.

Gracias @christinepayton por responder. Si no hubiera mencionado que funcionó para usted y tal vez la estructura de la URL era incorrecta, no habría pasado esta mañana mirándola.

[Syndicate_Admin]

@christinepayton gracias por la respuesta.

Entonces, como ejemplo, esta es la estructura de URL anónima (simplemente reemplazó todos los números con un 1) de un informe si lo abro a través del servicio (sé que no podría abrir el informe de todos modos, pero lo anonimicé para que nuestra TI no me asesine):

https://app.powerbi.com/groups/11a11111-c111-11ag-a1gt-b1f1b111f1b1/reports/1ff11ee1-1ebe-1111-11b1-...

y aquí está la misma url (anonimizada de la misma manera que la anterior) creada por mí dentro de PowerQuery:

https://app.powerbi.com/groups/11a11111-c111-11ag-a1gt-b1f1b111f1b1/reports/1ff11ee1-1ebe-1111-11b1-...

La fórmula al crear la columna url es simplemente una fórmula de concatenación:

"https://app.powerbi.com/groups/"&[WorkspaceId]&"/reports/"&[ReportId]&"/ReportSection?experience=power-bi"

¿Hay alguna función que debería agregarle o un sufijo para que reconozca al usuario? Como dije, tengo acceso a todos los informes con los que estoy probando esto y algunos de ellos los creé, pero termino con un mensaje de verificación de seguridad y luego el cuadro de permiso a continuación. Sucede si abro desde el escritorio o un informe publicado en servicio.

Obviamente hay algo que no estoy haciendo correctamente porque lo probé esta mañana.

con Sharepoint. Abrí el informe anterior, copié la URL de la barra de direcciones (la primera opción anónima anterior) y luego la asigné a un botón en una página básica de Sharepoint. Al hacer clic en el botón, se abrió el informe. Pero, si copié la url que construí (la segunda opción anónima anterior), que a mis ojos parece idéntica, y la asigné al botón, obtengo la ventana de permiso.

[Syndicate_Admin]

¿Podría publicar un ejemplo de su enlace concatenado o la fórmula que está utilizando? Hice exactamente a lo que te refieres en el pasado con los datos de la API de PBI y no me hizo esto, por lo que puede ser un problema con tu estructura de URL. Aunque tenga en cuenta que los administradores no tienen acceso automático a todo lo que hay en el inquilino, aún tienen que estar en el área de trabajo para ver las cosas (esto es cierto para la mayoría de las áreas de M365, como los administradores de SharePoint no tienen acceso a todos los sitios de SharePoint de forma predeterminada a menos que se agreguen a él).