Cosa ha ispirato questa richiesta nella lista dei desideri? Difficoltà con il generatore di flussi di lavoro quando vengono apportate modifiche a tabelle/colonne (tabella non trovata, colonna non trovata, ecc.).
Quale miglioramento vorresti vedere? Vorrei che Workflow Builder utilizzasse maggiormente le variabili in modo nativo. Sia nel backend JMP che nell'interfaccia grafica per gli utenti.
Quando eseguo o condivido un flusso di lavoro e qualcosa come il nome di una tabella cambia, JMP è molto bravo a dare all'utente la possibilità di correggere la differenza. Tuttavia, spesso non è chiaro in quale fase del processo la modifica debba essere corretta, quindi gli utenti, me compreso, potrebbero optare per interrompere il flusso di lavoro e provare un'altra strada (aspetta, cosa si aspettava JMP che non c'era, come faccio a correggerlo? ecc.).
E quando vado a vedere cosa succede, magari trovo qualcosa di errato o che dovrebbe essere dinamico. Bene, ora devo rivedere e correggere TUTTE le aree in cui un riferimento a una colonna o a una tabella dati è stato codificato in modo rigido. Se JMP lo avesse semplicemente impostato come variabile fin dalla sua prima implementazione, avrei modificato un punto e avrei finito.
Inoltre, potrei sapere fin dall'inizio di un flusso di lavoro che elementi come i nomi delle tabelle dati o le colonne potrebbero essere variabili. Rendere semplice l'aggiunta di variabili al flusso di lavoro, da impostare come predefinite o da richiedere all'utente, diventa quindi estremamente utile.
Perché questa idea è importante? Workflow Builder è davvero fantastico e permette di automatizzare i processi senza bisogno di particolari conoscenze di scripting, e se non si apportano modifiche funziona benissimo. JMP si comporta già bene quando incontra potenziali differenze, e l'aggiunta di una migliore gestione delle variabili contribuisce a portare tutto questo a un livello superiore. Inoltre, la gestione nativa delle variabili nel processo offrirà un ulteriore "allenamento" a chi si sta familiarizzando con gli script quando questi vengono esportati, poiché invece di vedere valori hardcoded ovunque, sarà chiaro che si stanno impostando variabili e che queste vengono utilizzate in tutto il codice. L'unico inconveniente/modifica? Potrebbe essere che le esportazioni JSL di Workflow Builder debbano creare un proprio spazio di lavoro in cui risiedere (l'ultima cosa di cui abbiamo bisogno è un enorme wrapper "locale" per proteggerci dalle collisioni di variabili).
Sono d'accordo, ci vorrebbe un modo per rendere il Log avanzato e il WFB più generalizzabili. Forse una soluzione semplice potrebbe essere quella di aggiungere un'opzione per far sì che il Log avanzato utilizzi la funzione Current Data Table() invece del riferimento esplicito alla tabella. Mi accorgo che questo rappresenta circa il 90% delle modifiche che devo apportare al JSL creato nel Log avanzato e nel WFB.
Grazie per aver inviato questa richiesta!
