Externe opslag bijlagen aan te bevelen

Inleiding

In deze blog gaan we in op hoe het beheer van data wordt beïnvloed door de database keuze en met name welke consequenties dit heeft voor bijlagen in SAP. Een van de aandachtspunten die vaak onderbelicht blijft, betreft de manier van opslaan van bijlagen en gegenereerde documenten in SAP. Het is niet ongebruikelijk dat de opslag van bijlagen een significant deel van de database bestrijkt.

Veel SAP gebruikers koppelen lokale PC bestanden aan SAP documenten. Via de "Generic object services" knop, beschikbaar in vrijwel alle standaard SAP transacties, kunnen bijvoorbeeld PDF, Word of Excel bestanden toegankelijk gemaakt worden via het onderliggende SAP document. Zo worden in de praktijk bijvoorbeeld offerte bestanden gekoppeld aan bestellingen of binnenkomende bestellingen gekoppeld aan verkooporders. Daarnaast worden er veel documenten, met name PDF documenten, gegenereerd door SAP. Denk hierbij o.a. aan uitgaande bestellingen. Al deze documenten komen standaard terecht in de SAP database.

Middels deze blog willen we duidelijk maken dat het opslaan van deze bijlagen efficiënter en vele malen goedkoper kan door de opslag te verplaatsen van de database naar een externe contentserver. Zeker wanneer een HANA database zijn intrede maakt in het SAP landschap, is dit laatste vanuit een architectuur oogpunt meer een vereiste dan optioneel. We gaan daarnaast ook kort in op hoe deze verplaatsing van database naar contentserver technisch vorm gegeven kan worden. We gaan hierbij uit van een on-premise of private cloud scenario.

Onderzoek onder een aantal van onze klanten leert dat in enkele gevallen de tabel waarin bijlagen en gegenereerde documenten worden opgeslagen (tabel SOFFCONT1) tot wel 25% van de totale database kan beslaan. Wanneer men kijkt naar de kosten van opslag in een SAP HANA omgeving kan een reductie van de database significante kostenbesparingen realiseren. Maar ook wanneer traditionele databases gebruikt worden kunnen de voordelen aanzienlijk zijn. Denk hierbij aan backup procedures of systeem kopieën.

Data als nieuwe valuta

Door de continue ontwikkelingen die de ICT sector de afgelopen decennia heeft meegemaakt, zijn niet alleen de mogelijkheden qua IT applicaties maar tevens ook de mogelijkheden voor opslag van data exponentieel toegenomen. Hierdoor hebben bedrijven tegenwoordig grote hoeveelheden data tot hun beschikking en ook steeds meer mogelijkheden om deze data te analyseren en te verwerken. Een veel gebruikte term is “Data is the new currency” ofwel “Data is de nieuwe valuta”. Dat data waardevol is, lijkt voor iedereen een uitgemaakte zaak. Om bedrijfsprocessen te kunnen optimaliseren en versnellen, is niet alleen de data zelf maar ook een snelle toegang en verwerking van diezelfde data steeds meer een vereiste. Real-time data analyse staat daarom hoog op het lijstje van iedere manager, maar dit wordt vaak tegengehouden door de huidige hard- en software binnen bedrijven.

Traditionele database versus HANA database

De beperkende factor voor het snel en real-time verwerken van data zijn de zogenaamde traditionele databases. Een traditionele database kan maar één werkproces tegelijk behandelen voor een specifieke applicatie. Voor iedere applicatie die ontwikkeld wordt, wordt de data uit de database geconfigureerd en geoptimaliseerd voor de betreffende applicatie. Hiervoor wordt data continue verplaatst en gedupliceerd om aan de specifieke wensen per applicatie te voldoen. Hoe meer applicaties er binnen een bedrijf gebruikt worden, hoe lastiger het wordt om iedere applicatie snel toegang te geven tot data op de database. Een oplossing hiervoor is van oudsher een data warehouse. De data wordt op een dusdanige manier geaggregeerd en geconsolideerd, dat applicaties hier snel over kunnen rapporteren. Dit heeft echter weer tot gevolg data de data niet meer real-time te benaderen is en tevens dat er compromissen zijn gedaan ten opzichte van het detailniveau van de data.

Om de tekortkomingen van traditionele databases te ondervangen heeft SAP een zogenaamde in-memory database ontwikkeld waarin data direct toegankelijk is; de SAP HANA database. Naast snelle toegang tot de in-memory data is er ook een snellere verwerking van bijvoorbeeld queries op de data mogelijk. Data hoeft niet gedupliceerd te worden om vervolgens verwerkt te kunnen worden; dit kan direct op de database plaatsvinden. Onder andere de performance optimalisatie die behaald wordt met de introductie van een HANA database, haalt de noodzaak weg om data te consolideren en te aggregeren richting bijvoorbeeld data warehouses. Data is direct en snel toegankelijk zonder afbreuk te doen aan het detailniveau van de data.

