Contesto: JMP 17
Ciao a tutti,
Sto lavorando a un progetto di dashboard in cui utilizzo una funzione per generare una serie di grafici diversi che vengono inseriti in una grande griglia consultabile dall'utente. Questa funzione gestisce la generazione dei grafici e ha una propria clausola Where() per selezionare da una tabella dati più ampia che contiene molti altri dati. La griglia di grafici si trova quindi all'interno di un filtro dati locale, così posso effettuare un filtraggio di alto livello in base all'annata dei dati. Tutti i grafici vengono ricalcolati automaticamente, in modo che l'intera dashboard risponda come desiderato.
Il passo successivo consiste nell'includere un set di statistiche di riepilogo personalizzate (le statistiche di riepilogo della piattaforma di tracciamento non sono sufficienti) per ciascun grafico. Non ho problemi a utilizzare la stessa clausola where dei grafici per creare un sottoinsieme in base al parametro specifico, ma le statistiche di riepilogo devono anche tenere conto dello stato dell'LDF e aggiornarsi di conseguenza, ed è qui che ho difficoltà.
Il mio primo tentativo di risolvere il problema consiste nel sottoinsiemare la tabella Big Data con la stessa clausola where del grafico associato, quindi eseguire un Summary() su quel sottoinsieme e seguire il riepilogo derivando nuove colonne, rinominando quelle vecchie, pulendolo, ecc. e quindi sputare il risultato con Get As Report(), impacchettandolo con il grafico, racchiudendo sia il grafico che le statistiche in una V Splitter Box e quindi restituendo tale V Splitter Box da inserire nella griglia della dashboard. Tuttavia, questo approccio non sembra essere in grado di ricalcolare quando l'LDF viene modificato.
Sto adottando l'approccio sbagliato creando sottoinsiemi, riassumendo e post-elaborando il riepilogo? Esiste un modo migliore per farlo? Esiste un modo per rendere un blocco di codice compatibile con LDF? Anche se funzionasse, sarei costretto a mantenere attivi tutti i piccoli sottoinsiemi e riepiloghi? Potrebbe essere una ragione sufficiente per trovare un approccio alternativo...
Mi dispiace, non ho un modo semplice per includere esempi di codice, quindi al momento sto solo cercando una direzione architettonica.
Grazie!
Hai verificato se Tabulate/Distribution con statistiche di riepilogo personalizzate sarebbe sufficiente? Potresti anche usare << Make Filter State Handler.
Grazie per il contributo. Le statistiche di riepilogo personalizzate mi sembrano un vicolo cieco perché devo integrare anche i valori dei criteri di successo in ogni riga (essenzialmente limiti di controllo, ma non sono codificati come limiti di controllo nella tabella, provengono da un altro file).
Intendevi "Make Filter Change Handler"? È l'unica voce che ho trovato nell'indice degli script. Forse c'è stato un cambio di nome?
Grazie
Sì << Crea gestore delle modifiche del filtro (il gestore dello stato è errato).
