Database exporter – Come ti estraggo i dati dal Cloud

In questo post andremo ad esaminare un addon che ci permette di poter estrarre i dati dal Cloud in modo da permetterci di poter eseguire delle interrogazioni mirate.

Esplorazione alchemica in corso

Una premessa importante

Chi lavora con il Cloud sa perfettamente che quando vogliamo eseguire delle interrogazioni sui dati, la risposta è sempre una. Il seguente memo ce lo spiega

Vediamo di chiarire il punto

Sul Cloud non abbiamo alcuna possibilità: Ci è precluso l’accesso al database interno. Di conseguenza non possiamo fare nulla per lanciare query… almeno fino ad ora.

Abbiamo una soluzione

Inventato da Bob Swift ma adesso sotto il controllo della Appfire, abbiamo un addon che ci aiuta in tal senso, fornendoci la possibilità di costruire un simil-database su cui poter eseguire le nostre interrogazioni.

L’addon di cui parleremo oggi.

Questo addon è nato con l’obiettivo di ricostruire un database simile, rispetto a quello che avevamo a disposizione con la versione onPremise, e permettere agli utenti cloud di riuscire a ricostruire delle query ed interrogazioni.

Fonte Marketplace

Come possiamo vedere dalla precedente immagine, riusciamo a ricostruire sia i dati della parte standard, compresi i campi custom. Dalla documentazione dell’addon abbiamo a disposizione anche uno schema dati che ci spiega come ricostruire le relazioni tra le varie tabelle:

Fonte: Documentazione dell’addon

Possiamo, attraverso questo addon, ricostruire un simil-database (non è proprio il database effettivo: Teniamolo sempre a mente).

L’addon al momento permette di poter estrarre i dati direttamente su di un database Postgresql. Questo ci limita un pò i movimenti, ma non più di tanto. Se in azienda abbiamo uno standard che ci impone l’utilizzo di altre tipologie di Database (ad esempio: In azienda si usano database MS SQL Server). Tuttavia, usando dei server Linux, il problema viene risolto.

Punti di attenzione

Dobbiamo però tenere sempre a mente alcuni punti di attenzione. Ricordiamoci sempre che il nostro Cloud Atlassian è prevalentemente una macchina virtuale localizzata su Internet e di conseguenza abbiamo:

  • Il nostro cloud deve poter accedere al database e di conseguenza questo deve essere raggiungibile da internet
  • Essendo raggiungibile da internet, occorre che questo database sia gestito in maniera opportuna.
  • Non possiamo esporre direttamente i nostri database verso internet
  • Il database da usare deve essere un database che viene immediatamente blindato o svuotato non appena viene compilato

Come si può vedere non si tratta di semplici raccomandazioni, ma di punti di attenzione molto importanti. Se non li rispettiamo abbiamo dei problemi abbastanza seri.

Se perdiamo i dati questa sarà la nostra espressione.

Di conseguenza abbiamo molto da considerare.

La mia esperienza

Ho avuto modo di collaudare questo addon direttamente presso un mio cliente e posso dire che l’addon lavora in maniera egregia. Nel senso che i dati estratti sono effettivamente il clone dei dati. Ma vorrei fare alcune ulteriori considerazioni.

Abbiamo principalmente i dati dello standard

Non ci facciamo illusioni. Non riusciamo a disporre di tutti i dati come nel caso delle nostre installazioni onPremise. Infatti quando possibile, si accedeva anche ai dati degli addon semplicemente andando a leggere le tabelle con prefisso AO%, come riportato in questa documentazione ufficiale Atlassian.

In questo caso l’addon ricostruisce, con buona approssimazione, le informazioni standard e attraverso opportune query, riusciamo a leggere le informazioni che ci servono.

Solo alcuni addon sono disponibili

L’addon riesce a leggere i dati di alcuni addon, come TEMPO TIMESHEET, ma una cosa che ho notato è che le informazioni che sono scaricate sono sotto forma di un JSON che deve essere ‘lavorate’ per poter estrarre i dati che servono.

Possibile eseguire backup totali ed incrementali

