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.

Diamo una marcia in più

In questo post diamo i risultati del test di questo addon, che ci permette di poter estendere le interrogazioni che il JQL standard mette a disposizione, e ci permette di avere delle interrogazioni avanzate.

Installazione

Partiamo come sempre dalla installazione. Cerchiamo il nostro addon dalla lista degli addon disponibili

Selezioniamo Free trial per attivare la procedura di installazione …

… lasciamo passare qualche minuto …

… che si eseguino tutte le informazioni ….

… una volta completata l’installazione, attendiamo che si attivi la procedura di generazione della licenza …

… selezioniamo Get license per attivare la proceura di generazione della licenza ….

… quindi applicarla al nostro server selezionando Apply License …

Fino alla conclusione della procedura. Passiamo alla fase successiva.

Configurazione

L’addon mette a disposizione una sezione di configurazione. Vi possiamo accedere direttamente dalla sezione degli addon installati, selezionando il nostro addon e il tasto Configure , come mostrato in figura:

Possiamo in alternativa accedere alla configurazione anche da un nuovo menù, che è stato inserito nella barra laterale, come mostrato nella figura successiva:

Da li accediamo alla seguente sezione:

da dove possiamo configurare il nostro addon. Esaminiamo nel dettaglio che cosa possiamo configurare:

• Le licenze dell’addon, opzione che si attiva attraverso il tasto Manage license e che reindirizza sulla pagina di gestione degli addon
• La JIRA Local URL –

Test

Concludiamo con il test. Possiamo accedere ad una console di gestione del codice SQL dal menù di EXPORT di gestione dei Filtri, come mostrato in figura:

Questa funzione ci permette due cose:

• Di accedere alla console SQL;
• Se abbiamo scritto una funzione in JQL, questa viene tradotta in SQL e riportata in console, come mostrato in figura successiva;

Dalla console lanciamo le nostre query SQL e otteniamo i seguenti risultati:

Ma non è l’unica cosa che possiamo fare: Possiamo anche richiamare direttamente il codice SQL nel nostro JQL, come mostrato dalla seguente immagine:

che ci permette di poter eseguire delle query molto molto molto più interessanti. Questo ovviamente lo possiamo eseguire a tutti i livelli in cui si richiama JQL. Se andiamo ad osservare la seguente figura:

Conclusioni

Il risultato del test è ottimo. Possiamo estendere il JQL in modo da fargli eseguire delle interrogazioni che con lo standard non riusciremo a fargli eseguire, estendendo le nostre possibilità.

Reference

Maggiori informazioni sono reperibili alla pagina del marketplace.

Diamo una marcia in più

In questo post analizziamo un addon che ci permette di poter estendere le interrogazioni che il JQL standard mette a disposizione, e ci permette di avere delle interrogazioni avanzate.

Che cosa offre l’addon?

L’addon permette di eseguire delle interrogazioni avanzate attraverso una opportuna interfaccia, come mostrato dalla seguente figura:

dove abbiamo il controllo completo dello schema di database di JIRA.

Possiamo realizzare tutte le interrogazioni che vogliamo, eseguendo anche delle trasformazioni di JQL in SQL.

Conclusioni

Le premesse sono molto interessanti. JQL out-of-box sono molto potenti ma non consentono di poter eseguire delle interrogazioni di un certo tipo, che richiedono sempre di più l’utilizzo di addons particolari che aggiungono funzioni al JQL. Nel prossimo post andremo, come sempre, a saggiare questo addon e verificare come si comporta.

Reference

Maggiori informazioni sono reperibili alla pagina del marketplace.

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.

Visualizziamo numeri

In questo post sarà mostrato come poter utilizzare Confluence per realizzare delle semplici statistiche. Si tratta di un semplice esempio di uso dedicato alla realizzazione di dashboard, che possono sempre aiutarci nel nostro lavoro.

Di cosa abbiamo bisogno?

Quello di cui abbiamo bisogno è:

• Confluence (versione cloud)
• SQL Play
• Database MySql, per fare tutte le prove di cui abbiamo bisogno. Per tutte le nostre prove, utilizzeremo db4free, un sito che gratuitamente mette a disposizione database mysql di test, attraverso eseguire dei test.

Andiamo in dettaglio

In questo post andremo a vedere un semplice esempio di come visualizzare alcune informazioni. IN questo caso supponiamo di andare a visualizzare delle semplici statistiche sui miei consumi di benzina 🙂

A tale scopo, ho creato un semplice DB su db4free, dove ho riportato alcuni semplici dati.

Sfruttando le potenzialità dell’addon SQL Play, ho creato il contesto verso tale database, quindi ho creato la query per visualizzare i dati.

A questo punto creiamo la pagina di prova 🙂

Ovviamente si tratta di dati di esempio. 🙂

Conclusioni

Abbiamo visto come inserire delle semplici statistiche da un database remoto. Possiamo a questo punto creare delle dashboard che, leggendo le informazioni da un db remoto, visualizzano i risultati direttamente sulle pagine di Confluence.

Query SQL su Confluence

In questo post andremo ad esaminare un altro addon, dedicato alla esecuzione di query su database esterni, al fine di creare dei report interni a Confluence stesso. Abbiamo già esaminato questo nei seguenti post.

PocketQuery – First look

PocketQuery è un addon gratuito (al momento in cui viene redatto questo post), per Confluence Server, che consente di poter eseguire delle query predefinite su database esterni a Confluence, all’interno delle varie pagine. Attraverso una opportuna macro, come mostrato nella figura precedente, è possibile impostare quale query eseguire ed i relativi parametri.

I dati non sono solo visualizzati in forma tabellare, ma viene data la possibilità di poter realizzare dei grafici :-), sfruttando le potenzialità di Google Chart API.

Che utilizzi sono possibili?

Tra i possibili utilizzi di questo addon, vedo la possibilità di poter realizzare delle Dashboard che mostrano informazioni derivate da query implementate ad hoc. Un esempio potrebbe essere quello di mostrare i log di caricamento di determinate procedure. Un altro esempio potrebbe essere l’andamento delle vendite o qualsiasi altra cosa. La fantasia è il nostro unico limite 😛

Conclusioni

Abbiamo un addon che consente di poter realizzare delle dashboard interattive e consente una discreta funzionalità. Nei prossimi post, proveremo ad usarlo e ne saggeremo limiti e pregi 🙂

RMAN – First Look

Iniziamo, con questo post, una serie di articoli in cui andiamo a spiegare il funzionamento di questo comando, la sua utilità ed il suo utilizzo.

Che cosa è?

RMAN (Oracle Recovery Manager) è un interprete a riga di comando. L’utility è presente in ogni installazione di database, anche per le installazioni XE (express).

A cosa serve?

Serve fondamentalmente per eseguire backup e restore di database Oracle. Il backup è inteso per ogni singola ISTANZA di Oracle, non per l’intero database. RMAN può eseguire sia backup FULL o completi che backup incrementali, in base alle esigenze o alle impostazioni eseguite

Esempio di uso

Vediamo un primo esempio di utilizzo. Per far ciò mi avvalgo della mia versione di Oracle 11 XE, che ho installato.

Come mostrato dalla figura, per accedere ad RMAN, attiviamo una sessione di CMD e successivamente digitiamo il comando RMAN TARGET /, per accedere alla attuale istanza Oracle. Dato che dispongo di una installazione XE, non avendo a disposizione che una sola istanza Oracle, non devo fare altre operazioni per selezionare dove connettermi. Dalla immagine possiamo vedere che siamo collegati alla istanza XE.

Possiamo subito vedere se abbiamo dei backup, lanciando il comando: LIST BACKUP SUMMARY;

che ci mostra l’elenco dei backup attualmente presenti a sistema.

Per lanciare un backup, lanciare il comando: BACKUP DATABASE; Il risultato sarà simile a quello mostrato ella figura sottostante (dove ho lanciato un comando similare, che ripete il backup ma eseguendo una validazione per verificare se è possibile eseguite l’operazione).

Per ripristinare il backup, semplicemente eseguire il comando RESTORE DATABASE. 

Conclusioni

Questo è solo il primo passo, per descrivere questa importantissima utility di Oracle, in cui abbiamo semplicemente presentato alcune delle funzionalità. Nei prossimi post, andremo ad esplorarla meglio e a fare dei semplici esempi di come possiamo utilizzarla.

Reference

Maggiori informazioni sono reperibili sui vari manuali Oracle, ma una buona reference è reperibile qui

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.

JIRA e le sue tabelle

In questo post, proseguiamo quanto iniziato su questo post, dove abbiamo fatto una breve panoramica delle tabelle di Confluence.

In questo caso, proviamo ad eseguire la stessa operazione presentata nel post precedente, ma facendo riferimento alle tabelle di JIRA. La seguente immagine riassume alcune delle tabelle di JIRA. Si rimanda alla sezione Reference per tutte le indicazioni sul caso.

Precauzioni

Si ribadiscono le stesse identiche precauzioni che sono state indicate nel precedente post. Fate sempre un backup dei dati, prima di procedere con qualsiasi operazione. In questo modo potete essere sicuri di poter operare in tutta sicurezza.

Iniziamo 🙂

Cerchiamo di impostare un avatar di default differente da quello preimpostato. Partiamo da questa situazione:

Le tabelle che andiamo a referenziate sono le seguenti:

• cwd_user – Tabella contenente le informazioni degli utenti
• avatar – contenente gli avatar standard
• propertyentry – contenente le associazioni da utente ed avatar utilizzato
• propertynumber – contenente l’associazione con l’avatar collegato all’utente

Procediamo con la modifica

Aggiungiamo il nuovo avatar. Il file va caricato nella directory:

<Install-Dir>Atlassian-JiraWEBINFClassesAvatar

Supponiamo di utilizzare sempre l’icona del pinguino 🙂

Punto di attenzione. A differenza di Confluence, JIRA ha la necessità di avere anche una seconda icona, dimensione 24×24, la metà rispetto alla dimensione dell’avatar che si inserisce, ovvero 48×48, che viene referenziato e mostrato in alto a destra. Predisporre quindi un secondo avatar, nome pari a small_<nome_del_file_nuovo_avatar>.png e memorizzarlo nella stessa directory.

Quindi aggiungiamo un nuovo record, alla tabella avatar, con le indicazioni dell’icona nuova

Dalla tabella cwd_user, identifichiamo l’utente in questione:

Dalla propertyentry ci ricaviamo l’ID per determinare la proprietà da andare a modificare, cercando per ENTITY_ID = ID USER e PROPERTY_KEY = ‘user.avatar.id’:

Quindi dalla propertynumber, ci ricaviamo l’ID dell’avatar utilizzato.

Inseriamo, nel campo propertyvalue, l’ID del nuovo avatar di default, e questo è il risultato:

Conclusioni

Con questo sistema riusciamo ad impostare il nuovo avatar di default in maniera semplice. Questo ci consente di poter eseguire una semplice modifica alla installazione, sostituendo gli avatar in modo semplice.

Se si vuole aggiungere un avatar non di default?

Fattibile, ma occorre agire da tutt’altra parte. In questo caso si dovrebbe memorizzare il file del nuovo avatar in altra directory, ovvero:

<JIRA-Home-dir>dataavatars

e si memorizzano in vari formati, principalmente il formato 48×48 ed il formato 24×24, che servono principalmente per tutte le funzionalità. La configurazione delle tabelle è la medesima. Il nome del file, come per il precedente esempio, deve essere preceduto dal nuovo ID assegnato alla tabella Avatar. Nei prossimi post vedremo altre informazioni sulle tabelle di JIRA.

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.