SAP R/3

Breve guida sul Linguaggio

ABAP 4
di Fernando Scatena
by Manuali.it

http://www.manuali.it - Per mettersi contatto con lautore

manda una email ad info@manuali.it

INTRODUZIONE A SAP/R3............................................................................................................3
CARATTERISTICHE GENERALI DI ABAP................................................................................5
LE FASI E I LIVELLI DI SVILUPPO............................................................................................7
ARCHITETTURA SOFTWARE DEL SISTEMA SAP..................................................................8
LIVELLO DATABASE..........................................................................................................................8
LIVELLO APPLICAZIONI.....................................................................................................................9
LIVELLO PRESENTAZIONE.................................................................................................................9
VANTAGGI DELL'ARCHITETTURA A LIVELLI....................................................................................10
APPLICATION SERVER...............................................................................................................11
WORK PROCESSES...........................................................................................................................11
DISPATCHER....................................................................................................................................11
GATEWAY........................................................................................................................................11
SHARED MEMORY...........................................................................................................................12
CONNESSIONE AL DATABASE..........................................................................................................12
WORK PROCESSES..........................................................................................................................12
STRUTTURA DEI PROGRAMMI ABAP....................................................................................14
PARTE DICHIARATIVA.....................................................................................................................14
BLOCCHI DI PROCESSO.............................................................................................................15
CHIAMATE DEI BLOCCHI DI PROCESSO............................................................................................15
TIPI DI PROGRAMMI........................................................................................................................15
BLOCCHI DI PROCESSO....................................................................................................................17
IL DATABASE LOGICO.....................................................................................................................18
IL LINGUAGGIO ABAP................................................................................................................19
DICHIARAZIONI...............................................................................................................................19
ISTRUZIONI DI MODULARIZZAZIONE...............................................................................................19
STRUTTURE DI CONTROLLO............................................................................................................20
ISTRUZIONI DI CHIAMATA...............................................................................................................20
ISTRUZIONI OPERAZIONALI.............................................................................................................20
ISTRUZIONI PER IL DATABASE.........................................................................................................20
TIPI DI DATI E OGGETTI..................................................................................................................21
INTERFACCIAMENTO CON L'ESTERNO DI SAP R/3..........................................................23
AGGIORNAMENTO DELLE TABELLE STANDARD...............................................................................26
INTEGRAZIONE DI SAP CON ALTRE APPLICAZIONI TRAMITE OLE..................................................26

Introduzione a SAP/R3
SAP unazienda europea che ha saputo esportare nel mondo un nuovo modo di gestire
le risorse delle imprese. Il suo successo legato ad R/3, un prodotto che ha
unarchitettura per lassetto organizzativo dellimpresa in grado di affrontare mercati del
futuro
SAP R/3, indicato comunemente con il termine SAP, conosciuto da alcuni come un
nuovo linguaggio di programmazione, altri suggeriscono un database ( o DBMS, DataBase
Management System), altri ancora lo individuano come un pacchetto per gestire la
contabilit o il magazzino.
In realt SAP tutto questo, una struttura informativa, ma anche un database
relazionale ed anche un sistema di sviluppo.
E un sistema gestionale integrato e abbastanza complesso, suddiviso in aree applicative.
Le aree applicative sono i settori o le zone di operativit di unazienda. I principali settori di
attivit (finanziario, logistico e gestione risorse umane) sono gestiti interamente dal
sistema R/3. Come la maggior parte dei prodotti sul mercato, il dialogo con lutente si
realizza con gli strumenti di Windows cio i classici elementi "finestre" e "popup". Ogni
funzione della singola applicazione, interagisce simultaneamente con pi processi; R/3
quindi unintegrazione di processi che interagiscono in modo armonico tra loro in tempo
reale.
(Ad esempio, quando unofferta tramutata in ordine viene aggiornato lo stato dei
fabbisogni ed creato tutto liter necessario per la consegna e la fatturazione. E il sistema
stesso ad amministrare i flussi logici e a rilevare eventuali incongruenze.)
Il sistema ha unarchitettura di tipo client/server.
R/3 il software che si trova fra le applicazioni SAP e il sistema di base. Esso realizzato
per tutte le principali piattaforme UNIX, NT e AS400.
Il linguaggio utilizzato per lo sviluppo in SAP R/3 ABAP/4(Advanced Business
Application Programming), un linguaggio interpretato.
Nel mondo del lavoro cresce la domanda di figure legate al mondo degli ERP e in
particolare di SAP (che una specie di standard de facto).
Uno dei principali vantaggi del sistema SAP R/3 che un SISTEMA APERTO
che consente:

Portabilit: attraverso lutilizzo degli standard POSIX e X/Open - standard industriali

che permettono la interoperabilit di applicazioni, dati e interfacce utente.

Copertura: lutilizzo di protocolli standard come TCP/IP, EDI, OLE, permette di

interfacciare il sistema R/3 con applicazioni per PC su vasta scala.

Espansione: Il linguaggio ABAP permette di sviluppare nuovi application module da

aggiungere a quelli esistenti.

Caratteristiche generali di ABAP

SAP R/3 un software gestionale integrato che consente di informatizzare l'intera
organizzazione di un'azienda.
E' costituto di moduli standard che possono essere configurati (personalizzati e adattati a
seconda dell'organizzazione aziendale in cui vengono utilizzati) e collegati tra loro.
All'interno dell'ambiente SAP disponibile un linguaggio ABAP/4 per lo sviluppo dei
componenti software necessari per integrare SAP ad altri programmi di gestione.
ABAP/4 il linguaggio creato dalla SAP AG per l'implementazione e lo sviluppo del
sistema SAP/R3.

ABAP/4 l'acronimo di Advanced Business Application Programming.

Sviluppato da SAP per lo sviluppo interattivo di programmi applicativi

Con ABAP/4 possibile:

Creare del software completamente nuovo, per il quale non esiste alcun programma
standard SAP, che pu essere personalizzato per adattarsi alla propria azienda

Lavorare su copie di componenti gi esistenti, ottimizzandoli e personalizzandoli

ulteriormente.

In entrambi i casi, la ferrea disciplina di controllo esercitata da ABAP/4 assicurer che il

software risultante sia in grado di essere eseguito immediatamente su tutti i tipi di
computer e su tutti i sistemi di database supportati da SAP.
Dato che ABAP/4 un linguaggio interpretato, qualsiasi chiamata ad una funzione provoca
la reinterpretazione del codice, completa di tutte le modifiche rilasciate dopo lattivit di
sviluppo.
Gli sviluppatori che lavorano in ambiente SAP R/3 non devono preoccuparsi delle
complessit delle reti Client/Server; i moduli applicativi sviluppati, infatti, possono essere
eseguiti localmente o su computer host centrali, e possono utilizzare uno qualsiasi dei
server esistenti.
Il software SAP stato progettato e continua ad essere progettato, principalmente
attraverso ABAP/4. Le uniche eccezioni sono costituite da quelle parti del sistema BASIS
che devono essere progettate per la particolare piattaforma hardware sulla quale R/3 deve
essere eseguito.

6
I principali usi dei programmi ABAP/4 sono:
Reporting
Sviluppo di programmi di dialogo degli utenti
Personalizzazione di R/3 secondo le esigenze individuali dei clienti
Esso un linguaggio strutturato a blocchi che assomiglia molto ad un incrocio tra PL/SQL
della Oracle e PL/I della IBM.

Le fasi e i livelli di sviluppo

Lo sviluppo di programmi deve attraversare diverse fasi e cicli per provare che il software
sar effettivamente in grado di fare ci per cui stato realizzato, e senza creare problemi.
ABAP/4 si aspetta che gli sviluppatori di programmi abbiano bisogno di aiuto e supporto
durante lintero processo, e che tutte le applicazioni sviluppate dovranno prima o poi
essere sottoposte a manutenzione; a tal fine, ABAP/4, in grado di conservare il materiale
con cui ha lavorato per permettere di consultare ogni singola parte in qualsiasi momento
successivo.
Qualsiasi nuovo sistema o componente aggiunto ad una implementazione gi esistente
dovr comunicare con il resto del sistema, utilizzando inoltre tutte le funzionalit hardware
e software nel modo pi efficiente possibile.
Le linee guida sono le seguenti:

Deve essere raggiunta la consistenza dei dati mantenendo i master data in un unico
luogo.

Non devono esserci interruzioni nei canali tecnologici di comunicazione, e devono

essere presentati dei default per evitare il pi possibile un eccessivo inserimento di dati
manuali.

I componenti software devono essere progettati per essere trasportati verso nuove
piattaforme, via via che i produttori di dispositivi e di attrezzature migliorano i propri
prodotti, utilizzati per assemblare sistemi complessi.

Gli sviluppatori di applicazioni che utilizzano ABAP/4 riceveranno tutto il supporto

necessario per poter lavorare a qualsiasi livello di dettaglio:

Metadati per lo sviluppo di applicazioni

Proposte e standard per interfacciarsi con i database

Interfacce standard per il collegamento a qualsiasi rete gi impostata ( per esempio,

per comunicare con i sistemi SAP R/2 e con i servizi di database forniti per specifici
settori industriali e non)

Procedure per la progettazione dettagliata di interfacce grafiche utente, al fine di

soddisfare sia i requisiti della nuova applicazione che la necessit degli utenti futuri.

Architettura software del sistema SAP

Prima di descrivere con maggior dettaglio il linguaggio ABAP, dobbiamo innanzitutto
conoscere l'architettura software nella quale tale linguaggio opera.
L'architettura software di SAP/R3 organizzata secondo il modello Client/Server,
cio il BSS(Basis Software System).
Essa pu essere schematizzata come in figura:

Analizziamo con maggior dettaglio i vari strati software che vanno a formare la classica
configurazione del sistema SAP R/3:

Livello Database
Il livello database consiste in sistema centrale di database contenente tutti i dati del
sistema R/3.
Il sistema database ha 2 componenti:

Il Database Management System (DBMS)

Il Database Server

9
Il sistema SAP R/3 supporta i seguenti altri database di altri fornitori:
ADABAS D, DB"/400, DB2/Common Server, DB2/MVS, INFORMIX, Microsoft SQL Server,
ORACLE e ORACLE Parallel Server.
Il database non solo contiene i master data e i dati delle transazioni delle business
application, ma tutti i dati dell'intero sistema R/3 memorizzato in esso.
Ad esempio, il database contiene il controllo e i dati sotto i quali il sistema gira, il codice
dei programmi delle varie applicazioni.
Le applicazioni possono essere codice di programma , screen definition, menu, moduli e
svariati altri componenti.
Queste applicazioni sono memorizzate in una speciale sezione del database chiamata R/3
Repository. Si pu lavorare su di esso mediante l'utilizzo dell'ambiente di sviluppo dei
programmi ABAP chiamato ABAP Workbenk.

Livello Applicazioni
Il livello applicazioni consiste in uno o pi application server e un message server.
Ciascun application server contiene un insieme di servizi utilizzati per far girare il sistema
R/3. In teoria ciascun application server pu eseguire pi servizi, in pratica uno stesso
servizio pu essere eseguito tra pi application server.
Il message server responsabile della comunicazione tra i vari application server. Esso
quindi si occupa di gestire le richieste tra un application server e gli altri presenti nel
sistema. Contiene inoltre delle informazioni circa lo stato degli application server e il carico
dei dati sugli stessi. Questa informazione pu essere utilizzata per la scelta di un
appropriato server su cui far collegare gli utenti nel sistema.

