OutBoarding is a process of archiving data via 'OutBoard for Analytics'.
Every process has three phases:

Data copying – Data is selected from an InfoProvider and written into OutBoard
Data verification – Data is read from OutBoard and compared against the data in the InfoProvider
Data deletion – Data is deleted from the InfoProvider

Phases are completed in sequence; only after the previous phase finished successfully then another phase can be started manually or automatically.

OutBoarding can be done either manually via transaction RSA1, automatically via a process chain and by using an advanced feature.

Manual archiving will be shown:

Manual OutBoarding

1. In RSA1:

a/ Choose an InfoProvider from the context menu
b/ Go to "Manage" and "Archiving" tab (commonly last)

_{OutBoarding tab in InfoProvider Administration RSA1}

c/ Archiving tab – Here the archiving process can be started
d/ Check that connection to OutBoard exists in RSA1

_{Archiving request tab view}

e/ Click on "Near-line Connection…" at the bottom of the "Archiving" tab
f/ Create an Archiving Request by clicking on "Archiving Request…" button near the bottom of the tab view.

ΤA: RSA1

2. It is possible to:

Specify which data should be archived based on Restrictions at the top of the screen
Define the Process Flow Control at the bottom of the screen (e.g. when archiving request will be invalidated or if the BWA index should be rebuild after archiving or not).

_{Archiving request creation}

Restriction for archiving the data:

When specifying the data that should be archived, it is possible to set:

Primary time restrictions - Selection based on the time characteristic which was chosen in DAP creation
Further restrictions – Selection based on additional characteristics chosen in DAP creation

In the case where Primary and Further Restrictions are used, data that satisfies both conditions will be archived (i.e. an intersection of conditions will be made).

1. Relative conditions:

Based on the input 'Only Data Records Older than' and 'Only complete' the relative condition will automatically be filled. Any record that falls within these relative conditions will be archived.

_{Relative conditions}

2. Absolute conditions:

Using these select conditions to state a specific time frame, records that match these absolute conditions will be archived.

_{Absolute conditions}

3. Further Restrictions Tab

The further restriction tab, allows extra flexibility to incorporate further restrictions. The further restrictions are linked with the Selection Profile in the DAP.

_{Further Restrictions Tab}

The selection criteria should be chosen in a way so that the average archiving request will be between 500 000 and 20 000 000 entries.

Process Flow Control

Here the Flow of the archiving can be controlled. In the "Process Flow Control", you can set until which phase the archiving should proceed. Archiving by default includes 3 phases:

Copying
Verification
Deletion

_{Continue processing until Target Status}

→ leave the option unchanged, if the entire archiving should be completed in one go.
→ to invalidate archiving after an error occurs, set "Autom. Request Invalidation After Error" (after request invalidation the same archiving process can be started later again)
As of SAP BW 7.30, the BWA index can be rebuild after archiving → this can be simply started at the end of the archiving by checking the "Rebuild BWA Index" field.

_{Request invalidation after error}

Job Name will be automatically assigned if the field is left empty. Alternatively, you can assign the process to an existing Job Name.

_{Job name}

Finally, you can launch the Archiving in:

Dialogue Process (F8)
Background (F9)

Since archiving can take a really long time, it is recommended to execute it only in Background.
After launching Archiving in a Dialogue Process (F8) or in Background (F9), a request will appear with individual phases of the archiving process:

• Copying
• Verification
• Deletion

⇒ after each phase is completed, a green light will appear in the respective window, and archiving will enter the next phase until it is completed. Keep pressing, "Refresh" to see the current status.

_{Archiving in the copy phase}

_{Archiving in the verification phase}

_{Archiving completed (delete phase and subsequent status mark)}

In the case of error / warning → click on the warning/error icon or display the archiving log, to see the reason

_{Displaying Job Overview}

_{Displaying Archive Log}

Archiving of SPOs in OutBoard for Analytics with Storage Management

As of OutBoard SP18, archiving and working with SPOs based on DSO and InfoCube is now possible in all OutBoard processes. As of OutBoard SP22, support for SPO based on WODS is also available.

