Installazione di Uniface – Problemi con Uniface Tomcat?

Installando Uniface in ambiente Windows vengono configurati alcuni servizi all’interno del sistema operativo in modo che l’ambiente Uniface si avvi automaticamente all’avvio del sistema stesso.

Fino alla versione U9.6 i servizi Windows configurati sono stati 3:
– Uniface URouter
– Uniface Tomcat
– Uniface SolidDB
A partire dalla versione U9.7 si riducono a 2 essendo SolidDB stato sostituito da SqlLite come DBMS di default di ogni installazione.

Durante il processo di installazione vengono richiesti i vari parametri che contribuiscono all’installazione dei vari servizi. Eventuali problemi di installazione di URouter o di SolidDB, ad esempio una sovrapposizione della porta TCP in ascolto con altri software o con altre versioni di Uniface, possono essere facilmente individuati e debuggati analizzando i relativi log files.

Un poco più complessa è la configurazione di Tomcat, costituita dalle varie variabili di ambiente necessarie a questo software che svolge funzione di “application server”. Può capitare che l’installazione di Tomcat si sovrapponga ad altri software installati utilizzanti anch’essi questo “application server” piuttosto diffuso.
Come si fa a verificarla ed eventualmente modificarla dopo l’installazione?

Per prima cosa bisogna procurarsi la stringa di comando per l’avvio del servizio Uniface Tomcat definita all’atto dell’installazione di Uniface. Per fare questo è sufficiente dalla Microsoft Management Console dedicata ai servizi del sistema operativo accedere alle proprietà del servizio incriminato. Vi troverete dinnanzi ad un formato simile a questo:

<DISK:><PATH>tomcat8.exe //RS//<YourServiceID>

Copiate l’intera riga di comando e incollatela in una finestra di “prompt dei comandi”, modificandola in questo modo:

<DISK:><PATH>tomcat8W.exe //ES//<YourServiceID>

Le modifiche apportate sono 2:
– Aggiunta del carattere W al termine del nome dell’eseguibile prima del punto separatore dell’extension, per puntare ad un altro eseguibile disponibile nell’installazione di Tomcat.
– Nel primo parametro modifica di //RS// (che significa Run Service) con //ES// (che significa Edit Service)

Eseguite il vostro comando e vi troverete in una finestra che vi permetterà di modificare i parametri del vostro servizio Uniface Tomcat.

Per chi fosse interessato ad un approfondimento sul tema, consiglio la lettura della pagina: https://tomcat.apache.org/tomcat-8.0-doc/windows-service-howto.html

Buona lettura!

Da “Standard & Guidelines” a “Framework”

L’argomento che si dibatte più frequentemente in questi ultimi anni durante le attività su Uniface è quello che definisce il titolo di questo articolo: stabilire i metodi / criteri di sviluppo per riscrivere od estendere le proprie applicazioni al mondo Web/Mobile.

Più che un articolo che fornisce una soluzione ideale vuole essere l’inizio di una riflessione su quale sia il metodo scelto, ed eventualmente applicato, per:
– migrare una applicazione client/server esistente a 3 livelli
– sviluppare estensioni a 3 livelli per una applicazione client/server esistente

Nell’ambito della classica architettura applicativa a 3 livelli DATI -> SERVIZI -> (API) -> PRESENTAZIONE risulta in particolare sempre un poco ostica la decisione di quale/i componente/i di programmazione della presentazione lato browser (MV*) includere nel proprio framework per via della molteplicità di proposte e di scelte offerte dal mercato. Potete dare un’occhiata al sito http://todomvc.com per comprendere cosa si intenda per “molteplicità”.