E’ possibile eseguire entrambe le modalità. Nel mio caso, potrebbe essere utile eseguire un primo backup generale e poi tutti i backup incrementali. Questo aiuterebbe notevolmente

Conclusioni

Abbiamo un addon interessante ma che deve essere usato con tutti i crismi del caso. Possiamo estrarre i dati che ci interessano e fare le statistiche personalizzate del caso, anche se in ultima istanza suggerisco di appoggiarsi ad appositi tools che permettono di poter portare le informazioni di Jira su PowerBI o QLIK e consentono di gestire le statistiche molto meglio che con un semplice database da rimettere in piedi.

Come sempre riporto le mie indicazioni perché, questo sicuramente lo avrete compreso leggendo i miei post, che è sempre meglio avere più possibilità che solo una possibilità. La libertà di scelta è una arma molto potente che intendo sempre sfruttare e mettere a disposizione, anche quando eseguo le mie consulenze.

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.




Esecuzione di query SQL sotto Confluence – un aggiornamento

Riprendiamo le fila

In questo post andremo a esaminare nuovamente un argomento non indifferente: Visualizzare dati d un database su Confluence. Abbiamo già esaminato questo argomento sui altri post, come quando siamo andati a curiosare su PocketQuery, qualche anno fa.

Quali novità?

Abbiamo identificato un addon, opensource (e questo non è un elemento da sottovalutare), che permette a Confluence di connettersi a databases.

Mette a disposizione una macro che, in base alla configurazione impostata, crea una tabella basata sulla query impostata.

Fantastico… lo provo subito

Lo installiamo come siamo sempre stati abituati. Lo andiamo a cercare nella pagina degli addons

Come vediamo basta solo selezionare Install per procedere con l’installazione ….

… una volta completata l’installazione, l’addon è pronto all’uso

Configurazione

La configurazione è molto semplice e prevede una configurazione generale. Occorre mettere a disposizione la possibilità di poter raggiungere i vari Drivers

Occorre indicare una directory dove sono presenti tutti i vari driver e comunque l’addon ci aiuta in questo.

In aggiunta dobbiamo creare dei database profile, ovvero la configurazine vera e propria per accedere al database

In questo esempio ho inserito la configurazione per accedere allo stesso database di Confluence.

Test

Creiamo una pagina di prova, dove andiamo ad inserire la nostra nuova macro, come mostrato in figura:

Il risultato è mostrato dalla seguente figura:

Conclusioni

S P E T T A C O L O :-D. Abbiamo a disposizione uno strumento molto molto molto interessante e utile. Inserire dei risultati su pagine di Confluence è utilissimo. Come potete vedere ho eseguito il test sul nuoco Confluence 6.7, che ho installato da poco. Quindi questo addon è comunque manutenuto e ben gestito.

Reference

Maggiori informazioni sono reperibili dalla pagina del marketplace.




Un piccolo suggerimento per JIRA Server

Un piccolo suggerimento

In questo post andremo a vedere un semplice trucco, per JIRA Server, che ci permette di poter resettare una password …. quando siamo in emergenza.

 

Scenario

Nel caso in cui non ricordiamo la password di una determinata utenza, e non riusciamo a resettarla attraverso le operazioni standard (non abbiamo il server di posta configurato), siamo un pò nei guai. Se poi si tratta della utenza di amministrazione, siamo parecchio nei guai.

 

Come rimediamo?

Se abbiamo a disposizione JIRA Server, quello che possiamo fare è seguire le indicazioni riportate in questo articolo ufficiale, in cui andiamo a metter mano al database, cercando di prestare la massima attenzione.

ATTENZIONE

Lo so. Sono ripetitivo, ma lo faccio a fin di bene. Quando mettere mano a database, assicuratevi di andare esattamente dove volete intervenire, non toccare le altre parti e …. fare sempre dei backup

Intervento

Se volete resettare la password del vostro utente XXXX, occorre eseguire il seguente SQL, dove possiamo eseguire il reset della password.

update cwd_user set credential=’uQieO/1CGMUIXXftw3ynrsaYLShI+GTcPS4LdUGWbIusFvHPfUzD7CZvms6yMMvA8I7FViHVEqr6Mj4pCLKAFQ==’ where user_name=’XXXX’;

