Free license available.

Database Relazionali & Internet

Esempi Applicativi: Emissione Ordine mediante Form/CGI

a cura di: Alessandro Fiorenzi
Revisori: Prof. F.Pirri, Ing. M. Lunghi, Ing. C. Vestri

Emissione Ordine mediante Form/CGI

Definizione progetto
Setup progetto
Moduli operativi
Risultati
Emissione Ordine Acquisto
Sorgenti

Definizione Progetto

Il progetto si pone come obbiettivo di realizzare e valutare i processi di accesso a basi di dati in modalità remota. Col termine "modalità remota" intendiamo l’accesso tramite una intranet, extranet e naturalmente tramite Internet.

Non disponendo di una situazione dati reale, abbiamo costruito per intero la struttura di una azienda che vende computer e componenti di computer, la "Telematic Lab". Abbiamo realizzato le procedure che, mediante accesso ad una pagina aziendale, permettono di emettere un ordine per gli articoli a listino.

Abbiamo operato, con i seguenti strumenti, riportandone poi vizi e qualità.

PC Linux
Server Web	Apache
Server SQL	MySQL
Linguaggio di Scripting:	Perl

La scelta di operare su un Pc Linux con Apache, è stata dettata dalla disponibilità di tale piattaforma oltre che dalla grande diffusione di questo binomio in ambito internet. MySQL risulta inoltre essere un server sql stabile, multipiattaforma, multiprotocollo, oltre all’esistenza di una distribuzione commerciale del prodotto completamente supportata. Il server supporta infatti

Multi-thread usando i threads del kernel, può usare anche più CPU
API C, C++, Java, Perl, Python e TCL
Lavora su sistemi Windows NT, Unix ,Linux e derivate processori Intell, sun, PowerPC, 68K
Supporto ODBC e JDBC
Supporta SQL ANSI92

La scelta del linguaggio Perl è stata motivata dalla grande diffusione che tale linguaggio ha come linguaggio di scripting.

Setup Progetto

Una volta individuati gli strumenti abbiamo proceduto alla loro configurazione.

Prima di tutto si è dovuta scegliere la collocazione delle pagine web e dei programmi in Perl. Abbiamo deciso di collocare le pagine web sull’account "fiorenzi" nella directory pubblica vista dal server http, "/public_html". Per tenere separati i programmi CGI/Perl di competenza di questo progetto da altri, abbiamo optato per la creazione di una directory "/publich_html/cgi" ove porre tutti i file cgi. Abbiamo definito all’interno del file di configurazione del server web , srm.conf, un alias "/cgi-fio/" per i programmi che si trovano nella nostra directory cgi. Il server ogni volta che avrà una richiesta ad un file sul cammino "/cgi-fio/file.cgi" lo indirizzerà al percorso "/home/fiorenzi/public_html/cgi/file.cgi" .

Il secondo passo è stato quello di verificare la presenza di una versione Perl superiore o uguale 5.004, verifica che ha avuto esito positivo. Tale verifica si è resa necessaria in quanto le API del MySQL richiedono specificatamente tale parametro.

L’ultima fase di Setup delle risorse, nasce con l’analisi della realtà aziendale, la definizione dello schema Entity Relationschip, e la successiva definizione di struttura del Database. L’analisi si è focalizzata essenzialmente su il problema "Emisione ordine" trascurando molti dettagli delle tabelle non interessate. Ecco di seguito una breve analisi della realtà.

L’azienda "Telematic Lab" opera nella vendita di computer e componenti di computer, ha a listino computer da loro assemblati, e componenti , schede video, hard disk,….. Gli acquisti dei clienti avvengono mediante emissione di ordine riportante i dati del cliente, del/degli articolo/i e la relativa quantità. Per ogni ordine si definisce uno step di produzione che può assumere 3 valori : "1" significa è in assemblaggio o preparazione; "2" il prodotto è disponibile; "3" ordine evaso. Dopo che l’ordine è stato evaso si può procedere alla fatturazione, naturalmente si può emettere una fattura riepilogativa di diversi ordini. Sul lato fornitori il discorso è analogo; si emette un ordine per xxx articoli su un fornitore, successivamente o contestualmente al ricevimento della merce si ottiene fattura di acquisto. Il diagramma Entity Relationship focalizza l’attenzione sulla gestione ordini.

