Pubblicazione delle modifiche allo schema

Personalizzazione › Personalizzazione dell'interfaccia Web › Personalizzazione dello schema con Screen Painter Web › Pubblicazione delle modifiche allo schema

Pubblicazione delle modifiche allo schema

Una volta completate le modifiche allo schema, è possibile metterle a disposizione di tutti gli utenti pubblicandole. WSP archivia le tabelle nuove o aggiornate e le colonne rispettivamente Nelle tabelle wsptbl e wspcol del database.

Procedere come descritto di seguito:

Creazione o aggiornamento dei file che descrivono lo schema modificato per il motore oggetti e i programmi di utilità di CA SDM. WSP crea i file seguenti nel motore Web definito dall'opzione wsp_webengine (con impostazione predefinita web:local);

wsp.mods

Descrive tutti i cambiamenti allo schema gestiti da Screen Painter Web per il motore oggetti.

wsp_schema.sch

Descrive tutte le tabelle e le colonne gestite da Screen Painter Web.

wsp_index.sch

Descrive gli indici del DBMS per le tabelle gestite da Screen Painter Web.

wsp.altercol

Assegna il nome alle nuove colonne create da Screen Painter Web ma non ancora definite per il DBMS.

wsp.altertbl

Assegna il nome alle nuove tabelle create da Screen Painter Web ma non ancora definite per il DBMS. Inoltre, Screen Painter Web distribuisce il file wsp.mods a tutti i server CA SDM con un motore oggetti.
Selezionare File, Salva e pubblica.
Questa operazione crea i file necessari sui server di CA SDM ma non li riavvia. Quindi, i nuovi file non hanno un impatto immediato. Tuttavia, una volta creati, i file verranno usati al successivo riavvio dei servizi di CA SDM.
Se si utilizza la configurazione convenzionale, completare i passaggi seguenti:
- Arrestare i servizi di CA SDM sul server primario ed eseguire il comando seguente:
```
pdm_publish
```
  Questo comando modifica il DBMS fisico in modo che contenga le informazioni sul nuovo schema.
  
  Importante: L'esecuzione del processo pdm_publish ha un impatto significativo sugli altri utenti. Verificare di aver pianificato con cura la pubblicazione delle modifiche allo schema. Si consiglia di usare gli ordini di cambiamento CA SDM per pianificare e ottenere l'approvazione alla pubblicazione dello schema pianificato.
Se si utilizza la configurazione con disponibilità avanzata, completare i passaggi seguenti:
1. Eseguire il comando seguente sul server in background per informare tutti gli utenti attivi tramite Support Automation di salvare il loro lavoro:
```
sa_server_notifier [-h] | [-q seconds] | [-c]
```
  -h
  
  Visualizza la pagina della Guida.
  
  -q seconds
  
  Questa opzione avvisa un server locale (background) di rimanere inattivo durante un intervallo di tempo specificato. Questo intervallo è il numero di secondi che trascorrono prima che il server diventi non in linea. Non è possibile utilizzare questa opzione per un server di standby o un server applicazioni.
  
  -c
  
  Questa opzione annulla una richiesta di disattivazione inviata precedentemente.
  
  Un messaggio popup viene ricevuto da tutti gli utenti attivi mediante Support Automation sul server in background. Questo messaggio comunica agli utenti l'arresto del server e il tempo pianificato rimasto prima dell'arresto. Gli utenti devono salvare il proprio lavoro e uscire entro il tempo pianificato.
2. Arrestare i servizi di CA SDM sul server in background.
  Importante: Non riavviare i servizi di CA SDM sul server di standby o sul server applicazioni una volta eseguite le operazioni di salvataggio e pubblicazione da WSP. Così facendo si danneggia la configurazione con disponibilità avanzata. Se i servizi CA SDM sul server di standby o sul server applicazioni vengono interrotti e si desidera avviarli, eseguire il comando pdm_server_control -v sui server per eliminare il controllo versioni prima dell'avvio dei servizi di CA SDM.
  
  Importante: Se il server in background non riesce durante l'attività di pubblicazione, verificare di aver recuperato le modifiche WSP. Per ulteriori informazioni, consultare l'argomento Recupero delle modifiche WSP in fase di errore del server in background.
3. Eseguire il comando seguente sul server di standby che si desidera promuovere a nuovo server in background:
```
pdm_server_control -b
```
  -b
  
  Indica a un server di standby locale di diventare il server in background. Il server di standby deve essere già in esecuzione. Se il server non è in esecuzione, viene avviato ma non viene eseguito nessun failover. Per avviare un failover, eseguire di nuovo il comando.
  
  Il server in background si arresta automaticamente e il server di standby viene promosso a nuovo server in background. Questo cambiamento non interessa le sessioni dell'utente finale. Gli eventuali aggiornamenti in corso vengono archiviati e ritardati, finché il nuovo server in background non passa in linea.
4. Immettere il comando seguente sul server in background originale (ora il server di standby) per aggiornare il DBMS con le modifiche allo schema:
```
pdm_publish
```
  Il comando pdm_publish crea un file di controllo che comporta al prossimo avvio di CA SDM la rimozione della sincronizzazione tra il server di standby e il server in background. Questa azione è necessaria per conservare le modifiche al file di schema apportate con pdm_publish. Il comando permette eventualmente di eseguire un secondo failover dopo la corretta pubblicazione delle modifiche allo schema. Il messaggio seguente viene visualizzato dall'utente una volta completata la pubblicazione:
```
Eseguire pdm_publish per avviare CA Service Desk Manager su questo server di stand-by ed eseguire il failover (S/N)?
```
  - Se si immette S, pdm_publish avvia i servizi di CA SDM sul server di standby ed esegue automaticamente il failover. Saltare al passaggio g per applicare le modifiche dello schema a tutti i server applicazioni.
  - Se si immette N, procedere con il passaggio e.
5. Avviare i servizi di CA SDM sul server di standby (server in background originale).
  All'avvio viene individuato il file di controllo creato da pdm_publish, ma senza sincronizzazione del server di standby con il server in background. La mancata sincronizzazione permette di mantenere le modifiche apportate da pdm_publish per questo avvio.
  
  Importante: Verificare l'esatta esecuzione di queste istruzioni, poiché i servizi risulteranno danneggiati se il failover al server in background originale dopo pdm_publish non è corretto.
6. Immettere il comando seguente sul server di standby (server in background originale) per renderlo di nuovo server in background:
```
pdm_server_control -b 
```
  Questo comando cancella anche il file di controllo, in modo che il controllo versioni funzioni normalmente quando il server in background diventa un server di standby.
7. Immettere il comando seguente sui server applicazioni:
```
pdm_server_control -q interval -s server_name
```
  -q interval -s server_name
  
  Notifica a un server applicazioni locale o remoto di rimanere inattivo in un intervallo di tempo specificato. Questo intervallo è il numero di secondi prima che il server diventi non in linea. Quando si utilizza questa opzione senza un server_name, il server locale viene informato di rimanere inattivo. Non è possibile utilizzare questa opzione per un server in background o di standby.
  
  Un messaggio popup viene visualizzato da tutti gli utenti attivi sul server applicazioni specificato. Questo messaggio comunica agli utenti l'arresto del server e il tempo pianificato rimasto prima dell'arresto. Gli utenti devono salvare il proprio lavoro e uscire entro il tempo pianificato. Gli utenti accedono al server applicazioni aggiornato per riprendere il lavoro.
8. Riavviare tutti i server di standby.