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.

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

PocketQuery – Un esempio di uso

Vedremo in questo post un esempio di uso dell’addon PocketQuery, precedentemente presentato nel seguente post.

Iniziamo

Partiamo dalla installazione dell’addon, che eseguiamo molto semplicemente da pannello di amministrazione.

AL termine della installazione, procediamo con la configurazione:

La sezione di amministrazione e configurazione dell’addon consente di poter impostare le varie componenti.

Iniziamo a configurare un DB esterno di prova. Il primo passo è inserire i dati di accesso al database. A tale scopo, utilizzeremo un DB di test db4free.net , che mette a disposizione un database per i nostri test, gratuito (al momento un cui l’articolo viene redatto, il sito mette a disposizione dei database gratuiti, sotto opportune limitazioni).

Una volta specificati i parametri di connessione, procediamo con il definire una query:

A questo punto passiamo a visualizzare i dati. Andiamo nello space indicato nella parametrizzazione della query e creiamo una pagina ad hoc, dove andremo a visualizzare i dati. Quindi andiamo ad aggiungere la macro PocketQuery  e otterremo questo primo risultato.

Il risultato nella pagina sarà il seguente:

Conclusioni

Abbiamo a disposizione un addon free (al momento in cui viene scritto questo articolo, l’addon è gratuito) che consente di poter eseguire delle interrogazioni e di poter visualizzare i risultati delle query in modo semplice e rapido.

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.

In questo post cercherò di riassumere come sono riuscito ad installare Oracle XE 32 bit per windows, su di un sistema operativo 64 bit. In particolare, su Windows 7 Professional 64 Bit.

Avevo la necessità di disporre di un sistema Oracle su di un PC, dove era presente una installazione Windows 7 Professional, ma non ero mai riuscito a eseguire l’installazione.

Ho in prima battuta consultato diversi forum, dove si dibatteva il fatto che l’installazione di non era possibile su di un sistema a 64 bit, con le soluzioni più strane che ho visto.

Ne riporto alcuni che ho consultato:

• http://blog.mclaughlinsoftware.com/2011/09/13/oracle-11g-xe-installer/
• http://kmatcha.wordpress.com/2012/08/07/trick-to-install-oracle-express-edition-11g-on-windows-7-64-bit/
• https://forums.oracle.com/thread/1123908?start=0&tstart=0

per darvi un esempio di quanto è presente su internet.

Dopo diversi tentativi, ho verificato che è possibile installare Oracle XE 32 bit sotto Windows 7 64 bit senza fare chissà quali passi. Occorre solo prendere alcuni accorgimenti ed eseguire delle semplici operazioni manuali. Passiamo ai vari step per arrivare al risultato.

Fase 1 – Download del setup

Il Setup è disponibile alla seguente pagina. Ricordarsi di accettare le condizioni per poter eseguire il download.

Fase 2 – Installazione di Oracle XE

Lanciare il setup e seguire tutti i passi. Sicuramente sarà intercettato un errore, come mostrato dalla seguente figura:

Date OK ed andate fino in fondo. L’installazione procederà fino alla fine.

Fase 3 – Configurazione manuale

Una volta che avete installato Oracle, definite le seguenti variabili di ambiente:

• TNS_ADMIN    
• ORACLE_HOME
• OCIDLL

specificando il path dove avete installato Oracle. Se avete lasciato i valori di default, basta che inseriate:

C:oraclexeapporacleproduct11.2.0server

• NLS_LANG (opzionale. Serve per definire un settaggio che sarà utilizzato. Mettete ITALIAN per italiano).

La variabile PATH risulterà già configurata. Se non fosse, semplicemente aggiungete in coda ai vari path anche quello di Oracle.

Fase 4 – Iniziate a lavorare

Fatto ciò, potete iniziare a lavorare. L’interfaccia WEB, selezionabile dalla Icona Get Started presente sul Desktop, sarà utilizzabile e potrete iniziare a lavorare con la vostra installazione di Oracle.