Le proposte disponibili sul mercato vanno sostanzialmente suddivise in due gruppi:
– Framework server-side
– Framework client-side
e la decisione sulla strada da seguire per perseguire gli obbiettivi che l’applicazione si propone di affrontare e risolvere non sempre risulta immediata. In molti casi un ragionevole equilibrio tra le funzionalità svolte dal server e quelle attuate dal client è necessario ma non sempre è immediata la linea di demarcazione tra i due fronti in quanto molto (se non tutto!) dipende dalle funzionalità che si devono sviluppare. L’ideale sarebbe sviluppare applicazioni utilizzando un framework che sia in grado di lavorare su entrambi i fronti (Vedere http://isomorphic.net).

La difficoltà legata alla molteplicità di scelte tecnologiche disponibili va in genere a braccetto con l’esigenza di mantenere il miglior grado di indipendenza dai browser disponibili sulle varie piattaforme, utilizzate dagli utenti; alcune di queste accoppiate browser/piattaforma fanno parte del mondo mobile, per cui si portano appresso esigenze specifiche a livello di presentazione e richiedono di conseguenza un approccio, perlomeno in parte, dedicato. Quando questo approccio dedicato diventa prioritario nel panorama complessivo si parla di “Mobile First Framework”.

Le scelte che ho riscontrato essere maggiormente utilizzate ad oggi sono:
– Bootstrap + jQuery
– AngularJS
– ReactJS
– Custom / Personalizzato (della serie “uso quello che mi serve quando mi serve!”)

Ringrazio anticipatamente chi volesse aggiungere un contributo o una riflessione.

Sviluppo applicazioni Web – Mobile

Con il rilascio della versione 9.7.02 si è aperta la possibilità di sviluppare e rilasciare applicazioni mobile con Uniface.

Lo sviluppo con Uniface di applicazioni mobile presuppone conoscenza nello sviluppo di applicazioni Web con integrazione delle tecnologie che stanno alla base del web 2.0 (HTML5 / CSS3 / Javascript) nel contesto delle DSP (Dynamic Server Pages), la cosiddetta “programmazione lato browser”.

Al fine di permettere agli sviluppatori Uniface Desktop (Client/server) di approcciare lo sviluppo web/mobile DA ZERO gli ULab hanno rilasciato sul canale YouTube dedicato a Uniface una serie di filmati che sono raccolti in un articolo introduttivo disponibile su uniface.info alla pagina:

http://unifaceinfo.com/html5-javascript-css3-training-videos-uniface-developers-uniface-info/

I brevi filmati chiariscono alcuni punti fermi dello sviluppo Web/Mobile, dando un compito specifico ad ognuna delle tecnologie di base coinvolte nella programmazione lato browser:

  1. HTML5: gives a meaning to data.
  2. CSS3: styles elements presented on screen, paper, or other media.
  3. Javascript: a scripting language to enable interactive sites.

Nell’ambito dei filmati viene fatto riferimento ad un paio di siti di supporto:
1) http://caniuse.com che costituisce uno dei principali riferimenti per conoscere il livello di supporto, e di conseguenza la portabilità, di una specifica funzionalità della programmazione lato browser.
2) http://css3generator.com che permette un approccio semplificato a quelle direttive CSS3 che dovessero essere differenziate e/o moltiplicate nella loro sintassi per ottenere una effettiva portabilità attraverso i vari browser e le loro versioni.

Un’ultima avvertenza, consiglio la visione dei filmati in quest’ordine:
1) HTML5
2) CSS3
3) Javascript

Buona visione!

Uniface applications in modalità “readonly”

Negli ultimi anni è diventata sempre più pressante l’esigenza di proteggere i sistemi informativi aziendali, che permettono il regolare svolgersi della quotidianità, dalle invasioni indesiderate di agenti esterni come virus o da azioni inconsulte da parte di maldestri utenti.

Affiancando questa esigenza a quella di un regolare e progressivo aggiornamento dell’ambiente Uniface Runtime, abbiamo deciso di sviluppare un semplice script shell che si occupasse in modo completo dell’avviamento di un (sotto)sistema sviluppato con Uniface in un ambiente di produzione.

Questo script shell, particolarmente utile da quando il numero di utenti supera le 50 unità, permette di:
– Avere un unico e standardizzato criterio di avviamento a cui far puntare le icone di avvio di TUTTI gli utenti;
– Standardizzare e configurare in maniera nettamente separata l’area programmi e l’area dati di un (sotto)sistema;
– Riconoscere le varie directory di riferimento e di lavoro dell’applicazione con delle semplici chiamate;
– Mettere in linea un aggiornamento dello Uniface Runtime in modo progressivo prima agli utenti pilota e poi a tutto il resto dell’utenza configurando semplicemente un paio di files;

Chi volesse avere maggiori informazioni su questo criterio organizzativo per il rilascio in produzione di applicazioni Uniface mi contatti.

Uniface & Windows Registry

Ad oggi Uniface, quando eseguito su piattaforma MSW o derivate, utilizza il registry di Windows per conservare diverse informazioni; dalla documentazione fornita con il prodotto è possibile ricavare un elenco di tali categorie di informazioni:
– Component States
– Logical printers
– Command line history
– Installation information
– COM options
– Application Informations
– Initialization Settings

Alcune di queste informazioni hanno cambiato posizione di base all’interno del registry nel passaggio dalla versione U9.6 alla U9.7, a seguito dell’abbandono di tutti i riferimenti al vecchio proprietario del prodotto. Quello che in precedenza era salvato sotto:
HKEY_CURRENT_USER\Software\Compuware\Uniface\USYS9\State\
a partire da U9.7 è salvato sotto:
HKEY_CURRENT_USER\Software\Uniface\Uniface 9\State\
E’ garantita compatibilità con il passato in quanto la vecchia posizione viene comunque letta anche da U9.7 ma i nuovi salvataggi avvengono sempre nella nuova posizione.