Data from the Semantic Partitions of an SPO can be archived using the BW archiving process. The archiving object can be created via the context menu of the SPO in TA RSA1. Once activated, archiving can be performed by clicking on the archiving button in the SPO maintenance, which leads to the standard archiving request screen:

ΤA: RSA1

_{Edit semantically Partitioned InfoCube}

The create archiving request screen has additional options referring to SPO, where the administrator can choose to archive data from all partitions or from single partitions:

_{Archive data from all or single partitions}

In OutBoard Storage management you canwork with SPOs intuitively using the following OutBoard functionalities however with some restrictions:

OutBoard Analyzer: The data distribution is calculated for the SPO Object (not separately for each semantic partition). The information is then summed between partitions to get the final result.
OutBoard Massarchiving: The data of an SPO can be archived here only at the Cross-Partition level (functionality to archive data for a specific partition is not available in mass archiving).

Also, other OutBoard features such as usage of NLS Writer, changing the structure of SPOs, OutBoard Aggregates, and OutBoard Indexes are supported with no noticeable differences for the user (all on the SPO level).

Outboarding via Process Chains

For automatic OutBoarding via process chain, use the process chain "Archive Data from an InfoProvider".

This can be found in the "Data Target Administration" of the process chain tree → the actual setup and OutBoarding work the same way as manual OutBoarding.

_{Example of a process chain}

Reloading data

Data from an InfoCube or a DataStore Object archived by OutBoard can be reloaded back to the online database. Reloading is the opposite process to archiving – taking the archived data from the OutBoard archive and inserting it back into the corresponding tables of the InfoProvider.

When reloading data for an InfoCube, this data will be inserted into the F-table of the InfoCube and loading request will be created in the Request Tab.
If reloading data for an DSO or WODS, this data will be inserted directly into the active table of a DSO and no loading request will be created.

_{Process Request for reloading data from NLS}

To reload data from OutBoard into an online database, call transaction RSA1.

ΤA: RSA1

Choose an InfoProvider from the context menu, go to "Manage" and then proceed to the "Archiving" tab.
Check whether the last archiving was successful.
Double-click on the Archiving Request

To reload OutBoarded data → check the reload radio button and run in the background or dialog.
There is also the option to 'Reload Subsequent Requests' ⇒ all archiving requests with higher Request SID will also be reloaded.
As with archiving, the reloading will go through 3 steps:

a/ Copying
b/ Verification
c/ Deletion

Upon successful reload, all lights will be green. After reloading is finished, the request in OutBoard is invalidated and the data is automatically deleted from the storage area.

_{Data reload from NLS successfully completed. Archiving request below}

Reload Empty NLS requests

Report /DVD/NLS_RELOAD_0_REQUEST reloads Archive requests, which contain no data, which means their NL Request is 0.
Select the DAP name (InfoProvider), which you want to reload, and select an Object type. If you click on a black expander, you can choose a specific object type, like InfoCube, DSO, or Write-optimized DSO.

_{Reload empty NLS requests}

After the report execution, the job will be running in the background. Report deletes only requests that are in phase 70 or more. If archiving is not finished, data reload is not possible. In case, that InfoProvider or DAP has an archiving request with a status less than 70, the archiving request will be skipped and this information will be available in logs.

Reporting on archived data

One of the NLS key features is that the archived data can be accessed for reporting and loading processes without the need to reload the data back from the archive. To include the NLS data, the queries need to be adjusted → normally the access to NLS data is switched off by Default.
How NLS data is included in reporting is dependent on the SAP BW Release. In the following tables the differences are summarized in a short form (for more detail read the whole chapter):

SAP BW Release	Up to 7.02	As of 7.30
Read NLS data for a Query	Set in TA RSRT in Properties of Query	Set in Query Designer and/or InfoProvider Level
Adjust Queries automatically using the report:	/DVD/NLS_INC_NLS_CHCK_TO_QUERY
Supported reporting on MultiProvider	A VirtualProvider has to be built	Supported automatically the same way as for basic InfoProviders
Build VirtualProvider automatically using the report	/DVD/NLS_VP_GUI

Improve performance on reporting