Questo codice permette di resettare la password a sphere, permettendoci di accedere e, successivamente, andare a eseguire il reset con le normali procedure.

 




Tipo Boolean in Oracle – Una piccola digressione

Due parole sul tipo Boolean

In questo post andremo ad affrontare un argomento particolare: parleremo di questo tipo Boolean sotto Oracle.

Esiste il tipo Boolean?

Oracle mette a disposizione il tipo Boolean, ma occorre tenere conto di queste precisazioni:

  • NON E’ usabile nella definizione dei campi della tabella.
  • PUO’ essere usato nel PLSQL.

Se vogliamo utilizzarlo nella definizione di una tabella, come suggerito da Tom Kyle, conviene sostituirlo con il tipo CHAR(1), che presenta le stesse caratteristiche, come mostrato di seguito:

flag char(1) check (flag in ( 'Y', 'N' )),

Il risultato è il medesimo.

Una precisazione

Anche se esiste come datatype, non è possibile usarlo ovunque. PL-SQL ha le sue regole e chi lo usa deve mettersi in testa che si devono seguire. Non si può pretendere che, se altri linguaggi (quali ad es. JAVA) lo consentono, PL-SQL si deve adeguare.

 

Conclusione

Abbiamo visto un piccolo tassello, ma di grande importanza. Questo ci ricorda che ogni linguaggio ha le sue regole e i suoi ambiti di applicazione. Dobbiamo tenerne presente sempre.




Esportazione dati via SQLPLUS

Un suggerimento

In questo post, andremo a vedere un piccolo trucchetto che ho usato per poter esportare dei dati, sopratutto quando si tratta di esportare dati di una certa mole.

 

Andiamo nel dettaglio

L’idea è di fare uso di SQLPLUS, che si presta bene a questo genere di lavori. sfruttando le sue capacità. In particolare ci appoggiamo alla possibilità di poter inviare su file il risultato della esecuzione della query. Stiamo parlando del comando: SPOOL;

 

 

Andiamo nel dettaglio e vediamo come fare.

Una volta definita la query, con tutti i dati che sono necessari. Quindi componiamo la query come segue:

Select <campo1> || <campo2> || ..... || <campon> from .....

oppure come

Select <campo1> || <delimitatore> || <campo2> || <delimitatore> ||  ..... || <campon> from .....

a seconda che si voglia avere una estrazione dove i campi sono a lunghezza fissa (primo caso) o con delimitatore (secondo caso).

A questo punto, vediamo come procedere per avere l’estrazione vera e propria.

Attiviamo SQLPLUS, da riga di comando:

sqlplus <utente>/<password>@<dbsid>

Quindi forniamo la sequenza di comandi:

set heading off
set pagesize 0
set linesize 200
set feedback off
Spool on
Spool <file_destinazione>.txt
<scriviamo la Query, mettendo il ';' finale >
Spool off <da lanciare al termine della esecuzione della query>

sqlplus01

La precedente figura da una idea per capire come procedere. Ovviamente mi sono limitato a eseguire una query di esempio per mostrare il funzionamento.

Conclusioni

Abbiamo un sistema molto semplice per eseguire delle estrazioni dati molto semplici. Il metodo è automatizzabile, creando degli script ad hoc, per semplificarci ulteriormente la vita :-).




FishEye – 2

Approfondiamo Fisheye

In questo post andremo a vedere il funzionamento di Fisheye, in modo da gestire un semplice repository di codice sorgente, proseguendo quanto già discusso nel precedente post.

 

 

Di che cosa abbiamo bisogno?

Sostanzialmente, abbiamo bisogno delle seguenti componenti:

  • Repository SVN
  • FishEye
  • JIRA

Iniziamo

Supponiamo che il sistema sia stato già configurato in modo da avere a disposizione JIRA come repository degli utenti di FishEye.

La prima operazione da eseguire, una volta che FishEye è stato installato, è di eseguire le operazioni di Login come utente amministratore e di configurare un accesso ad un repository. Una volta eseguito l’accesso:

  • Tramite COG menù, accedere alla sezione di amministrazione. Quindi selezionare, da Repository Settings, Repositories:

fish-01

  • Selezionare quindi Add repository

A questo punto, seguire il wizard, in modo da configurare l’accesso di FishEye al repository. Vediamolo nel dettaglio:

fish-02

Specificare la tipologia di repository. Fisheye consente di poter selezionare tra più tipologie (Es. Mercurial, CVS, Subversion, etc).

fish-03

Passare quindi a fornire i parametri di connessione. Questa sezione del wizard varia a seconda della tipologia di repository. Viene quindi data la possibilità di eseguire il test di connessione, prima di andare al passo successivo.

fish-04

Vengono quindi richieste le ultime configurazioni. Confermate anche queste ultime, si è configurato il Repository. Si può procedere alla fase di sincronizzazione. Al termine, si dispone di tutte le informazioni necessarie memorizzate sul DB di FishEye. Questa operazione potrebbe richiedere del tempo e, di conseguenza, occorre attendere che sia terminata prima di eseguire altre operazioni.

Questo è il risultato:

 

Come si può osservare, direttamente da FishEye andiamo a spulciare il codice. Ma questo è solo uno degli aspetti. Una volta collegato a JIRA, possiamo anche a referenziare direttamente il codice sorgente e le variazioni dello stesso da JIRA. Semplicemente, andando a vedere la sezione source, possiamo andare a leggere quali interventi sono stati eseguiti 🙂

fish-05il tutto semplicemente andando a inserire, nel testo delle note a fronte del Commit, la chiave della issue JIRA.  Infatti, usando questa chiave, Fisheye riesce a eseguire il link con la issue JIRA e attiva il TAB source.

 

Conclusioni

Abbiamo visto, in questo post, che cosa consente di fare FishEye nel dettaglio. Nei prossimi post approfondiremo l’argomento con la Code Review (Crucible) e con altre operazioni che sono possibili con Fisheye.

 




Panoramica sulle tabelle di Confluence – 2

Il viaggio continua

Continuiamo in questo post quanto iniziato nel precedente, dove abbiamo iniziato a esplorare l’oscuro arcano delle tabelle di Confluence. Andiamo avanti ed iniziamo ad entrare meglio nelle varie tabelle.

Prendendo spunto dal data model di Confluence, andiamo ad esaminare alcune delle tabelle dello schema.

 

Autenticazione ed utenti

Per gestire l’autenticazione, sono utilizzate le seguenti tabelle:

  • cwd_user
  • cwd_group
  • cwd_membership

Mappano rispettivamente gli utenti e i gruppi di appartenenza. La tabella cwd_membership fornisce l’associazione tra utenti e gruppi. . Qualora Confluence sia collegato ad un LDAP, le informazioni in queste tabelle sono aggiornate costantemente e la gestione della password viene affidata al sistema LDAP. Abbiamo visto un esempio di come andare a referenziare queste tabelle su questo post.

 

Spaces

Le informazioni sugli space sono relegate alla omonima tabella Space. Questa viene referenziata anche sulle altre tabelle, per indicare l’appartenenza dei contenuti.

 

Contenuti

I contenuti sono riportati nelle seguenti tabelle:

  • Content – Referenzia diverse informazioni, distinte in base al campo CONTENTTYPE. In particolare, in questa tabella sono presenti sia le informazioni delle varie pagine, che metadati dell’utente e degli space. Nel caso delle pagine, sono presenti TUTTE le versioni della pagina. Attraverso questa tabella Confluence riesce a fornire le differenze tra pagine.
  • Bodycontent – Referenzia il contenuto delle pagine. Queste sono riportati con i vari TAG usati per definirire formati ed altro.
  • Content_label – Referenzia le etichette che sono agganciati ai vari contenuti, distinti in base al campo LABELABLETYPE. 

Permissions

Le permission sono sparse su diverse tabelle:

  • Spacepermissions – Referenzia le permission che sono state assegnate ad uno specifico SPACE. Sono riportate sia le permission assegnate a GRUPPI che a singoli utenti. Nel caso dei singoli utenti, prestare attenzione a come sono codificati gli utenti stessi. Fare rifermento al precedente post per vedere come referenziare correttamente il tutto
  • Content_perm_set – Referenzia quale pagina dispone di una restrizione. Il dettaglio è riportato nella tabella successiva.
  • Content_perm – Da il dettaglio delle restrizioni della pagina referenziata nella tabella precedente, indicando quali utenti/gruppi sono soggetti alla restrizione.

 