Ho sviluppato alcune funzionalità aggiuntive al prodotto per dare visibilità a quanto suddetto; chi fosse interessato può contattarmi attraverso questa discussione oppure con uno tra i canali più consueti.

U9.7 on W10

In questi ultimi giorni mi sono imbattuto in una situazione strana di cui voglio mettere a conoscenza gli Unifacers. Negli ultimi mesi ho migrato il mio lavoro con Uniface su una nuova macchina (virtuale) W10. Ieri dovevo testare l’utilizzo di alcuni fonts di barcode e li ho installati ed utilizzati in pochi minuti su U9.6.08; quando ho migrato la stessa form su U9.7.01.G104 (la versione corrente) e ho modificato l’INI file per definire anche su questa versione i font logici che l’applicazione doveva utilizzare ho perso parecchio tempo per via di un sistema di protezione che Windows applica a tutte le applicazioni che vengono installate nelle directory “protette” e al registry di sistema. Tra queste sono (ovviamente) presenti:
– C:\Windows
– C:\Program Files
– C:\Program Files (x86)
Nel mio caso avevo installato le versioni di uso di Uniface nella directory “C:\Program Files (x86)”.

In breve: le modifiche che applicavo al file USYS.INI presente nella directory “C:\Program Files (x86)\<U97installDir>\uniface\adm” NON venivano riconosciute dall’ambiente di sviluppo di Uniface eseguendo il programma con la mia normale utenza Windows (Gianni); le form che facevano riferimento ai font logici inseriti nel file usys.ini all’atto della compilazione non risultavano contenere il riferimento a tali font logici perché NON erano visti dall’ambiente di sviluppo.

Dopo aver perso un pò di tempo e aver scambiato qualche chiacchiera con il supporto ad A’dam la luce si è cominciata a schiarire quando lanciando l’ambiente di sviluppo con l’opzione “Run as Administrator” ho visto utilizzata la copia aggiornata del file usys.ini mentre lanciandolo senza questa opzione vedevo utilizzata una copia vecchia del medesimo file.

La chiave di lettura di questo caso si chiama UAC ed il suo “Virtual Store”: sulle directory protette, in determinate condizioni, Windows permette ad un utente, NON abilitato al pieno accesso ad una specifica risorsa, di svolgere una certa funzione accedendo alla sua versione “dedicata” di quella risorsa e non a quella reale, corrente salvata su disco. Tale versione “dedicata” della risorsa protetta viene salvata nel “Virtual Store”.

In pratica: nella directory di installazione di Uniface c’era il mio file usys.ini aggiornato con i miei font logici definiti; nella directory “C:\Users\<UserName>\AppData\Local\VirtualStore” e ramo sottostante c’era la copia vecchia del file usys.ini salvata all’atto della modifica del file con definizione dei font logici necessari. Se eseguivo IDF come Administrator accedevo alla copia di usys.ini aggiornata mentre se eseguivo IDF come Gianni accedevo alla copia vecchia di usys.ini salvata nel “Virtual Store”.

Eliminando il file usys.ini salvato da Windows nel “Virtual Store” per “proteggersi” e “proteggermi” ho risolto il problema…

Al momento la soluzione più banale è quella di installare Uniface in una directory che NON sia tra quelle “protette” da Windows… 😉

Il problema verrà definitivamente superato in una prossima release di Uniface con una modifica alla distribuzione e installazione del prodotto che renderà Uniface più adeguato alle ultime regole dettate da Microsoft per l’ecosistema Windows.

P.S. La virtualizzazione del registry di sistema funziona in modo analogo ma riguarda le chiavi del sottoalbero HKEY_LOCAL_MACHINE\SOFTWARE. In mancanza dei diritti di amministratore gli aggiornamenti delle chiavi e dei dati di questo sottoalbero vengono reindirizzati alla sottochiave HKEY_CURRENT_USER\Software\Classes\VirtualStore.

More info a questa pagina.

Uniface Debugger Watchpoints

La settimana scorsa durante un’attività formativa mi sono stati chiesti lumi su una funzionalità di interruzione dell’esecuzione di una applicazione Uniface con attivazione del debugger a fronte di una specifica condizione: ad esempio quando un campo assume un certo valore. Questa funzionalità in genere viene definita “Watchpoint”.

Dialogando con gli ULab ho scoperto che questa funzionalità pur non essendo ufficialmente supportata o documentata è disponibile da sempre nel mondo Uniface a partire da Uniface 6.1 (1994!) anche se a livelli diversi nel corso del tempo.