De SAP HANA database is al enige tijd beschikbaar in het IT landschap (sinds 2010) en kan dus gebruikt worden met bijvoorbeeld een SAP ECC systeem. Echter, waar een SAP HANA database optioneel is voor een SAP ECC systeem is dit een vereiste voor een S/4HANA systeem. Steeds meer bedrijven maken daarom de overstap naar een SAP HANA database.

Kosten HANA database

Waar de introductie van een SAP HANA database mogelijkheden met zich meebrengt voor de verwerking van data, zijn er ook een aantal aandachtspunten te benoemen. Het opslaan van data in-memory levert namelijk significante voordelen op in de performance van applicaties, maar is daarentegen wel een duurdere vorm van data opslag ten opzichte van de traditionele databases. Hoge performance vanuit een traditionele database wordt bereikt via snelle opslag en processing (CPU) snelheid van servers. Echter, bij SAP HANA wordt de grootte van het geheugen zelf (in-memory) de belangrijkste resource.

Ondanks dat het opslaan van data continue goedkoper wordt, kan dit niet op tegen de continue groei van de data zelf. Daarnaast is het opslaan van alle data in-memory zeker niet noodzakelijk; waarom zou je data direct toegankelijk maken als deze nooit wordt opgevraagd? Schattingen zijn dat gemiddeld genomen 85% van de data in een database zogenaamde “cold data” is en weinig tot nooit “aangeraakt” wordt. Er blijft dus maar 15% “hot data” over, welke naar schattingen goed is voor 90% van de interacties met de database.

Om goed om te gaan met warme en koude data, kan ervoor gekozen worden om slechts een gedeelte van de data (warm) op te slaan als in-memory en de overige data (koud) op te slaan op andere databases. Deze koude data is nog steeds bereikbaar, maar wordt pas in-memory geplaatst wanneer hierom gevraagd wordt door een specifieke applicatie.

Een van de type data welke als “koud” kan worden aangemerkt zijn bijlagen binnen een systeem. Denk hierbij onder andere aan uitgaande bestellingen, uitgaande facturen, binnenkomende facturen, e-mails, notities, etc. Als voorbeeld nemen we de gegenereerde PDF van een inkooporder die naar een leverancier verstuurd wordt. Deze PDF bijlage wordt éénmaal gecreëerd, vervolgens uitgeprint of gemaild naar de leverancier en gekoppeld aan de inkooporder in SAP. Wordt alles geleverd door de leverancier en betaald, dan is het inkoopproces in principe afgehandeld. Veel van deze gecreëerde PDF documenten zullen nooit of nauwelijks meer geopend worden. Waarom deze documenten dan ten alle tijden in-memory laden? Dat lijkt compleet onzinnig en dat is het in feite ook!

Opslag van bijlagen

Van oudsher worden bijlagen en gegenereerde documenten in SAP opgeslagen in de onderliggende database; dit is soort van de default instelling in SAP. Maar zelfs een traditionele database is in principe niet bedoeld voor de opslag van zogenaamde binaire documenten. Wat we vaak zien bij onze klanten is dat dit ooit een eerste opzet is geweest van het systeem en onbedoeld jarenlang in stand blijft. De systeem opstelling die hiervoor wordt aanbevolen is dat zogenaamde “platte” data op de database wordt opgeslagen en documenten of “binaire” data op een contentserver (bijvoorbeeld de SAP Content Server). Een contentserver heeft namelijk ook als specifiek doel om documenten in op te slaan en vervolgens snel op te halen wanneer daarom gevraagd wordt. Het is daarnaast ook efficiënter en goedkoper om dit soort documenten in een contentserver op te slaan dan in een database; denk hier bijvoorbeeld aan back-up procedures of systeemkopieën.

De ingebruikname van een contentserver kan middels een SAP Content Server. Deze valt binnen de reguliere SAP licentie en is kosteloos te gebruiken. Er kan daarnaast ook gekozen worden voor externe contentservers, zoals bijvoorbeeld OpenText Archive. Wanneer bijvoorbeeld een externe contentserver reeds in gebruik is voor andere processen, dan kan hier op worden aangesloten.

Migreren naar HANA

Waarbij het in een SAP landschap met een traditionele database nog een aanbevolen optie was om documenten op te slaan op een contentserver, heeft de introductie van S/4HANA en de daarmee gekoppelde SAP HANA database de noodzaak hoger gemaakt voor het switchen van een SAP database naar een (SAP) Content Server. Wanneer men naar een SAP HANA database migreert al dan niet met of zonder een S/4HANA systeem, is ons advies om hierbij zeker de contentserver goed op te zetten voor de documentenstroom in SAP. Zonder een juiste installatie van een contentserver, worden alle documenten en bijlagen per default op de onderliggende HANA database opgeslagen; dit is onnodig. Indien er gemigreerd wordt naar een S/4HANA systeem, dan is ons advies om preventief al documenten te migreren naar een contentserver. Op deze manier hoeft er geen database migratie plaats te vinden inclusief alle reeds bestaande bijlagen; deze staan immers dan al op de contentserver.