Analizzando ogni entità si perviene ad una struttura di database con le seguenti tabelle

(questo è lo script che permette di creare le tabelle)

#!/bin/sh /usr/local/bin/mysql test_telem <<END_OF_DATA

CREATE TABLE cliente ( codcli char(3) not null, rag_soc char(20) not null, altroc char(60), unique (codcli), primary key (codcli) );

create table fornitore ( codfor char(3) not null, rag_sof char(20) not null, altrof char(60), unique (codfor), primary key (codfor) );

create table ordinevend ( codcli char(3) not null, nord int not null, dataa date, nfatt int, primary key (codcli, nord) );

create table fatturavend ( nfatt int not null, iva float, totale float, primary key (nfatt) );

create table articoli ( codart char(3) not null, descri char(20), qta int, livmin int, prezzo real, tipo enum ("Semplice", "Assemblato"), primary key (codart) );

create table comprendev ( nordvend int not null, codart char(3) not null, qta int, step_produz enum("1","2",3"), primary key (nordvend,codart) );

create table comprendea ( nordacq int not null, codart char(3) not null, qta int, primary key (nordacq,codart) );

create table compone ( cod_mod_predef char(3) not null, cod_art_sempli char(3), primary key (cod_mod_predef, cod_art_sempli) );

create table ordineacq ( codfor char(3) not null, nordacq int not null, dataa date, nfatt int, primary key (nordacq) );

create table fattacq ( nfatt int not null, iva float, totale float, primary key (nfatt) );

create table numeri ( ultimo_ord_vend bigint, ultimo_fat_vend bigint );

END_OF_DATA

Si può quindi procedere alla creazione effettiva del DB mediante i seguenti comendi (da shell)

>mysql mysql>CREATE DATABASE TEST_TELEM;

Il DB è creato, ha il nome TEST_TELEM, che non ci impone di definire i diritti di accesso (questo vale per i DB il cui nome inizia per TEST_ in mysql)

Uscendo da mysql si lancia lo script sopra riportato e così sono definite anche tutte le tabelle.

L’inserimento dei dati nel DB è stato realizzato immettendo i dati opportunamente formattati, in file di testo e applicando il comando

LOAD DATA INFILE "nomefile.estensione" INTO TABLE nometabella

Tutto ciò per ogni tabella.

La configurazione è quindi completa.

Moduli Opertativi

La procedura di Emissione ordine cliente è stata realizzata partendo da una pseudo pagina iniziale dell'azienda (costituita da frame) e da questa mediante l'ausilio di programmi Perl.

Sopra è riportata l'aspetto della pagina iniziale e l'indicazione dei vari frame.

1	Seguendo il link "Ordine Prodotti", si richiama la pagina codcli.html nel frame "Principale". La pagina codcli.htm richiede l'inserimento del codice cliente. Una volta digitato tale codice i dati sono inviati alla cgi codcli.cgi mediante il meccanismo delle form.
2	La procedura codcli.cgi procede a verificare l'esistenza del codice cliente nel Db. Se il codice non esiste è indicato, se la ricerca ha avuto esito positivo sono visualizzati i dati del cliente ed è assegnato un numero d'ordine. Il bottone "Avanti" lancia la cgi "nordine.cgi"
3	La procedura nordine.cgi prendendo in ingresso codice cliente e numero ordine, formatta per il frame Eventi, una pagina html con queste informazioni debitamente nascoste, riportando le categorie merceologiche a listino, oltre alle voci "visiona ordine" e "stampa ordine". Cliccando su una categoria merceologica, p.e. "Hard Disk", si richiama la cgi ordina.cgi a cui vengono passati i dati : codice cliente, numero ordine, categoria merceologica.Cliccando su le voci "Visiona ordine" e "Stampa ordine" si richiama la cgi genera.cgi a cui vengono passati i dati: codice cliente, numero ordine, codice articolo =0 e cancella=0.
4	La procedura genera.cgi riceve in ingresso codice cliente, numero ordine, codice articolo e un flag di nome "cancella" che se impostato a 0 segnala alla procedura di bypassare la routine di cancellazione, se impostato a 1 di eseguirla. Dopodiché la procedura interroga il DB relativamente agli articoli presenti nell'ordine numero xxx; quindi formatta, per il frame "Elecon", i dati ottenuti in una pagina html, con indicate descrizione articolo, quantità, prezzo unitario e un bottone per eliminare quella riga di ordine. Nella pagina sono nascosti i codici relativi agli articoli che vengono passati alla procedura con il flag cancella=1 nel caso si sia premuto il tasto elimina.
5	La procedura ordina.cgi riceve in ingresso i dati codice cliente, numero ordine e gruppo merceologico. Procede interrogando il DB relativamente agli articoli presenti in una specifica categoria merceologica, quindi, formattando, per il frame "Principale", i dati ottenuni in ina pagina html riportando , Descizione articolo, prezzo unitario, una casella per indicare la quantità e un tasto "invia" per inserire nell'ordine uno specifico articolo. Nella pagina formattata rimangono nascosti i dati codice cliente, numero ordine. Al click di un bottone "invia" i dati: codice cliente, numero ordine, codice articolo e quantità , vengono passati alla cgi inserisci.cgi
6	La procedura inserisci.cgi procede a inserire in ordine i dati ricevuti e a formattare per il frame "Principale l'elenco articolo del settore merceologico corrente.

Una volta ultimato l'inserimento dell'ordine si può tornare al link "Home". Per modificare il campo relativo alla quantità di un certo articolo, è necessario cancellare quell'articolo dall'ordine e reinserirlo col nuovo valore del campo quantità

Risultati

Gli strumenti sopraindicati si sono rilevati tutti estremamente efficienti.

Il server Apache e Linux si sono dimostrati efficienti ed estremamente performanti

Il server SQL che ha mostrato grande flessibilità e ottime prestazioni.

Il linguaggio Perl, si è mostrato abbastanza versatile, e moderatamente facile all’uso, manca infatti di un efficace strumento di debug dei programmi script, e l’interpretazione degli errori generati è assai difficile.

CGI ha mostrato forti limitazioni . La presenza su lato Host di un Server Web, di un Server SQL, e l’esecuzione per ogni accesso di uno script da parte dell’host impone scelte hardware costose. Ogni utente che richiede una procedura, indica al server http quale script eseguire. Il server manda in esecuzione lo script e si pone in attesa di una risposta. Lo script Perl ( che deve inoltre essere interpretato!) si interfaccia mediante API al server SQL e attende risultati da formattare per il server http; il quale, ottenuta una pagina come risposta la indirizza al client. La stessa procedura eseguita contemporaneamente da 10 20 utenti (numero modesto e assai lontano dalla realtà) porrebbe seri problemi di tempi di risposta, savo impostare il server per modperl, un modulo che permette di "compilare" il codice perl solo una volta. Inoltre la mera adozione di un linguaggio script lato host, limita l’interattività e dinamicità della pagina web.

Le conclusioni a cui siamo giunti sono le seguenti:

Se possibile, è consigliabile spostare sul lato cliente buona parte dell’elaborazione delle interrogazioni. Strumenti indicati: Java e JDBC
In alternativa è consigliabile usare linguaggi di script non interpretati per ridurre i tempi di risposta.
Sul lato client per ottenere una ceta dinamicità dei dati è consigliato usare un linguaggi di scripting come Javascript.

Ultimo Aggiornamento 25 Gennaio 1999