Oltre a facilitare l'istituzione di un sistema di gestione modifiche basato sul ruolo, un flusso di lavoro comune può anche facilitare l'individuazione dell'amministrazione dominio e la gestione delle richieste di replica in un ambiente
distribuito. Ad esempio, se un utente accede a una replica
che risiede a Bangalore, quando l'utente crea una nuova operazione, questa viene controllata
dove è ubicato il proprietario sviluppatore. L'operazione viene creata sul sito Bangalore e quindi replicata. L'amministrazione dominio dell'operazione iniziale è determinata dal proprietario sviluppatore predefinito, indipendentemente
da dove viene eseguito il controllo della richiesta. Tenere presente che:
- Una richiesta deve eseguire la replica su tutti i siti per essere visibile.
- Una richiesta contiene riferimenti alle operazioni associate e le operazioni
contengono un riferimento alla richiesta.
- Ogni operazione viene controllata nel sito del proprietario sviluppatore predefinito una volta che l'operazione è aperta. L'operazione viene controllata nel sito del responsabile QE una volta che l'operazione è attivata.
- L'attività per un'operazione associata viene controllata nel sito del proprietario una volta che è aperta e inoltrata. Lo sviluppatore assegnato è il proprietario dell'attività sviluppatore. Il proprietario sviluppatore predefinito può essere determinato da un valore del campo di progetto, componente o componente secondario. Il proprietario della documentazione predefinito è il proprietario dell'attività di valutazione della documentazione e il proprietario QE predefinito è il proprietario dell'attività di test.
Il paradigma del flusso di lavoro ALM fornisce supporto per lo sviluppo distribuito parallelo. Ad esempio, operazioni create per gestire richieste possono essere esaminate,
per controllarne lo stato di avanzamento, dai richiedenti quando le attività sviluppatore sono complete ma non testate o valutate per la documentazione. Alcune attività sviluppatore possono essere completate e altre ancora aperte mentre l'esecuzione del test può essere effettuata sul lavoro che è completo alla data.
L'ordinamento dei record in un gruppo MultiSite non può essere effettuato in modo che gli utenti che eseguono la stessa query su siti differenti vedano la stessa sequenza di record se i campi da ordinare su una query hanno più di un record con la stessa chiave di ordinamento o valori di chiave di ordinamento concatenati. Ad esempio, se si ordina per nome e due record hanno lo stesso nome, gli utenti di ciascun sito potrebbero non vedere i due record nella stessa sequenza su entrambi i siti. Se si utilizza l'ID record come secondo campo di ordinamento, tenere presente che gli ID sono blocchi assegnati di ID che potrebbero non riflettere l'ordine dei record in fase di inoltro. Se si utilizzano i filtri di cronologia (History.action_name
in ('Copy_Record, 'Import')OR History.old_state = 'no_value'), è possibile richiamare il primo record di cronologia di ciascun record per eseguire l'ordinamento, in questo modo si trova la sequenza assoluta in base alla quale i due record entrano in un gruppo. È possibile utilizzare History.expiration_timestamp
IS NULL per richiamare l'ultima azione di cronologia (History.Action).