Voorbeeld scenario

In transactie ME21N of ME22N (bestelling creëren of wijzigen) kan men bijlagen koppelen via de knop "Services voor objecten".

Bij het koppelen van de bijlage aan de bestelling zal dit document in de SAP database worden opgeslagen. De wens is om PC documenten zoals Excel, PDF, et cetera aan een bestelling te koppelen zonder deze bijlagen op de SAP-server te bewaren. Deze documenten moeten opgeslagen worden op een extern opslagmedium.

Om te analyseren of het zinvol is om bijlagen op een alternatieve wijze op te slaan gaan we eerst bekijken wat de database grootte is van de tabel SOFFCONT1. In onderstaande voorbeeld zien we dat deze tabel ongeveer 1.074.542 MB groot is. Ten opzichte van een totale database van 5.661 GB is dit ongeveer 20%! In dit voorbeeld zijn dus significante besparingen mogelijk.

We zien dat er hier significante besparingen mogelijk zijn. In de volgende paragraaf leggen we uit hoe.

Opslaan van bijlagen op extern opslagmedium

Het is via configuratie mogelijk om bijlagen standaard op te slaan op een externe gegevensbron, bijvoorbeeld een SAP Content Server. De SAP Content Server is een stand-alone SAP component waarop externe documenten kunnen worden opgeslagen. Uiteraard zijn de bestanden direct via SAP opvraagbaar.

Documenten worden opgeslagen in een MaxDB database (onderdeel van de installatie). SAP applicaties kunnen toegang krijgen tot Content Server voor het uploaden, downloaden of weergeven van documenten via het Archivelink protocol.

Zoals in onderstaande figuur zichtbaar is, zullen bijlagen via KPro in the content repository SOFFDB (onderhouden via transactie OAC0). Deze refereert naar database tabel SOFFCONT1.

Om documenten op te slaan in een externe content repository dient men de volgende procedure te volgen: 

1. Creëer een content repository gekoppeld met een SAP Content Server

In de Implementation Guide (IMG) (transactie SPRO) kies SAP NetWeaver → Application Server → Basis Services → ArchiveLink → Basic Customizing → Define Content Repositories.

2. Creëer vervolgens een content repository voor de storage category HTTP content server. Deze content repository bevat de details rondom de connectie naar de SAP Content Server. 

Er zijn nu dus 2 categorieën beschikbaar: SOFFDB die gekoppeld is met de SAP Database, en SOFFHTTP die gekoppeld is met een SAP Content Server.

 
 

3. Toewijzing SOFFPHIO class aan content category SOFFHTTP

  • Kies transactie SKPR08.

  • In het veld previous category SOFFDB staat class SOFFPHIO. Voer hier het veld New Category de waarde SOFFHTTP in.

  • Kies "Save".

Indien waarde SOFFPHIO niet beschikbaar is dient deze beschikbaar gemaakt te worden via transactie SE16N. Wijzig hiervoor de veldwaarde CAT MAINT naar X in tabel SDOKPHCL, regel SOFFPHIO.

Vanaf nu worden alle bijlagen opgeslagen in de SAP Content Server. Men kan dit controleren door de grootte van tabel SOFFCONT1 te bekijken voor en na het koppelen van een bijlage aan bijvoorbeeld een inkooporder.

Migratie

Nadat het standaard gedrag bij het opslaan van documenten gewijzigd is, is het zaak om ook de reeds in de SAP database aanwezige documenten te migreren naar de externe gegevensdrager. SAP heeft hier een aantal hulpmiddelen voor beschikbaar gesteld. Hierdoor kunnen de reeds gekoppelde bijlagen eenvoudig verplaatst worden. 

SAP rapporten RSIRPIRL of RSGOS_RELOCATE_ATTA kunnen gebruikt worden om de bestaande documenten fysiek van SOFFCONT1 naar een externe content server te verplaatsen.

Deze SAP programma’s voor de migratie van bijlagen zijn beschreven in SAP Note 1634908 en Note 2459712. 

 
 

In de schermafdruk hierboven worden alle bijlagen opgeslagen in de SAP Database uit een bepaalde periode gemigreerd naar een SAP Content server. In dit geval in test modus. Eindgebruikers merken geen verschil na de daadwerkelijke migratie, voor hen verandert er niets. De SAP database zal echter significant in omvang afnemen. Zoals eerder gemeld in sommige gevallen met meer dan 20%!

Houd er rekening mee dat deze reductie in de tabel grootte niet automatisch zal resulteren in een kleiner database grootte. Uw databasebeheerder kan u eenvoudig helpen met de reorganisatie van de database.

Voor vragen of extra informatie over dit onderwerp kunt u contact opnemen met Sander van der Wijngaart.