APPUNTI BW

SAP BW è un business wharehouse che si interfaccia e può recepire dati da diversi sistemi: altri
moduli SAP, qualsiasi database, file, http.
I sistemi con cui BW è collegato devono essere mappati; SAP fornisce nativamente una modalità
di connessione tra i vari sistemi e moduli gestibili dalla transazione SM59, in cui si trovano le
connessioni RFC (Remote Function Call) con ambienti esterni, sotto la cartella ABAP connection.
Solo il collegamento con i file non è mappato in SM59 perchè è BW stesso che mi fornisce questo
tipo di collegamento.

Su RSA1 - per l'operatività di bw vengono censite solo le connessioni non in

dialogo (le quali avranno un user di servizio che mi dà accesso diretto alle funzionalità di
caricamento dal sistema sorgente - così non devo ogni volta loggarmi, cosa che sarebbe
necessaria in dialog).
Quello che mi permette di estrarre da sistemi esterni è un Infopackage, che estrae sempre in full
dal momento che BW non è in grado di definire un delta dai sistemi esterni. Nell'infopackage
definisco quali sono i campi che sto caricando e posso averne una preview per valutare la
correttezza dell'estrazione. Dal tab Execute l'infopackage può anche essere schedulato
autonomamente. Quando si clicca su execute semplicemente si lancia un codice ABAP che in
alcune release di BW è visibile dal menu in alto Extras -> Display generated program.
Se carico un file da pc non posso farlo in batch ma solo in dialog, dunque non posso schedularlo
ma dev'essere x forza un'esecuzione diretta.
A seconda di cosa carico definisco una mappatura tra la sorgente e destinazione tramite la PSA
per permettere di caricare i dati mappati correttamente e di averli dunque in BW (nella vecchia
versione di BW da infopackage si poteva andare direttamente in ods/cubi). La PSA tramite il
manage permette di vedere le request; di solito si seleziona una request e con la pila di gettoni si
vedono i dati di quella request suddivisi in packet. Se la PSA ha più di una request posso vedere
cmq tutti i dati andando sulla PSA maintenance (doppio click, simbolo martello e cacciavite), anche
se il modo immediato di vedere i dati è quello di selezionare la singola request dopo il manage
(questo perchè si suppone di svuotarla e ricaricarla ogni volta dato che gli infopackage estraggono
in full, dunque mi fa vedere una request, cioè un caricamento alla volta).
I DTP permettono invece di trasferire dati da un oggetto BW ad un altro internamente a BW, e per
questo differiscono dagli infopackage i quali invece si interfacciano coi sistemi esterni.
Gli Infoobject sono oggetti per dati non transazionali. Quando un Infoobject ha attributi diventa un
master data (se poi ha anche testi è semplicemente un master data coi testi), altrimenti l'infoobject
diventa una Caratteristica, ovvero un campo informativo.
Gli attributi di un Infoobject sono a loro volta degli Infoobject, e possono essere in Display o
Navigabili, cioè posso farci delle aggregazioni (somma record) o dei filtri. Su un ODS un infoobject
può essere un attributo (navigabile se è flaggato, in display se non è flaggato) o un data fields:
 Se sono Data Fields
il valore del campo è
fisso, se è
Navigation Attributes
nella reportistica il
valore varia in base
agli aggiornamenti
del master data.

Creazione oggetti:
 Info Area: su rsa1 tasto dx -> Create Info Area. Sotto un’IA posso nidificarne altre.
 Info Cubo: da IA tasto dx -> create Infocube

Per metterlo RealTime c’è il flag!!

Dimensions: quelle blu sono

standard e sono chiamate
col nome cubo + P,T,U. Al
time però devono essere
aggiunti gli infoobject del
time (es 0calyear, …).
Dimension 1 è la prima
dimensione customizzabile,
posso cambiarle descr e
aggiungerle gli IO. Sono
chiamate con nome cubo +
num progressivo.
Keyfigures: è la kf BW, a cui
aggiungo uno o più IO
keyfigure.
 Il cubo deve avere per forza le dimensioni con sotto degli IO e almeno una kf altrimenti non
me lo fa attivare:

Max 13 dimensioni, sotto le quali ci sono uno o più IO; i membri di un IO non devono avere
una cardinalità troppo elevata altrimenti il modello si complica in maniera esagerata.

 InfoObject: può essere di due tipi. E’ Characteristic se contiene dati qualitativi, è Keyfigure se
contiene il numero. Le icone sono colorate all’opposto per distinguerli.
Gli IO possono essere raggruppati nei Catalog (altrimenti andrebbero nei not assigned node).
Anche i catalog quando li creo vengono settati per contenere IO Characteristic o IO kf.
Quando su RSA1 vado sul menù InfoObj mi trovo le IA create prima e qui con tasto dx creo i
catalog:

Tasto dx sul catalog: create IO.

In base al tipo di catalog su cui mi metto mi crea un IO ch o kf:

Per gli IO ch devo per forza mettere un data type e una lunghezza:
 Per il time le caratteristiche fiscali standard sono in compound, cioè inscindibili, una si tira
dietro l’altra. Per il compounding c’è un Tab apposta alla fine, es lo 0fiscalyear è in compound
con 0fiscvar (Z1/2015: Z1 è la 0fiscvar, cioè un parametro std che indica che l’anno fiscale è da
sept a aug; 2015 è lo 0fiscyear. K4 è quello che va da gennaio a dicembre, k9 da ottobre a
settembre….. NON SONO MAI DA CAMBIARE. Da OB29 vedo le varianti fiscali che vengono
prese dai sistemi transazionali, cioè ECC).

Per gli IO kf definisco invece il tipo di kf, cioè cosa indica il numero. Un IO kf si porta dietro una
unit, es per gli amount la unit è Currency, per la Quantity la unit è Unit of Measure:

 Multiprovider: è un oggetto BW che contiene e lega in unione altri oggetti BW. Sempre sotto IA
tasto dx e create multiprovider. Mi chiede quali infoprovider contiene:
Dato il/gli infoprovider sotto il multiprovider, ne definisco le dimensioni e i loro IO ch e kf
(posso trascinare i singoli IO o le dimensioni stesse):

In alto poi ho de tastini che mi permettono di definire come legare le dimensioni dell MP con
quelle degli IO che lo compongono, sia per gli IO ch che per gli IO kf:
 Aggregation Level: sempre in una IA. Lo
costruisco su un MP:

Anche qui trascino le dimensioni (“Chars”) e le

keyfigures: