Migliori pratiche di progettazione dei report

Questo argomento descrive i fattori chiave da considerare quando si usa Application Studio per scrivere report su cubi OLAP.

Considerazioni sul front-end

La tabella mostra le considerazioni chiave per la progettazione dei report front-end:

Considerazione Descrizione
I report contengono iperblocchi nidificati? Un report basato su una slice e in cui gli iperblocchi sono filtrati per escludere, ad esempio, i valori nulli, ha prestazioni migliori. L'utilizzo di Sezionamento comporta una curva di apprendimento e mancano alcune funzioni desiderabili, ma le funzioni disponibili soddisfano l'80% dei casi d'uso.
I report richiedono uno scorrimento verticale? Se sì, inserire un'estensione web di paginazione nei piè di pagina report. Migliora l'esperienza dell'utente e le prestazioni.
I report fanno uso della formattazione condizionale? La formattazione condizionale è una funzione potente, ma va usata con parsimonia a causa del suo effetto sulle prestazioni durante la valutazione delle condizioni. Quando si usa il formato numero, si evita la formattazione condizionale e ci si affida ai formati numero definiti nel database. Application Studio raggruppa le richieste di dati delle formule, che vengono inviate al database OLAP. Il risultato è un'unica query complessiva invece di più query a Celle singole. Le query in cluster sono più veloci dell'accesso a una singola cella. Le formattazioni condizionali e i salti di report non possono essere raggruppati e vengono sempre interrogati come richiesta di una singola cella.
Le relazioni sui fogli di stile sono sovradimensionate? Pensate alla semplicità quando sviluppate nuovi fogli di stile e resistete all'impulso di continuare ad aggiungere contenuto ai fogli di stile esistenti, ove possibile. Il numero di stili aggiunge dimensioni al report.
Sono state specificate le selezioni iniziali per le entità che redige il bilancio? I report si caricano più velocemente se viene memorizzata l'ultima entità visualizzata dall'utente. Se un report viene caricato, ad esempio, a livello di Tutte le entità, devono essere recuperati molti più dati e il caricamento del report richiede più tempo.
Si utilizzano controlli stateless, come gli oggetti Ricerca, piuttosto che controlli basati su viste elenco? I controlli basati sulle viste elenco, come le caselle combinate, recuperano gli elenchi di elementi quando viene caricato un report. I controlli stateless non recuperano elenchi di elementi, il che rende più veloce il loro caricamento.
Testate a fondo i vostri report? È possibile creare report che concatenano stringhe per ricavare gli ID degli elementi, ma se si invia la richiesta al server OLAP per elementi che non esistono, si rischiano errori e timeout. I test devono sempre tenere conto delle impostazioni di protezione dell'utente finale.
Filtri elenco Alcuni tipi di filtro sono più lenti di altri, ad esempio i filtri attributo sono più lenti dei filtri valore. I filtri in generale sono più lenti delle selezioni di strutture. Evitare aree dati di grandi dimensioni nei filtri. Più elementi si selezionano per dimensione, più lento è il filtro.
Azioni globali Considerate l'uso di azioni globali per sottrarre tempo di calcolo ai singoli Report. Le azioni globali vengono eseguite durante la registrazione dell'utente, dopo la creazione di un modello di repository e prima della creazione di qualsiasi motore. I valori delle Variabili globali sono già impostati prima che venga caricato un report.
Variabile report Evitare stringhe di grandi dimensioni nelle variabili.

Indietro, considerazioni ambientali e interpersonali

In un progetto di successo esiste un ciclo di feedback tra gli sviluppatori dei report e gli autori dei cubi. Una cattiva progettazione del cubo è probabilmente il fattore principale di scarse prestazioni. La Tabella mostra i fattori importanti da considerare:

Considerazione Descrizione
Scrittura e test di reportistica con una serie di dati realistici I report in cui le dimensioni comprendono fino a 30 elementi e i cubi includono diverse centinaia di punti dati possono avere buone prestazioni, ma sono difficili da mantenere, a causa dell'ampio set di dati. Importa fare test con Importazioni di dati realistici.
Scrittura di regole OLAP corrette. Un esempio di regola scritta male: [Ricavo] = [Prezzo] * [Quantità] oppure [Account 1] = [Account2} + [Account3] + [Account4] Acquisire familiarità con le migliori pratiche per la scrittura delle regole OLAP. Consultare la documentazione in linea per una guida.
Dimensioni mal strutturate Si consideri una dimensione prodotto con un elemento superiore di Tutti i prodotti, ma 10.000 figli. A un certo punto è probabile che l'utente attivi una richiesta al server OLAP che richiede il recupero di tutti gli elementi e, potenzialmente, la loro visualizzazione. I livelli intermedi rendono più performante un report basato sulla gerarchia.
Numero elevato di utenti Evitate di modificare le dimensioni durante le ore di ufficio, quando il picco di utenti è in linea.
Elementi padre mancanti nelle dimensioni, ad esempio l'elemento "totale anno" Un report che recupera i dati giornalieri in colonne nascoste per sommarli e visualizzarli come totale dell'anno è molto più lento di un report in cui il totale viene calcolato nel database OLAP.
Uso improprio degli attributi Gli attributi possono essere definiti liberamente e utilizzati per filtrare i report, ma i report filtrati hanno prestazioni inferiori rispetto a una gerarchia che raggruppa gli elementi in base ai potenziali valori degli attributi.
Assicuratevi che il server OLAP disponga di una quantità sufficiente di RAM OLAP è un database in-memory. Le query scritte male possono consumare una quantità significativa di RAM. Se il server OLAP è in paging, le prestazioni sono scarse.
Non inserire dati transazionali nei cubi Infor OLAP è ottimizzato per la reportistica a livello di saldo. È possibile creare un report non performante, senza che l'applicazione lo impedisca. Ad esempio, è possibile creare un cubo dettagliato su un file di righe di ordini di acquisto, ma è probabile che non sia performante.
Scrittura di un report negativo come rimedio a breve termine Resistere alle pressioni del progetto per fare qualcosa che crei un rapporto non performante. Mettete per iscritto le vostre preoccupazioni e suggerite delle alternative.
Non memorizzare gli zeri nel cubo Uno zero è un numero che deve essere memorizzato nella memoria OLAP e valutato nei calcoli delle regole, mentre l'alternativa di null non lo fa. È possibile creare un processo di Application Engine in grado di sostituire gli zeri di un cubo con dei nulli.
Il luogo migliore per fare calcoli Ciò dipende da diversi fattori, tra cui la frequenza con cui sono richiesti i valori di calcolo. Queste sono opzioni esemplificative di dove effettuare i calcoli, in ordine di preferenza:
  • Nel sistema d'origine
  • Nell'ambito di un processo di caricamento dei dati
  • Calcolato e memorizzato in OLAP da Application Engine
  • In OLAP con l'uso di Regole Dinamiche
  • Come calcolo (membro della sessione) nel proprio repository
  • In Application Studio come parte di un report
Imposta come predefinito elementi specifici Se non si selezionano elementi predefiniti specifici per le dimensioni gerarchiche, l'elemento superiore viene selezionato come predefinito. Ciò richiede più tempo per reimpostare gli elementi predefiniti. Gli elementi predefiniti sono impostati nelle proprietà estese della dimensione.
L'utilizzo dell'interfaccia XML è più lento rispetto alla comunicazione tramite l'interfaccia incorporata nella versione 11 Per accelerare la comunicazione, si consiglia di non leggere i valori con richieste a una sola cella, ma di inserirli in una o più richieste a OLAP. Questo può essere fatto con la richiesta di lettura del cubo, aggiungendo più tag CellCoordinate.
Usare la paginazione lato server per creare un report che interroghi solo i valori visibili La paginazione nelle pagine di iperblocco avviene sul lato client. Tutte le Celle vengono restituite dal server, ma viene disegnata solo una pagina.

Negli elenchi OLAP utilizzare la funzione subset per l'impaginazione sul lato server.

Negli elenchi relazionali si usano metodi avanzati nelle query per creare sottoinsiemi.
Filtri alle query per evitare di interrogare tutti gli elementi di una dimensione Usare la soppressione dei null per mostrare solo le celle riempite, mostrare tutti gli elementi sotto un certo padre invece di un'intera dimensione. Diminuire il livello iniziale di espansione nei sezionamenti e negli elenchi.
Evitare di assegnare grandi dimensioni all'Asse La quantità Ottimale è di tre dimensioni per asse delle righe, una dimensione per asse delle colonne.