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

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.

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.

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>

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 :-).

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:

• Selezionare quindi Add repository

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

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

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.

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 🙂

il 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.

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.

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).

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:

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

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:

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

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.

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:

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.

Affrontiamo un argomento abbastanza spinoso. Backup e Restore dei dati di Confluence e 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

JIRA ADMINISTRATION

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.

In alcune circostanze, occorre impostare dei ritardi nella procedura che deve essere eseguita. Fino a qualche tempo fa avevo risolto attraverso un ciclo, eseguito un tot di volte, in modo da simulare un ritardo.

Consultando il prolifico sito di Ask Tom, ho scoperto che esiste una funzione che realizza il tutto. Si tratta di:

DBMS_LOCK.SLEEP(<numero di secondi>)