B.A.C.H. per chi non c’era
di Fabrizio Marchesano, Frame srl
Seconda parte
Disclaimer 1: il presente testo è la revisione in formato articolo della sessione relativa a Domino &
BlackBerry presentata all'evento Dominopoint; anche se i contenuti sono i medesimi, l'esposizione degli
argomenti è naturalmente stata adattata alla pubblicazione per iscritto.
Disclaimer 2: questo articolo è rivolto a sviluppatori e amministratori che abbiano già dimestichezza con
i dispositivi BlackBerry e l'ambiente di sviluppo Domino; anche se in alcuni casi, a scopo di maggior
chiarezza, verranno ribaditi alcuni concetti primari, si dà per scontata una conoscenza di base della
terminologia utilizzata e dei software di riferimento.
Nella prima parte di questo articolo (N.B.: in caso di pubblicazione separata delle
due parti, inserire qui il link alla prima parte) abbiamo visto come sia possibile
risalire al PIN identificativo di un dispositivo BlackBerry utilizzato per accedere al
nostro ambiente Domino.
Riassumiamo per chiarezza espositiva i punti chiave stabiliti:
il PIN è un codice alfanumerico che identifica univocamente il dispositivo
●
BlackBerry
l'associazione PIN-Utenza-EMail è univoca e in ambiente Domino è esplicitata
●
nel database BlackBerry User Profiles
è possibile configurare il BlackBerry Enterprise Server in modo da consentire
●
l'invio delle informazioni relative al PIN nelle headers delle richieste HTTP inviate
dai dispositivi BlackBerry
relativamente alla applicazioni MDS Studio, è possibile configurare le Device
●
Policies del BES in modo da consentire la lettura di informazioni da
un'applicazione a un'altra (con particolare riferimento al gruppo di variabili
denominato DeviceInfo, comprendente naturalmente il PIN)
in ambiente Domino esistono diverse metodologie applicative per acquisire il
●
valore del PIN in dipendenza dal tipo di applicazione alla quale stiamo
accedendo via BlackBerry (Notes Agent, Formule, Web Services)
noto il PIN, è possibile risalire all'identità dell'utente associato al dispositivo che
●
sta effettuando la richiesta, tramite formule di lookup o script analoghi,
recuperando l'informazione dal database BlackBerry User Profiles (o
qualunque altro database contenga la stessa informazione)
La situazione di partenza per questa seconda parte dell'articolo è quindi la seguente: è
stato effettuato un accesso via BlackBerry a dati residenti nella nostra intranet Domino
da parte di un utente identificabile (e identificato) senza necessità di autenticazione
tramite inserimento di username e password.
Siamo dunque pronti a effettuare un primo passo per raggiungere l'obiettivo prefissato
(accesso alla Intranet Domino via BlackBerry bypassando l'autenticazione manuale):
la progettazione di una security di tipo applicativo.

In altre parole, possiamo effettuare in backend la verifica dei diritti di accesso
dell'utente per conto dell'utente stesso.
L'ambiente Domino ci mette a disposizione diversi strumenti per ottenere questo
risultato.
Ad esempio, se all'interno dell'applicazione stiamo già utilizzando campi Authors e
Readers, potremmo semplicemente verificare se l'utente in questione è compreso
nelle liste memorizzate in tali campi.
Naturalmente, la security di un'applicazione Notes non è limitata all'inserimento
esplicito di un nominativo in campi appositi, ma si basa anche e soprattutto su una
corretta gestione dell'Access Control List, dell'appartenenza a gruppi, dell'attribuzione
di ruoli, e spesso una singola applicazione, nel senso più ampio del termine, è
costituita da differenti database NSF, ciascuno con le proprie ACL esecurity rules.
In questi casi possiamo verificare i diritti di una particolare utenza ad esempio via
Lotus Script utilizzando i metodi QueryAccess, QueryAccessPrivileges e
QueryAccessRoles, tutti definiti all'interno dell'oggetto NotesDatabase.
Oppure ancora, a parità di condizioni di security, possiamo impostare regole dinamiche
basate sulla tipologia e lo stato effettivo dei documenti (ad esempio, un certo
documento in un certo stato può essere modificato solo dal responsabile diretto
dell'autore del documento stesso, informazione memorizzata in un database per la
gestione gerarchica dello Staff).
Non esistono regole generali sempre valide per privilegiare una strada piuttosto che
un'altra: la decisione finale verrà presa in base all'esperienza e in dipendenza dalle
specifiche condizioni al contorno.
Vediamo ora un esempio pratico relativo al flusso delle informazioni per
un'applicazione BlackBerry realizzata con MDS Studio via Domino Web Services.
Compilazione Rapportini via BlackBerry
La schermata iniziale dell'applicazione richiede l'inserimento di una chiave di ricerca:
La funzione di ricerca associata, che chiameremo getCustomers, è basata sulla
valorizzazione di due variabili, myPIN e myCust:
Function getCustomers(myPIN as String, myCust As String) As Customers
myPIN, come abbiamo visto nella prima parte di questo articolo (N.B.: in caso di
pubblicazione separata delle due parti, inserire qui il link alla prima parte),
viene valorizzata automaticamente con il PIN del dispositivo, myCust è la chiave di
ricerca inserita.
Una volta risaliti all'identità dell'utente associato al PIN con uno dei metodi sopra
descritti e sulla base della stringa associata alla variabile myCust, il valore di ritorno

sarà costituito dalla collection dei clienti il cui nominativo corrisponde al criterio di
ricerca e filtrata sulla base dei diritti di accesso dell'utente
:
La funzione associata a questa seconda schermata, che chiameremo getOrders,
restituirà l'elenco delle commesse relative al cliente selezionato, anch'esso filtrato sulla
base dei diritti di accesso dell'utente:
Function getOrders(myName As String, myCust As String) As Orders
La variabile myPIN è stata rinominata in myName (l'utenza associata al PIN è stata
esplicitata in precedenza) mentre myCust conterrà ora l'identificativo completo del
cliente come selezionato dalla lista.
Il valore di ritorno viene così esplicitato nella schermata successiva:
Una volta selezionata la commessa desiderata, si accederà alla compilazione del
rapportino vero e proprio:
Il passo finale sarà la creazione di un documento Notes in apposito database:
Function repStatus (myName As String, myCust As String, myOrder As
String,myDetails As String, myDate As String, myPlace As String, sTime As
String,eTime As String, pMinute As String) As Report
… ' codice per verifica integrità dati
' creo il nuovo documento rapportino

Set rDoc=rDb.CreateDocument
… ' codice per trasferimento dati in documento Notes e salvataggio
Da qui in poi l'unico limite è la vostra fantasia (più spesso la fantasia del cliente): invio
in automatico di notifica al responsabile della commessa, conversione del rapportino in
PDF e invio in tempo reale al cliente (il cui indirizzo di posta elettronica è memorizzato
nel database di anagrafica) finalizzato alla stampa e alla firma del documento
cartaceo, eccetera.
Accentramento delle procedure
Abbiamo dunque analizzato le possibilità offerte dallo sviluppo di applicazioni
BlackBerry in ambiente Domino per l'autenticazione in backend degli utenti e
approfondito un esempio di flusso applicativo.
Ma non è tutto qui: dopo aver semplificato e velocizzato l'utilizzo delle applicazioni per
l'utente, possiamo compiere un piccolo passo in più per facilitarne l'approccio anche
dal punto di vista dei programmatori.
Effettuando l'autenticazione in backend, infatti, non abbiamo più la necessità
contingente di aggregare le procedure costituenti l'applicazione nello stesso database
dove risiedono i dati.
In altre parole, è possibile progettare lo sviluppo di un repository centralizzato e
condiviso atto a contenere Notes Agents, Web Services, codice Java (le Central
Highways dell'acronimo B.A.C.H.) e qualunque altro strumento necessario alla
realizzazione di applicazioni, con tutti i benefici che ne possono derivare.
Ad esempio:
sviluppo non dispersivo
●
condivisione script libraries e codice
●
omogeneità strutturale delle applicazioni
●
possibilità di gestione funzionalità lato client, tramite compilazione di appositi
●
documenti keyword
possibilità di realizzazione di un pacchetto di applicazioni base, personalizzabile
●
secondo le esigenze del cliente
e qualunque altro vantaggio riconducibile alla gestione centralizzata di procedure
informatiche.
Sviluppi futuri
All'inizio di questa seconda parte dell'articolo, ho parlato di “primo passo per
raggiungere l'obiettivo prefissato”: prima ancora che l'evento Dominopoint avesse
inizio, noi relatori avevamo già iniziato un proficuo scambio di idee, che nel caso
particolare ha portato a gettare le basi per interessanti evoluzioni future.
Come si suol dire: stay tuned for more.
Buon lavoro a tutti!