To improve the performance of reading OutBoard data in reporting this can be run in parallel. To do this, change the OutBoard configuration parameter REP_PAR_WP in OutBoard Settings.
Contact your consultant for further support in parallelization for better reporting performance.

When setting parameter REP_PAR_WP, make sure to have enough dialog work processes available i.e. Total number of dialog WP must be more than REP_PAR_WP + 3.

For an IQ transparent storage, the parameter for REP_PAR_WP cannot be set to higher than 1.

For binary storage, REP_PAR_WP makes reading from an archive parallel.

Needed adjustments for reading NLS data in detail

ΤA: RSRT

For SAB BW up to 7.02 reporting on NLS data is determined only on query level. To include archived data in your reporting, the reporting query must be adjusted.

To do this, call the Query Monitor - RSRT.

_{Query Monitor - transaction RSRT}

In the field "Query" write the query name and click the Properties.

_{Selecting/deselecting NLS for Reporting}

Click on the check box "Read Near-Line Storage As Well" if you wish to include data from NLS in Reporting (the check box will be absent if no Data). As it would be too much effort to adjust all queries manually, Report /DVD/NLS_INC_NLS_CHCK_TO_QUERY is created to adjust the queries automatically. In the selection screen of the report the user can specify:

TA: SE38

Add NLS: specify if the NLS data should be read or not
InfoCube: Define InfoCube for which all queries should be adjusted
Name (ID) of a reporting comp.: Define Queries that should be adjusted

_{Report /DVD/NLS_INC_NLS_CHCK_TO_QUERY}

After this report is executed in TA SE38, all specified Queries will be adjusted.
In SAP BW up to version 7.02, the data of MultiProviders can be included in reporting only via created VirtualProviders. In the OutBoard solution, there is a report to do this automatically for InfoCubes – how the report can be used can be found at the end of this chapter.
As of SAP BW 7.30 the logic changed, so NLS data can now be included in reporting on three multiple levels:
1. Query level - In Query Designer 7.30 and higher the NLS Usage can be defined in the Extended Tab of a Query. The user has three possibilities:

Include NLS data – Read Near-Line Storage
Not include NLS data – Do Not Read Near-Line Storage
Use Near-Line Storage According to Provider Settings

If the flag „Use InfoProvider default" is chosen, the Query Setting will be always taken from the InfoProvider Settings. To make this property changeable in the Query Designer, the InfoObject 0NEARLINE has to be active in the BW system.

_{NLS Usage in Query Designer}

Using the checkbox "Use InfoProvider default" - the InfoProvider Settings will be taken each time.

It is recommended to set the flag "Use InfoProvider default" and then determine the NLS Usage always on the Provider level

2. MultiProvider level – here the NLS usage can be set to read / not to read NLS data automatically and read NLS data based on PartProvider Settings.
This option can be set:

a/ Go to RSA1
b/ Double-click on InfoProvider and go to Extras
c/ Go to InfoProvider Properties and select 'change'
If the option "Near-Line Access Set the Same as for PartProvider can be selected, the archived data will be read from the underlying PartProvider based on their NLS Usage Settings.

_{Read NLS in queries for MultiProvider}

3. InfoProvider level – can be set the same way as on the MultiProvider level.

_{Read NLS in queries for InfoProvider}

It is important to note, that when defining NLS usage on query level, i.e. whether NLS Usage is allowed or forbidden on Query Level, the Provider options are not taken into account. But, if the Query Setting is set to default, the Provider Setting will be taken.
We recommend using the setting: "Use InfoProvider Default" every time it is possible. To set the NLS usage automatically for multiple queries, the report /DVD/NLS_73X_INC_NLS_QUERY can be used:

TA: SE38

_{Adjustment of NLS Query Settings}

When the queries are adjusted using:

/DVD/NLS_73X_INC_NLS_QUERY

The query report will need to be regenerated, before being executed in TA: RSRT. The regeneration is required in order to make the system aware of the new adjustments to the queries.
To set the NLS usage automatically for multiple MultiProviders as well as InfoProviders, the report /DVD/NLS_USAGE_MASS_EDIT can be used (this is relevant for SAP BW release 7.30 and higher).

_{Set NLS usage for InfoProviders}

Browser not supported