di Michele Sciabarrà

Il problema che ci siamo posti è di far fare all'azienda il primo passo verso il commercio elettronico e le opportunità di direct marketing offerte da Internet. Poiché la maggior parte delle applicazioni gestionali delle aziende non piccolissime in Italia risiede su AS/400 (è una realtà di mercato ben nota), l'AS/400 è centrale nella nostra soluzione in quanto deve mantenere i dati commerciali per le varie rielaborazioni successive.

La prima applicazione di ecommerce che occorre realizzare deve, nel caso più semplice, consentire di creare (e modificare) un catalogo prodotti, di presentarli all'utente e permettergli di inviare l'ordine. Gli aspetti di presentazione e di marketing sono di dominio di grafici, pubblicitari e webmaster e non li tratteremo qui. Supponiamo invece che il cliente sia giunto alla fase in cui desidera comporre l'ordine. La nostra applicazione avrà dunque le seguenti caratteristiche:

Figura 1

1. Nel contesto di un sito che presenta il catalogo prodotti, l'utente Web arriva alla pagina per effettuare l'ordine di alcuni dei prodotti presentati nel catalogo ( Figura 1 ). Il listino dei prodotti viene mantenuto nel database dell'AS/400.
2. L'utente compone l'ordine e lo invia. Il nuovo ordine verrà notificato al personale commerciale (per esempio tramite l'invio di un messaggio di posta elettronica) .
3. Dopo la ricezione dell'ordine, l'addetto può consultare il dettaglio dell'ordine, verificare le generalità del cliente, eventualmente contattarlo ed infine decidere se dare corso all'ordine.
4. Poiché i prodotti in vendita possono variare nel tempo, il sistema consente di variare il listino senza dover modificare le pagine HTML ( Figura 2 ). Il catalogo presentato può infatti essere facilmente modificato e le modifiche apportate al catalogo sono immediatamente operative online.

Figura 2

Figura 3

Utilizzando l'AS/400 per memorizzare il catalogo prodotti ( Figura 3 ) e gli ordini sono possibili numerose integrazioni del sistema di e commerce con le applicazioni preesistenti. Per esempio:

• Il catalogo può essere collegato alla gestione del magazzino, in modo da avere online una vetrina di merce realmente disponibile.
• La raccolta ordini può essere collegata alla fatturazione e alla contabilità, in modo tale un ordine accettato venga immediatamente fatturato e contabilizzato.
• Integrando il sistema di commercio elettronico con l'archivio clienti è possibile consentire al personale commerciale sia immediate verifiche sul cliente, sia nuove possibilità di indagini di marketing.

Figura 4

Tale architettura è sintetizzata in Figura 4 . Esaminiamo le ragioni tecniche delle varie scelte. Riteniamo che tale architettura sia la più comune e realistica considerando l'offerta commerciale e il panorama tecnologico del mercato italiano attuale.

La scelta n. 1 è assolutamente naturale sia perché normalmente sull'AS/400 risiedono tutte le informazioni dell'azienda, ma anche e soprattutto in vista delle possibili integrazioni del catalogo con il gestionale.

La ragione della scelta n. 2 è più complessa. Bisogna dire innanzitutto che l'AS/400 rappresenta di per sè una buona soluzione come Web Server. Tuttavia quando su tale macchina risiedono anche informazioni vitali per l'azienda (come è del tutto naturale) occorre riconsiderare con molta cautela la scelta di esporre la macchina ad Internet. Infatti, nonostante la macchina in sé possa essere considerata sicura, può essere sempre violata non necessariamente per motivi tecnici ma anche (e soprattutto) per motivi legati al fattore umano. È infatti nota la difficoltà con cui (purtroppo) si riesce ad educare il personale ad osservare le necessarie misure di sicurezza. Per questo motivo è molto meglio non correre rischi e non esporre direttamente la macchina ad Internet. Meglio invece mantenere la macchina protetta dietro un firewall e far girare l'applicazione di e-commerce in una macchina presso un provider che si occuperà anche della necessaria manutenzione. Tale manutenzione è sufficientemente complessa da consigliare un outsourcing invece di gestirla in casa. Si provvederà invece ad attivare una linea diretta al provider e consentire una sola interazione, molto più facilmente controllabile, tra l'applicazione di e-commerce e l'AS/400. L'interconnessione con il provider utilizzerà una linea a Circuito Diretto Numerico, che è lo standard proposto da Telecom Italia per le connessioni dati permanenti. Questo tipo di linee sono utilizzate per le connessioni permanenti della maggior parte degli Internet Service Provider, ed hanno un costo che continua a diminuire, anche per .effetto della recente deregulation nelle telecomunicazioni.

Per quanto riguarda le ragioni della scelta nr. 3, dobbiamo considerare innanzitutto che i provider utilizzano generalmente Web Server con sistemi Unix o Windows NT. Questo requisito porta alla necessità di utilizzare un linguaggio compatibile sia con Unix che con Windows NT, che disponga di una buona connettività all'AS/400. Fino a qualche tempo fa si sarebbe ricorso ad un mix di linguaggi (Visual Basic, C++ e RPG) e alla rassegnata consapevolezza di dover riscrivere l'applicazione quando da Unix si desideri passare Windows NT, a un Domino con AS/400 o altre piattaforme (per esempio per cambio di provider o potenziamento dell'applicazione). Queste problematiche hanno un ovvio impatto sui costi. Oggi, grazie a Java è finalmente disponibile una soluzione ottimale:

• Innanzitutto l'applicazione è realmente portabile tra NT, Unix e AS/400.
• La connettività tra l'AS/400 e le applicazioni Java è eccellente grazie all'AS/400 Toolbox di IBM.
• Il linguaggio è sempre più supportato da terze parti, viene insegnato nelle scuole e guadagna consensi sia nella comunità dei programmatori Visual Basic che C++.
• Ultimo ma non meno importante fattore, Java è considerato il linguaggio designato per applicazioni di commercio elettronico e Internet in generale, per cui è il più supportato sia in termini di librerie che di integrazione con tool esistenti. Per esempio basta considerare il fatto tutti i principali Web Server (Domino compreso) supportano l'integrazione di Java.

Consideriamo infine la quarta scelta. Una volta costruita l'applicazione è opportuno dotare gli addetti al trattamento degli ordini di un applicativo user friendly per la loro gestione. Generalmente in ambito client la portabilità è un requisito meno stringente rispetto alla facilità d'uso e alla integrazione con gli strumenti di produttività individuale. Tra gli strumenti di sviluppo disponibili specificamente per AS/400, si è utilizzato il Borland Delphi /400 per la realizzazione del trattamento degli ordini. In questo articolo comunque ci concentriamo sul lato server ed esaminiamo le tecnologie Java utilizzate.