Attachments

Gli attachments sono gestiti attraverso queste tabelle

  • attachments – Referenzia i metadati che sono agganciati ai dati.
  • attachmentdata – Referenzia gli allegati veri e propri, nel caso in cui la configurazione di Confluence preveda che gli allegati siano riportati su DB e non su File System.

Conclusioni

In questo post viene mostrato come sono organizzati i dati. Nei prossimi post cercheremo di fornire una ulteriore spiegazione di come sono collegate le informazioni e di come referenziarle.

 




Accedere ai dati di CONFLUENCE

Scaviamo in profondità

In questo post andremo a vedere, con alcuni esempi, come possiamo accedere ai dati di Confluence e JIRA, lavorando direttamente su DB. In particolare vedremo alcuni esempi di come sono memorizzate le informazioni. In figura vediamo lo schema delle tabelle di Confluence.

 

Perché accedere ai dati?

Prima di iniziare ad esplorare le tabelle dei due sistemi, conviene porsi una domanda fondamentale: Perché dobbiamo accedere direttamente ai dati del DB? Quale è la necessità?

Uno dei motivi più importanti è sicuramente quello di dover accedere ad informazioni a cui non si avrebbe altrimenti accesso, oppure il dover eseguire una operazione massiva. Questo perché non sempre è possibile eseguire una operazione su di una grossa mole di dati, in quanto Confluence/JIRA non la consentono, come ribadito in altri post di questo blog. Fino a quando non saranno disponibili delle funzionalità di un certo tipo, occorre dover agire direttamente da DB. In aggiunta, queste informazioni sono sicuramente utili a coloro che vogliono sviluppare addon per i prodotti Atlassian 🙂

 

Precauzioni

Prima di agire, occorre sempre che siano prese delle semplici precauzioni. Il motivo mi sembra abbastanza semplice: Quando si lavora direttamente su DB, è abbastanza facile arrecare danni. Di conseguenza, sempre meglio avere un backup dei dati/tabelle/DB intero prima di procedere con le modifiche.

Il mio consiglio è sempre quello di avere a disposizione un backup del DB completo + una copia delle tabelle su cui si agisce, prima di procedere con qualsiasi operazione.

 

Un primo esempio

Supponiamo che si voglia modificare gli avatar standard, con un avatar differente (i motivi possono essere qualsiasi: Marketing aziendale,  impostare un avatar di default più carino, etc).

 

profile

 

Al momento, solo gli utenti possono modificare il proprio avatar. A livello di amministrazione, non è possibile eseguire tale operazione. La precedente immagine mostra dove è possibile eseguire tale operazione. Adesso vediamo come è possibile aggirare tale limitazione, semplicemente andando a lavorare su DB.

In prima battuta esaminiamo le tabelle dove sono contenute le informazioni delle utenze. In particolare faremo riferimento a:

  • cwd_user – Tabella contenente le informazioni degli utenti che sono stati configurati in Confluence.
  • cwd_group – Tabella contenente le informazioni dei gruppi definiti su Confluence.
  • os_propertyentry – Tabella contenente anche le informazioni degli avatar.
  • user_mapping – Tabella contenente la corrispondenza uid – nome utente.

La tabella che ci interessa in particolare è l’ultima. Dobbiamo andare a cercare le informazioni degli avatar, utilizzando questa query:

query

Come si vede dalla precedente immagine, quello che dobbiamo andare a cercare è il campo String_val. In questo campo è presente la localizzazione dell’avatar. In questo caso ho assegnato un avatar di default. 🙂 Nel campo Entity_name abbiamo la userid. Come possiamo vedere è abbastanza ….. criptata. Come facciamo a decodificarla? Il giro è il seguente:

  • Dalla tabella os_propertyentry abbiamo le indicazioni del path della immagine
  • Dalla tabella user_mapping abbiamo le indicazioni dell’uid dell’utente
  • Dalla tabella cwd_user abbiamo il nome dell’utente.

Le seguenti immagini chiariscono il tutto: Dall’ID identifichiamo l’utente

query01

 

query02

Di conseguenza, per modificare l’avatar dell’utente admin (in questo caso), possiamo semplicemente modificare il path e andare ad assegnarne uno nuovo. Supponiamo di creare una sottodirectory nel path utilizzato da Confluence per gestire gli avatar di default, ovvero:

<Install_dir_Confluence>confluenceimagesiconsprofilepic

supponiamo di chiamarla Demoprofile e di memorizzare il seguente avatar:

pinguino48

Eseguire il restart del servizio Confluence e, come per magia, il risultato sarà il seguente:

 profiloMod

Conclusioni

Abbiamo visto un esempio di come si può modificare il database per modificare gli avatar degli utenti di Confluence. Questo esempio può essere utilizzato anche per le installazioni per cui gli utenti sono presi da LDAP e non sono solo utenti locali di Confluence.  Nei prossimi post vedremo altri esempi di come si può accedere ai dati e …. vedere altre informazioni.




Creare una funzione split con plsql

Funzione SPLIT in PL-SQL

Riporto un sistema molto semplice per realizzare una funzione SPLIT in PL-SQL. Si tratta di una procedura che ho trovato in questo blog.

Si tratta di una funzione che, data una stringa con separatori, restityuisce l’elemento i-esimo.

create or replace function get_token(
   the_list  varchar2,
   the_index number,
   delim     varchar2:= ','
)
   return varchar2 is
   start_pos number;
   end_pos   number;
begin

   if the_index = 1 then
       start_pos := 1;
   else
       start_pos := instr(the_list, delim, 1, the_index - 1);
       if start_pos = 0 then 
          return null;
       else
           start_pos := start_pos + length(delim);
       end if;
   end if;

   end_pos := instr(the_list, delim, start_pos, 1);

   if end_pos = 0 then
       return substr(the_list, start_pos);
   else
       return substr(the_list, start_pos, end_pos - start_pos);
   end if;

end get_token;
/

Si tratta di una funzione molto semplice. Il risultato è il seguente:

select
   get_token('foo,bar,baz',1), -- 'foo'
   get_token('foo,bar,baz',3), -- 'baz'
   --
   get_token('a,,b',2),        -- '' (null)
   get_token('a,,b',3),        -- 'b'
   --
   get_token('a|b|c',2,'|'),   -- 'b'
   get_token('a|b|c',4,'|')    -- '' (null)
from
   dual

Punti di attenzione

  • L’indice parte da 1 e non da 0
  • Se per l’indice specificato, non è presente alcun valore, allora non viene restituito alcun valore
  • Se si fornisce un indice che non esiste (es. la stringa è formata da 3 elementi e si richiede il 4 elemento), allora anche in questo caso, la funzione non restituisce nulla.

 

Suggerimenti

Potrebbe tornare utile far restituire una stringa ad hoc, qualora non venga fornito un indice non esistente nella stringa, sostituendo il return null; con return ‘-1’; in modo da distinguere la situazione in cui non venga restituito un valore da l’aver richiesto un indice non esistente.

 

 




Backup & Restore

Affrontiamo un argomento abbastanza spinoso. Backup e Restore dei dati di Confluence JIRA.

Premessa

Almeno una volta nella vita capiterà di dover eseguire il restore. Lo stesso accadrà anche per Confluence e JIRA, che non sono da meno. Il consiglio che dò è di preparavi a tale evento, eseguendo dei test di restore dai backup che sono stati realizzati, cercando di capire bene tutte le operazioni che devono essere eseguite e tutti i problemi che si possono presentare. Al termine delle prove, si disporrà della esperienza per poter eseguire le operazioni necessarie senza grosse difficoltà.

In questo post vedremo alcuni scenari e descriveremo come eseguire il restore dei dati, rischi e punti di attenzione.

Tipologie di backup

Esaminiamo le possibili tipologie di backup che abbiamo a disposizione.