Livello Presentazione
Il livello presentazione contiene i componenti software che formano il SAPgui (Interfaccia
Grafica dell'Utente). Questo livello l'interfaccia tra il sistema R/3 e gli utenti.
Il sistema R/3 utilizza il SAPgui per fornire una intuitiva interfaccia grafica agli utenti per
immettere e visualizzare i dati.
Il livello presentazione manda l'input dell'utente verso l'application server e riceve dati da
esso per poi visualizzarli verso l'utente.

10
Questo architettura software permette di includere un altro strato che fa espandere il
sistema, tale strato chiamato Internet Transaction Server

( ITS ).

Vantaggi dell'architettura a livelli

L'utilizzo di un architettura a livelli porta a molti vantaggi tra i quali i pi significativi sono:

scalabilit: aggiunta di nuovi application server o utenti.

flessibilit: nuove applicazioni senza cambiare il BSS.

personalizzabilit: la modifica delle funzioni di business e della struttura

organizzativa non cambia il BSS

11

Application Server
Per poter studiare in dettaglio le caratteristiche del linguaggio ABAP/4 sul sistema SAP/R3
bisogna analizzare in modo dettagliato l'application server.
L'application server il luogo dove vengono eseguiti tutti i programmi di SAP R/3.
La struttura dell'application server la seguente:

Work Processes
Un application server contiene uno o pi work processes (processi di lavoro), che sono dei
componenti sui quali girano le applicazioni.
Il numero e il tipo dei work process viene definito quando il sistema SAP viene fatto
partire. Ciascun work process collegato ad un area di memoria contenente le
informazioni e i dati relativi all'applicazione che sta girando.

Dispatcher
Ciascun appllication server contiene un dispatcher. Un Dispatcher il collegamento tra i
work process e gli utenti collegati con l'application server.
Questo task riceve richieste dagli utenti con il SAPgui e direziona questi verso un work
process libero. Allo stesso modo, direziona l'output risultante verso l'utente che l'ha
richiesto.

Gateway
Ciascun apllication server contiene un gateway. Il gateway l'interfaccia per i protocolli di
comunicazione del sistem SAP R/3 ( RFC, CPI/C ).
Il gataway pu far comunicare con altri application server nello stesso sistema R/3, con
altri sistemi R/3, con sistemi R/2 o con Sistemi che non sono SAP.

12

Shared Memory
Tutti i work process di un application server usano un comune area di memoria chiamata
shared memory (memoria comune ) per salvare contesti o dati locali.
Le risorse che tutti i work process ( come programmi e tabelle) usano sono contenute nella
shared memory.
La gestione della memoria nel sistema R/3 assicura che tutti i work processes siano
indirizzati correttamente nel giusto contesto.
La memorizzazione locale dei dati nella shared memory nell'application server riduce il
numero di accessi in lettura al database, con una conseguente riduzione dei tempi di
accesso da arte dei programmi applicativi.
OSS. Per un uso ottimale del buffer di memoria, si possono concentrare le applicazioni
individuali (financial accounting, logistica, risorse umane ) in gruppi separati di application
server.

Connessione al database
Quando si avvia il sistema R/3, ciascun server application registra i suoi work process nel
livello database, e riceve un singolo canale dedicato.
Finch il sistema R/3 sta girando, ciascun work process un client del sistema database
che fa da server.

Work Processes
Struttura dei work process
Ciascun work process contiene 2 processori software ed un interfaccia al database.
Screen Processor
Nei programmi che utilizzano applicazioni R/3 c' una differenza tra interazioni utente e
processi logici.
L'interazione con l'utente viene gestita dai screens, che sono programmi che controllano
l'interazione tra utente e sistema.

13
Il sistema R/3 prevede uno speciale linguaggio per permettere la programmazione dei
screen, tale linguaggio contenuto nell'ABAP Workbench.. Questi programmi risiedono
nel processore degli screen.
Il compito di uno screen quello di gestire la comunicazione attraverso delle maschere tra
gli utenti e il sistema, ricevendo in input dati e fornendoli all'utente come output.

ABAP Processor
Il processo logico di un programma applicativo scritto in ABAP che come sappiamo il
linguaggio di programmazione su xcui si sviluppato il sistema SAP.
Il processore ABAP esegue il processamento logico dei programmi applicativi e comunica
con il database interface.
Lo screen processor comunica con al processore ABAP, attraverso lo screen flow logic,
quale il prossimo modulo che deve essere processato.

Database Interface
Il database interface svolge i seguenti servizi:

Stabilisce le connessioni tra work process e il database.

Permette l'accesso alle tabelle del database

Permette l'accesso agli oggetti dell'R/3 Repository (programmi ABAP, screen )

Permette l'accesso al catalogo informazioni (ABAP dictionary)

Controlla le transazioni

Amministra la tabella dei buffer dell'application server

14

Struttura dei programmi ABAP

I programmi ABAP sono responsabili del processamento dei dati all'interno del sistema
R/3.
Un programma ABAP non composto da una singola sequenza di istruzioni, ma ha una
struttura modulare.
Ciascun modulo chiamato processing block. Ciascun processing block consiste di un
insieme di istruzioni ABAP. Quando viene fatto girare un programma ABAP, ci sono una
serie di chiamate a blocchi di processo.
La modularit dei programmi, permette quindi di scrivere uno stesso programma da
persone diverse, inoltre consente la possibilit di espansioni future.
Ciascun programma ABAP costituito dalle seguenti due parti:

Parte Dichiarativa
La prima parte di un programma ABAP la parte dichiarativa di dati globali, selezione dei
screen e classi.
Queste consistono di:

Dichiarazioni dei dati globali, visibili in tutti i blocchi di processo interni.

Si possono definire le dichiarazioni prima del primo blocco di processo, nel modulo o
nei blocchi di evento.

Definizione degli screen

Definizione locale di classi (CLASS DEFINITION ). Le classi costituiscono una parte di

ABAP Objects, cio dell'estensione di ABAP ad un linguaggio orientato agli oggetti.

Le istruzioni di dichiarazione possono essere definite in ogni routine (metodi, subroutines,

moduli) nella parte dichiarativa delle stesse. La visibilit locale nella routine nella quale
vengono dichiarate.

15

Blocchi di processo
La seconda parte di un programma ABAP contiene tutti i blocchi di processo di un
programma ABAP. I blocchi di processo possono essere:

Moduli di dialogo

Blocchi di evento

Routines (metodi, subroutines, moduli di funzione)

Chiamate dei blocchi di processo

Si possono chiamare i blocchi di processo dall'esterno di un programma ABAP oppure
utilizzando i comandi ABAP.
La chiamata di blocchi di evento differente dalla chiamata dei blocchi di processo per le
seguenti ragioni:
La chiamata ad un blocco di evento causata dal verificarsi di un evento. Quando questo
si verifica, verranno eseguite delle opportune istruzioni, definite nel corrispondente blocco,
che descrivono quale debba essere la reazione del sistema al verificarsi di tale evento.

Tipi di programmi
Nel sistema R/3, ci sono vari tipi di programmi ABAP. Il tipo di programma determina degli
attributi di base del programma stesso, che possono essere settati al momento della
creazione del programma stesso.
Ci sono due possibili modi per permettere agli utenti di far eseguire un programma:

Digitando il nome del programma

Digitando il codice di transazione

Possiamo definire i seguenti tipi di programma per le varie applicazioni:

16

Tipo 1

I programmi di Tipo 1 hanno un importante caratteristica. Non possono essere controllati

utilizzando gli screen. Essi sono controllati da un programma di sistema invisibile che
chiama una serie di blocchi di processo in una sequenza fissata.
Si pu far partire un programma di Tipo 1 usando l'istruzione SUBMIT da un altro
programma ABAP.
Il programma di sistema invisibile esegue una serie di comandi, processa dati e fornisce
dei risultati in una lista definita dai programmatori.
Lavora inoltre con il database logico che un uno speciale programma ABAP che
associato alle tabelle dei database, processa questi dati e li visualizza all'utente.

Tipo M

I programmi di Tipo M possono essere controllati utilizzando gli screen flow logic.
Si pu far partire tale programma usando il codice di transazione, in questo modo viene
chiamato lo screen iniziale.
I programmi ABAP di tipo M contengono i moduli di dialogo appartenenti ai vari screen.
Essi vengono anche chiamati module pools.

Tipo F

I programmi di Tipo F contengono le funzioni dei moduli, conosciuti anche come function
groups. Per poter definire tali programmi viene utilizzato il Function Builder che un tool
di ABAP Workbench.
I function groups possono contenere dichiarazioni di dati globali e subroutines.

Tipo I

I programmi di Tipo I, chiamati anche fppos, sono il mezzo per dividere il codice di un
programma in piccole unit maneggevoli.
Si possono cos inserire all'interno di programmi altri programmi attraverso l' istruzione
INCLUDE.
All'interno di Abap Workbench c' un meccanismo automatico che permette di dividere
moduli e gruppi di funzione attraverso degli include programs.

17

Blocchi di processo
In questa sezione vengono descritti i vari blocchi di processo che possiamo trovare in un
programma ABAP.

Dialog Modules

Possono essere chiamati da uno screen nel seguente modo:

MODULEENDMODULE

Blocchi di processi causati da eventi:

Il verificarsi di un certo evento provoca una determinata reazione da parte del sistema:
<event keyword>
event statements
<event keyword>
event statements

Subroutines che sono locali chiamate FORM

FORM..ENDFORM

Possono essere definite in ogni programma ABAP.

Funzioni incapsulate globali definite chiamate FUNCTION MODULES

FUNCTION..ENDFUNCTION

Si pu richiamare una funzione utilizzando la direttiva CALL FUNCTION.

18

Il Database Logico
Il database logico uno speciale programma ABAP che legge i dati dalle tabelle del
database. Esso viene utilizzato per poter eseguire programmi di Tipo 1. A runtime si pu
considerare il database logico e i programmi eseguibili (reports ) come un singolo
programma ABAP, i blocchi di processo sono chiamato dal sistem program in una
particolare sequenza predefinita.
SAP supporta il database logico per ogni applicazione.

19

Il linguaggio ABAP
Il codice sorgente di un programma scritto in ABAP consiste di istruzioni ABAP e di
commenti.
Per quanto riguarda i commenti, possono essere definiti tra i simboli * (all'inizio di una
linea ) e " (in ogni posizione di una linea ).
Le istruzioni ABAP iniziano sempre con una ABAP keyword ed conclusa da un punto (.) .

Dichiarazioni
Definiscono il tipo di dato o dichiarano oggetti che possiamo trovare nei programmi ABAP.
Esempi di dichiarazioni:
TYPES, DATA, TABLES

Istruzioni di Modularizzazione
Queste istruzioni definiscono i blocchi di processo nei programmi ABAP.
Si possono suddividere in:
Event Keywords
Si utilizzano tali istruzioni per definire blocchi di evento:
AT SELECTION SCREEN,

START OF SELECTION,

AT USER COMMAND

Defining keywords
Istruzioni che permettono di definire subroutines, function modules, dialog modules e
metodi:
FORMENDFORM, FUNCTIONENDFUNCTION,
MODULEENDMODULE.

20

Strutture di controllo
Le istruzioni di controllo all'interno di un programma ABAP sono le seguenti:
IF ,

WHILE,

CASE

Istruzioni di chiamata
Le istruzioni per chiamare blocchi di processo definiti usando le istruzioni per la
modularizzazione sono le seguenti:
PERFORM, CALL, SET USER-COMMAND, SUBMIT, LEAVE TO

Istruzioni operazionali
Queste istruzioni processano i dati definiti nelle dichiarazioni, esempi sono:
WRITE, MOVE, ADD

Istruzioni per il database

Queste istruzioni usate dal database interface per accedere allle tabelle del sistema di
database centrale. Ci sono due tipi di istruzioni per poter accedere al database in ABAP:
Open SQL e Native SQL.

Open SQL
Open SQL un sottoinsieme di istruzioni dello linguaggio standard SQL92.
Esse contengono solo istruzioni per il Data Manipulation Language (DML) quali possono
essere:

SELECT, INSERT e DELETE, mentre non contengono istruzioni per il Data

Definition Language (DDL) come: CREATE TABLE o CREATE INDEX.

21
I programmi ABAP che utilizzano solamente istruzioni OpenSQL per accedere ai database
sono pienamente portabili su tutte le piattaforme.
Il database interface si occupa della conversione dei comandi di OpenSQL nei comandi di
altri possibili database.

Native SQL
Le istruzioni di Native SQL sono passate direttamente dal database interface al database
senza una conversione e permette l'utilizzo dei comandi DDL.
Il dizionario di ABAP utilizza Native SQL per i task che utilizzano le tabelle dei database. I
programmi ABAP utilizzano le istruzioni di Native SQL solo quando devono lavorare su un
database specifico, perch tali programmi non sono standardizzati per interfacciarsi con
SQL92.

Tipi di Dati e Oggetti

Tipi di dato predefiniti
Ci sono cinque tipi di dato predefiniti non numerici:
Character string (C), Numeric character string (N), Date (D),
Time (T) e Hexadecimal (X)
E tre tipi predefiniti numerici:
Integer (I), Foating point number (F) e Packed number (P).
Il numero di byte field length dei tipi D,F,I e T e fisso, mentre per i tipi C,N,X e P si pu
definire la lunghezza dichiarandola direttamente nel programma.
In particolare il tipo P utilizzato per calcoli esatti nel contesto business.
E' inoltre possibile definire altri tipi di dato attraverso l'istruzione TYPES.
Si utilizzano i tipi di dato per poter gli oggetti su cui si va a lavorare, come ad esempio dati
per l'input e l'output, dati su cui effettuare calcoli e cos via.

22

Tipi di dati strutturati

I tipi di dato strutturati possono essere Strutture (records) o Tabelle Interne

Strutture
Una struttura e una sequenza di tipi di dato definita dall'utente. Si pu accedere all'intero
oggetto oppure ad un componente individuale

Tabelle Interne
Le Tabelle Interne consistono in una serie di linee che hanno tutte lo stesso tipo.
Vengono utilizzate per memorizzare dati presenti nel database all'interno del programma.
Esse sono caratterizzate da:
Il tipo di linea : che pu essere dati per ABAP, un tipo elementare, una struttura o una
tabella interna.
Una chiave: utilizzata per poter identificare le entrate alla tabella. Ovviamente tale
chiave unica.
Il tipo di accesso: determina quale tipo di accesso viene fatto alla tabella da parte dei
programmi. Ci sono tre modalit di accesso:

Tabella non ordinata

Tabella ordinata con indici (si accede tramite indici)

Hash Table (si accede tramite una funzione hash calcolata da un

apposito algoritmo)

Quando definiamo una Tabella Interna specifichiamo solo la dimensione degli oggetti su
cui andiamo ad operare, cio fissiamo la lunghezza delle righe.
Il numero di righe invece adattato dinamicamente a runtime.

23

Interfacciamento con l'esterno di SAP R/3

Un aspetto fondamentale dei sistemi informativi la possibilit di scambiare, aggiornare
informazioni con altri sistemi anche se differenti.
Il sistema SAP R/3 offre diverse possibilit per aggiornare il proprio database attingendo
informazioni dal mondo esterno.
Si ricorre all'aggiornamento dei dati, tramite opportune tecniche d'interfacciamento, ogni
qualvolta il sistema non dispone nel proprio database di particolari informazioni.
Il metodo dell'aggiornamento dei dati pu essere implementato in diversi modi.
L'approccio pu essere semplice oppure pu seguire strade pi o meno tortuose in base
al metodo utilizzato.
Per lo sviluppo di nuove applicazioni, come gi abbiamo detto, si utilizza il Worchbench
ABAP/4.
Un possibile esempio l'utilizzo di file quando necessario esportare dati da SAP/R3
verso sistemi con caratteristiche tecnologiche diverse.
Un metodo d'aggiornamento molto semplice consiste nello scambio di informazioni
utilizzando dei file di appoggio.
La gestione dei file nel sistema R/3 ha solitamente le seguenti caratteristiche:

Accesso ai dati di tipo sequenziale

Lunghezza dei record fissa

Non possibile adottare separatori di campo

La gestione in base alle caratteristiche dell'ambiente, eseguita con due strategie diverse.
Se il file localizzato nel File System del rispettivo Application Server,

24

SAP R/3
READ DATASET

File

Record

Programma
ABAP/4

TRANSFER

Application
Server

allora si pu applicare il seguente metodo:

Per eseguire la lettura:

Apertura del file con il comando OPEN DATASET

Ciclo di lettura READ DATASET

Chiusura del file CLOSE DATASET

Per eseguire la scrittura:

Apertura del file con il comando OPEN DATASET

Ciclo di scrittura TRANSFER

Chiusura del file CLOSE DATASET

Se invece il file localizzato in un area del Presentation Server:

25

SAP R/3
WS_UPLOAD()

Tabella
Interna

File

Sistema
Locale

Programma
ABAP/4

WS_DOWNLOAD()

vale a dire nel personal computer o della workstation, i precedenti comandi non sono pi
utilizzabili.
Il file in questo caso locale e deve essere gestito con altri comandi.
Il file viene quindi gestito con due funzioni di sistema dedicate a tale scopo:
WS_DOWNLOAD(), per la scrittura dei dati;
WS_UPLOAD(), per la lettura dei dati.
Per l'utilizzo corretto di queste funzioni indispensabile operare con Tabelle Interne,
dichiarando una struttura in grado di contenere correttamente le informazioni che devono
essere trasferite.
La struttura pu essere dichiarata direttamente nel programma con le istruzioni:
010 DATA: BEGIN OF myTable OCCURS 10.
020 field(2) type c,
030 field(12) type c.
040 DATA: END of myTable.

26
Altrimenti se la struttura utilizzata da pi programmi, allora, pu essere dichiarata nel
dizionario dati, utilizzando il tools ABAP/4 Dictionary e richiamata come segue:
010 DATA: BEGIN OF myTable OCCURS 10.
020 INCLUDE STRUCTURE zmystruct.
030 DATA: END of myTable.
Nel corso del programma alla tabella interna saranno assegnati dei valori e al termine sar
utilizzata dalla funzione di trasferimento.
Supponiamo ad esempio, di voler trasferire delle informazioni sulle spedizioni che
dovranno essere effettuate. S'invia quindi il codice cliente, i riferimenti dell'ordine, ecc.
Queste informazioni sono l'input di un sistema esterno che rileva e associa tali dati.
Successivamente un programma ABAP/4 legge il file locale generato e trasferisce le
informazioni nel sistema R/3. In questo modo il programma completa il documento di
spedizione.
Dopo aver eseguito la lettura del file vengono assegnati dei valori alla tabella, quindi il
contenuto pu essere utilizzato per aggiornare la base di dati.

Aggiornamento delle tabelle standard

L'aggiornamento delle tabelle, se trattasi di tabelle standard, pu essere eseguito con i
batch input.
I dati importati da sistemi esterni dentro il sistema, prima di essere memorizzati
permanentemente nel database, devono essere convalidati dalla relativa applicazione.
Si ricorre a tale tecnica di aggiornamento quando si ha un'ampia mole di dati che devono
essere inseriti.
In generale i batch input sono eseguiti durante migrazioni dei dati da sistemi host per
inizializzare un nuovo sistema R/3 oppure quando devono essere caricati dati dall'esterno.
Il batch input una procedura automatica che permette il trasferimento dei dati nel
sistema mediante opportune transazioni. In concreto i batch input sono programmi scritti in
ABAP.
In questo modo viene effettuato l'input dei dati senza l'intervento manuale dell'utente.
E' il sistema SAP che garantisce l'integrit dei dati.

27

Integrazione di SAP con altre applicazioni tramite OLE

IL workbench ABAP/4 offre la possibilit di utilizzare la tecnologia OLE ( Object Link
Embedding).
OLE consente di integrare le applicazioni residenti sulla workstation locale o personal
computer (Excel, Word, ecc.) con il sistema R/3.

SAP R/3
Object

Sistema
Locale

Programma
ABAP/4

Tabelle
App. OLE

Gli oggetti OLE, che si vogliono usare in R/3, devono essere registrati nelle tabelle relative
a tale scopo. In esse sono contenute le informazioni per richiamare i server OLE da
programmi ABAP/4 e le informazioni legate all'oggetto. L'aggiornamento, l'inserimento o la
cancellazione di elementi nella tabella demandata al DB-Administrator.
Ogni qualvolta che si utilizza la tecnologia OLE i dati subiscono una doppia conversione di
tipo:

28

Dati convertiti in tipo char

Adattamento del tipo al tipo della variabile ricevente.

Per poter richiamare un oggetto OLE in un programma ABAP/4 si utilizzano le seguenti

istruzioni:

CREATE OBJECT : permette di richiamare un oggetto dall'OLE server

CALL METHOD OF(): richiama un metodo dell'oggetto OLE

SET PROPERTY OF: assegna un valore ad una propriet o ad un metodo dell'oggetto

GET PROPERTY OF: legge un valore di una propriet o di un metodo dell'oggetto e la

posiziona nella variabile val

FREE OBJECT: lascia le risorse