Ecco come implementarla:
1) Attivare una sessione di Uniface con il debugger attivo
2) Definire un breakpoint qualunque
3) Rimanendo nel debugger attivare la funzione di “Edit Breakpoint”
4) Nella finestra che compare selezionare il breakpoint temporaneo definito al punto #2; nei campi della parte bassa della maschera su cui si è posizionati compare il contesto SPECIFICO del breakpoint definito.
5) Modificare il contesto specifico del breakpoint definendo:
5a) Una condizione generica nell’ultimo campo, come nomeCampo=valore oppure nomeVariabile=valore.
5b) Eliminare le specificità di contesto non necessarie: “line”, “module”, “component”. Io ho provato ad eliminarle tutte quante per definire un contesto molto generico.
5c) Uscire dal debug e continuare l’utilizzo dell’applicazione
Nel momento in cui la condizione definita sarà “vera” il debugger comparirà automaticamente! Voilà.

Si possono anche inserire nel campo “condition” delle funzioni come ad esempio:
$scan($uppercase($item(“LIN”,($itemnr(1,$proccontext(“FULL”))))),”VARIA”)>0
che ferma l’applicazione in debug ogniqualvolta viene coinvolta in una istruzione Proc la variabile VARIA. In quest’ultimo caso si tenga in considerazione che esiste al momento un limite massimo di lunghezza del campo “condition” pari a 75caratteri; è stato richiesto un ampliamento a 128 caratteri.

L’unica avvertenza da tenere in considerazione è che questo tipo di settaggio NON viene salvato come stato del debug e quindi viene perso uscendo dalla sessione applicativa sotto verifica e va ridefinito all’inizio della sessione successiva nel caso in cui servisse nuovamente.

URouter Monitor migliorativo

Dalla Spagna ricevo e pubblico informazioni relative ad una versione migliorativa del monitor di URouter distribuito con l’ambiente Uniface. Risulta particolarmente utile in configurazioni con un numero significativo di utenti (> 50).

**********

UMO is an Uniface standalone application that uses UnifaceMonitor API to control URouter.

Features

  • Visual enhancement of standard Uniface Monitor tool
  • Remembers all urouters you connected to
  • Remembers users and passwords
  • Allows vision only or privileged access
  • Allows kill specific uservers or using a profile
  • Allows start uservers for specific UST
  • Shows statistics for every UST
  • Records statistics in database (when is running)
  • Order urouter to re-read asn file

Information about each userver is clear and multilanguage using tooltips to explain the meaning of fields.

UMO

  1. Connect
  2. Start/stop recording stats
  3. Filter (future use)
  4. Login as super-user
  5. Show uservers only or connected clients
  6. There is no six
  7. Refresh
  8. Start/Stop/Statistics about uservers (same as right-click over uservers)
  9. Show/Hide 10
  10. Info about selected userver
  11. Uservers running

Control-K changes theme colors

**********

Ringrazio Luis Vila, colui che ha sviluppato e distribuisce tale applicazione, e mi metto a disposizione per fornire maggiori informazioni agli eventuali interessati.

Uniface Lectures

Gli Uniface Lab di Amsterdam hanno lanciato una nuova iniziativa molto interessante: “Uniface Lectures”.

“Uniface Lectures” è una costituita da serie di webinar organizzati per contribuire alla diffusione di conoscenza tecnica su Uniface ed è orientata a TUTTI gli sviluppatori Uniface.

Una volta al mese verrà gestita una sessione serale via web direttamente dai Lab di Amsterdam su un argomento specifico. Utilizzando la versione più aggiornata di Uniface verranno dimostrate funzionalità, tips and tricks con l’obbiettivo di condividere conoscenza a livello tecnico e tecnologico.

Durante questo mese di febbraio verrà svolto il primo di questi webinar: Modernization.

Maggiori informazioni sul calendario già definito e le modalità di iscrizione ai webinar dell’iniziativa possono essere recuperate a questo link sul portale tecnico aziendale.

Buongiorno Unifacers!

Benvenuti a UnifaceSolutions.
Questo sito internet si propone di essere il punto di interscambio di informazioni tra e per gli utenti Uniface in Italia; affianca il sito istituzionale uniface.info (in inglese), anche raggiungibile da unifaceinfo.com, per coloro che preferiscano dialogare in italiano oppure abbiano esigenze specifiche da affrontare in Italia, sia di ordine tecnico che commerciale.
Qui troverete un’area di blogging ed un forum multi-livello nei quali condividere le vostre idee o le vostre esigenze relative allo sviluppo applicativo con Uniface.
Siete TUTTI invitati ad intervenire!
Per accedere al sito registratevi…

Chimichanga!
chimichangaU--icon80x80

Recent Entries »