Per tutte le installazioni (onDemand e download) messe a disposizione, possiamo eseguire un backup generale di:

  • Confluence – Tutti gli space (pagine, commenti, allegati, etc), comprensivi degli utenti, sono esportati su di un unico file ZIP;
  • JIRA – Tutti i progetti e gli allegati, comprensivi degli utenti, sono esportati su di unico file ZIP.

Per Confluence è possibile anche eseguire una esportazione di un singolo Space ed importarlo. Lo stesso può essere eseguito anche su JIRA, con la differenza che è possibile eseguire l’import di un singolo progetto, sempre partendo da un intero backup (Rif. alla seguente risposta su Atlassian Answer).

Per grandi installazioni, su server locali, non è conveniente eseguire delle esportazioni così indicate, in quanto i file XML risultano troppo grandi per essere gestiti. In questo caso occorre fare riferimento alla seguente pagina, dove viene specificato meglio quale strategia utilizzare per i backup e per i ripristini. Di seguito comunque indicheremo come eseguire un restore.

Una considerazione….

I dati presenti sul file ZIP possono variare da versione a versione (sia per Confluence che per JIRA) e non sempre si riesce ad importare da una versione all’altra. E’ possibile operare una workaround, come  riportato nel seguente link, ma nel caso di  evidenti differenze di versioni (es. da una versione 3.5 ad una 5.5), allora conviene procedere all’aggiornamento dei dati attraverso un upgrade del sistema Confluence o JIRA.

 

Possibili scenari

I principali scenari che vi si possono presentare sono:

  • Restore di un sistema installato su di un server locale, sia esso il server di produzione, sia esso il server di test da utilizzare per vari scopi (test di nuovi plugin, ambiente di test per replicare eventuali malfunzionamenti, etc);
  • Spostamento dei dati da un confluence ondemand ad una installazione in locale (in questo ultimo caso si vuole portare le informazioni da uno o più space verso una installazione che già contiene degli space e che risulta in uso).

Nel caso del primo scenario, nella ipotesi che si disponga di una installazione della stessa versione del backup, possiamo eseguire il ripristino come segue:

  1. Riportare il file di backup su (CONFLUENCE_HOME)/restore oppure posizionarlo su apposita directory dove eseguire il restore delle informazioni. La procedura consente di poter selezionare dove prelevare il file ZIP (vedi figura successiva);
  2. Accedendo alla sezione di amministrazione, sezione Import Site, selezionare quindi il file da importare, come mostrato nelle due figure successiva, per Confluence e per JIRA.

 

CONFLUENCE ADMINISTRATION

Confluence-restore

 

 

JIRA ADMINISTRATION

 

Jira-restore

 

Qualora sia stata eseguita una strategia di backup differente (come indicato prima, facendo riferimento alla pagina del manuale di confluence), dove si è eseguito:

  • Backup del database;
  • Backup della Confluence Home (o JIRA Home)

il ripristino deve essere eseguito ripristinando entrambe le due componenti sopra indicate, a server spento. Quindi riattivare il tomcat ed attendere il riavvio, controllando tutti i messaggi che si presentano nel log. Qualora si stia predisponendo una nuova installazione, vuoi di un server di test o di altro, occorre allora modificare i puntamenti al database, presenti nel file confluence.cfg.xml, e inserire dove è stato eseguito le coordinate del database di cui si è eseguito il restore. Questa modalità può essere eseguita solo su installazioni in locale.

 

 Punti di attenzione

Come ho indicato prima, i file ZIP presentano anche le indicazioni degli utenti. DI conseguenza, quando si esegue il restore, occorre prestare molta attenzione. Se si vuole eseguire un restore di un backup su di una installazione già avviata (vuoi per eseguire una unificazione di sistemi diversi, una on demand ed una locale), quando si esegue una importazione dello ZIP, gli utenti vengono riportati sulla installazione in cui si esegue il restore, rimuovendo il contenuto preesistente. Se non si agisce con criterio, si rischia di fare dei danni.

In questo caso occorre operare degli accorgimenti. Nel caso di JIRA, eseguire una importazione di un singolo progetto (nel caso di più progetti, l’operazione potrebbe richiedere molto tempo: Valutare bene le operazioni in questo caso). Nel caso di Confluence, procedere ad una esportazione di singolo space e relativa importazione.