Si lavora in tutta sicurezza con un clustering chiuso, che più utenti hanno aperto contemporaneamente. La visualizzazione dei risultati aggiorna, in seguito alle modifiche, i dati dell’albero e dei componenti salvati, in modo che nessun utente continui a lavorare con informazioni non aggiornate.
Per questa procedura sono necessarie due sessioni indipendenti e con accesso effettuato con clustering-view e clustering-edit. Utilizzate un clustering completato con un cluster di fogli pieno e uno vuoto, che può essere rimosso. Le modifiche riguardano i dati salvati; per le analisi o la formazione, utilizzate dati che possono andare persi.
Una sessione indipendente è un profilo del browser registrato separatamente o un contesto del browser autonomo. Due schede della stessa sessione del browser non costituiscono utenti indipendenti.
Elaborazione simultanea – Comandi, significato e decisioni durante il funzionamento
Lasciare aperto lo stesso clustering completato in entrambe le sessioni di elaborazione quando si sincronizza una modifica. Una modifica dello stato dei componenti viene salvata tramite la richiesta del rispettivo operatore ; successivamente, l'albero, i componenti selezionati e gli indicatori vengono ricaricati . Se il server accetta modifiche concorrenti in successione, entrambe le sessioni mostreranno, dopo il loro prossimo aggiornamento, lo stato salvato per ultimo.
Il server può rifiutare una modifica perché i dati sottostanti sono cambiati. In tal caso, la vista dei risultati ripristina lo stato attuale del server prima di visualizzare l’errore dell’azione. Le schede dei componenti, l’albero, la «Panoramica» e il grafico descrivono quindi la stessa revisione salvata, anziché mostrare totali obsoleti.
Le modifiche all' albero seguono lo stesso principio. La rimozione di un cluster vuoto aggiorna la gerarchia e i dati dei risultati correnti. Una sessione in cui il nodo rimosso era ancora selezionato deve ricaricare la pagina prima di poter proseguire; l’applicazione rimane utilizzabile in un contesto ad albero esistente, anziché considerare il nodo rimosso come valido.
L' area di lavoro legge la gerarchia e i dati attuali dei cluster come un'unica revisione dei risultati. Se le risposte fanno temporaneamente riferimento a revisioni diverse, perché un altro utente modifica il clustering, l'applicazione ripete il caricamento congiunto alcune volte. Una richiesta più recente sostituisce una precedente in sospeso, in modo che nessuna risposta obsoleta sovrascriva una selezione più recente.
Se non è possibile caricare un risultato coerente, la pagina mostra il messaggio di errore relativo alla coerenza con l’azione “Reload”. «Reload» richiede nuovamente il contesto attualmente selezionato. Anche gli errori di trasmissione compaiono in questa sede; essi non vengono ripetuti automaticamente come le revisioni divergenti.
In caso di revisione obsoleta di un'anteprima, il grafico gerarchico richiede lo stesso aggiornamento del risultato. Leggere il grafico solo dopo che l'albero e i dati del risultato sono stati aggiornati.
Una volta completato l'aggiornamento, entrambi gli utenti lavorano con lo stato di clustering salvato. Un'operazione rifiutata, sostituita o obsoleta non causa una visualizzazione errata: l' area di lavoro mostra l'errore, se necessario, e offre un'azione per ricaricare; l’albero, le schede dei risultati, la «Panoramica» e il grafico tornano a uno stato coerente e aggiornato.
Non inserire dati di accesso nella documentazione, nei file sorgente, nei log o nelle richieste di assistenza.
Se un’operazione in corso si comporta in modo inaspettato, annotare il clustering interessato, gli ultimi due stati osservati e il testo dell’errore visualizzato.
Questa procedura è stata verificata sulla base del codice sorgente ed è descritta solo sotto forma di testo . Non è stata testata con un'esecuzione nel browser e non contiene, di proposito, alcuna schermata.
