The OutBoard Browser offers an overview of data from InfoProviders in relation to their data archiving.

The Object Browser can be seen below:

_{OutBoard Object Browser}

By expanding the Object Name node, individual requests can be seen:

_{Expanded Objects in OutBoard Browser}

_{Column Headings in OutBoard Object Browser}

InfoCube
DSO/ADSO
Change Log/ PSA

Please note that for ADSO there are only display functionalities available in the OutBoard Browser.

Information about individual fields:

Object Name	description and technical name of the InfoProvider, PSA or Change Log
Technical name	system name of the Object
Created	date of the archiving request creation
Time	time of the archiving request creation
Status	status of the archiving request can be: INACTIVE Inactive/ Released into verification phase ACTIVE data is available INVALID request deleted - these requests are not visible in the Browser anymore CREATED request is created data is being copied CANCELED copying was cancelled CLOSED copying is finished
Selection	selection that was used for the request in archiving
Data	OutBoarded data can be shown as a table in Archive viewer when clicking on icon in this column
Count of rows	the number of rows contained in a request
Archived size	size of the table in external database when the NLS data are on external storage.
Unpacked size	displays the original size of the request. If the information is not available try recalculation compression ratio by selecting “Calculate compression ratio” when right-clicking on object.
Space saved (KB)	the difference between archived size and unpacked size, which can then be allocated to where it is needed.
Space saved (%)	how compressed the data really is. Higher compression ration typically means more money saved; however, higher compression ration can also mean longer data processing as the data needs to be uncompressed. When the data is archived into external storage, there should be value: 100%.
Storage Cost Saving (EUR/Month)	the amount of money saved based on the money coefficient provided earlier. The unit of measurement is determined by parameter CURRENCY.

The OutBoard Object Browser allows the user to access RSA1 - (F6 - below) and RSDAP - (F7).

_{Viewing number of entries}

The toolbar in the OutBoard Object Browser provides several functionalities for working with the data displayed. The fields, from left to right, stand for:

(F2) Refresh

(F5) Filter

(F6) Data Warehousing Workbench – RSA1

(F7) Edit Data Archiving Process – RSDAP

(Shift + F2) Edit InfoCube – RSDCUBE

(Shift + F6) Display Archived and Unpacked Size

(F9) Export data to Microsoft Excel

(Shift + F7) Create DAP for PSA or Change Log

(Shift + F1) Documentation

(Shift + F4) Display statistics

(Shift + F5) Change display of requests – only request with selected type will be visible

(Ctrl + F11) Switch to storage view - It is possible to see icon Storage update. Column headings are different, now you can see Storage ID, it´s status, Logs and Storage update messages.

(Crtls + F9) It is possible to change the storage you have chosen during Data Archiving Process creation

_{Column Headings in OutBoard Object Browser - Storage view}

If the user attempts to update the storage of requests that are already under storage update, warning about possible data lost in case of pop-up confirmation are displayed.

Similar to standard SAP functionality, with in the OutBoard browser, it is now possible to view the number of entries.

Filter (F5)

OutBoard Browser Filter

Filter allows you to select objects according to the criteria listed. Simply type in the criteria and click “Execute” (F8). Multiple selections are also supported. When starting the OutBoard Browser and more that 50 archiving objects are to be show you will be asked by default if a filter is wanted.

Object Type – which type of object is to be used. Possible values: CUBE, PSA, ODSO, and CHLG.

_{OutBoard Browser Filter}

Object types in OutBoard Browser Filter

Export Data to Microsoft Excel (F9)

Export Data to Microsoft Excel

In OutBoard Browser it is possible to Export data to Microsoft Excel. Filter(F5) the Objects, the ones with Data you want to export and click on icon and save it into your Computer. It is possible to choose as many as you want. Data will be saved in XML format.

_{Export data}

To view the data, just open the .XML document in chosen destination folder.

PSAs and Change Logs

For proper management of temporary data (such as PSAs and ChangeLogs), Datavard developed housekeeping solution: ERNA.

DAP button

Press DAP button, PSAs and Change Logs can be archived from inside the OutBoard Browser.

Selecting the PSA or Change LogTo create a Data Archiving Process for PSA, select “PSA DAP” and complete the DataSource. The DataSource can be selected from the list of DataSources in the system (F4) and the Source System is filled automatically.

After creating the Data Archiving process either for PSA or Change Log the object is added to the OutBoard Browser. It can be archived by right-clicking on the Object, selecting "Archive Table"

_{Archiving the PSA or Change Log}

Archiving can be done by Date (absolute or relative) or by Request. When "Archive by Request" is selected, a request from the system has to be chosen (F4).

_{Reload Request}

When Right-clicking on the object by selecting "Reload all Requests", all data is reloaded from an object to the system.

_{Reload all Requests}

The PSA DAP is kept. By selecting "Delete DAP" the DAP can be deleted. By selecting "Display Details", the details of the selected object can be seen. For viewing the Logs for the selected object the "Display Logs" must be selected. The compression ratio can be recalculated by selecting "Calculate compression ratio" or calling report /DVD/NLS_CALC_CONV_RATIO.

Field selection for Index

Field selection

The field selection functionality allows you to select fields according to which the indexes in the storage table will be created. Searching on selected fields will be faster however archiving will be slower.

For InfoCubes the time characteristics are selected by default. For DSO Objects the time characteristics and key fields are selected by default. It is recommended to have maximum 20 fields selected. Indexes can be rebuilt (deleted and recreated) by calling running "Rebuild selected indexes" (Shift + F6) or running the report /DVD/NLS_REBUILD_CONT in TA Se38. The OutBoard index can be rebuilt based on InfoProvider name or for a concrete archiving request.

_{Field selection for Index}

_{Field selection for InfoProviders}

The Field selection can be easily edited by selecting particular fields and saved by using the Save button.

Select all “Selection Fields“	Transport indexes Definition
Deselect all “Selection Fields“	Rebuild Indexes

When new data is added to NLS archive of an InfoProvider, the Indexes will be updated and used.

Parallel rebuild of Outboard for Analytics indexes

Parallel rebuild of indexes

Parallel rebuild of indexes is available. Now the user may define number of parallel tasks that will be running for Index rebuild, as well as time restrictions.

TA: SE38

The user can also define what should happen with OutBoard indexes that are already built on an InfoProvider. By running report /DVD/NLS_REBUILD_CONT – Select Request for rebuilding indexes the user may choose between Refresh or Rebuild.

Refresh option mean that new and old indexes will be created from scratch – (older indexes are deleted first).
Rebuild option means that before running the rebuild functionality, a check for all changes in "Field selection" is executed and only fields that were changed will be rebuilt.

_{Select Request for rebuilding indexes}

Relevant settings for OutBoard Indexes rebuild:
INDEX_PAR_BUILD – number of parallel tasks that can be running at the same time

Secondary indexes

Before speaking about Secondary indexes it is important to remind the logic for reading NLS data. Upon archiving, the SELECTs on archived DSOs need to be adjusted in order to read the archived data. In this case the SELECT formula reading archived DSO needs to be rewritten using NLS lookup API method (refer to the documentation part for NLS lookup).

The archived data is stored in NLS archive, in NLS packages. For these packages usually there are defined standard OutBoard indexes (/dv1/in* or /bic/in* OutBoard tables), for most cases this is sufficient to reduce the amount of NLS packages that need to be uncompressed when accessing the NLS data. However, in some cases these indexes are not enough, e.g. when using an object in filters with really high cardinality (such as 0material or 0doc_number).

Secondary Indexes

OutBoard secondary indexes may improve performance significantly, especially in cases where the archived data are accessed and filtered on such objects.The OutBoard Secondary indexes are rebuilt during all data operations that change archived data, such as: archiving of new data, partial and full data reload, drop of archived data, deletion of DAP, adjusting data in archive when using NLS Writer etc…

After the Secondary index is defined; you can check the performance improvement during the access to NLS data. NLS Secondary indexes usage needs to be allowed beforehand via the OutBoard Settings and the needed Secondary indexes have to be built.
As of OutBoard for Analytics SP21 release, Secondary indexes are available for OutBoard without Storage Management, too.

Storage for Secondary indexes

Standard OutBoard index can be stored only in primary database. In comparison to the OutBoard Secondary index, which can also be stored in external (transparent) database as a transparent table. In the OutBoard settings, the first step is to define the storage that is going to be used for storing the secondary index tables:

_{Defining the storage for Secondary Indexes}

When the storage is defined, it can be used when the Secondary index is created. In current release only external databases of type DB2 and ORACLE are supported. For an Oracle database the most suitable transparent storage should have the connection mode M (massive insert into external Oracle database):

Secondary indexes

The secondary indexes can be created from OutBoard Browser -> right click on archived InfoProvider. If not available, contact Datavard consultancy to allow this functionality in your environment (parameter INDEX_SEC_ALLOWED):

_{Secondary Indexes via Outboard Browser}

Secondary index can be created in a Cluster or in any other connected transparent storage: Oracle, DB2 and consists of two tables - /DV1/SEC* and /DV1/REC*. The "SEC" table is the header table and its number of rows is equal to the number of combinations of the selected fields for secondary index. The "REC" table number of rows is equal to number of rows in archive.

To view secondary index (SEC and REC tables) created in other than primary database use report /DVD/SM_DATA_BROWSER via transaction SE38. This report allows you to check number of rows in a specific table and its data based on selection. Secondary index tables for the index created in the primary database the content can be viewed in SE16.

Please note that deleting a SEC* table after archive reload only works if secondary indexes are build on a primary storage.

Otherwise SEC* table remains filled with data, even after a complete archive reload. In order to clear the SEC* table, you need to delete the corresponding secondary index.

In the next screen you can see the already created secondary Indexes and can also maintain new indexes:

_{Creating new and maintaining indexes}

To create a new index or delete already created one, use the buttons in the top of the screen (as above). After the user chooses to create new secondary index, following screen will appear:

_{Creating new Secondary index}

Here the user can choose the objects to be used for Secondary Index and confirm (in the bottom of the screen). Afterwards the order of objects for Secondary Index can be changed, in order to have Secondary index created in the same order as the objects are used in the lookup:

_{Change order of indexes}

In the next screen the storage for the SI can be chosen:

_{Selecting storage for secondary indexes}

Upon confirmation, the creation of secondary index can be started -> the tables /dv1/sec* and /dv1/rec* are created(notice also index ID in first column).

_{Index ID list}

When you double-click on the row with index ID, you are able to review the definition of the specific index:

_{Index detail}

When creating the Secondary index directly in primary database, the Secondary Index tables can be viewed in TA SE16. In other cases use the report /dvd/sm_data_bowser to check the Secondary Index tables.
If the Secondary index is build correctly, the status is set to "Active". However, there are multiple Secondary Index statuses, which can require different handle scenarios:

_{Secondary index - statuses}

Inactive: The SI will not be used in NLS readings(also even if allowed), in order to be activated again, the report /DVD/NLS_INDEX_SEC_REFRESH has to be run for DSO/index

Active: The SI will be used in NLS readings(if allowed)

Running: The rebuild of SI is running at the moment (SI will not be used in NLS readings, even if allowed)

Disabled: The rebuild of SI was not successful, there isn’t any other way to active the SI as rebuild it completely (in OTB Browser or via report: /DVD/NLS_INDEX_SEC_REBUILD)

Usage of secondary index

It is recommended to define OutBoard secondary index on objects that restrict the data the most during the access. Usually indexes defined on objects such as doc_number or deliv_number or on fields in filters with fixed values (e.g. comp_code = '0012') are the most suitable.

The usage of secondary indexes can also slow down the performance in cases where the NLS data is read heavily and not filtered at all. For this scenario, the usage of SI can be turned off on different levels (read below).

OutBoard Settings for Secondary Index

INDEX_SEC_ALLOWED

enables SI functionality in OTB browser, and is not editable via OTB settings (this parameter will be probably removed in next OutBoard SP)

INDEX_SEC_BUILD

when switched on (value "X"), Outboard's secondary index will be rebuilt during the NLS processes, such as archiving data and data reloading. The rebuild is done during the archiving/reload process, which can prolong the archiving/reload runtime. If some solvable issues occur during rebuild of Secondary index, the logic will switch automatically to a "P" mode of secondary index rebuild (see below).
When set to "P", the OutBoard secondary index will not be updated during the archiving/reloading of the archived data. However any affected requests during the archive operations are noted into table /DVD/NLS_SEC_REQ, then secondary indexes can be rebuilt by using report /DVD/NLS_INDEX_SEC_REFRESH (can be built into process chain)
when set to "" (left blank), the OutBoard secondary index will not be rebuilt during next archiving/reload of data and will be set to disabled (not usable). In cases where the Secondary Index should be used, there is the need to be rebuilt it in the /dvd/outboard -> Browser.

Recommended: Turned on (Value 'X') on DEFAULT level

Reload of whole archive

In case of all data from archive was reloaded and secondary index is in state ACTIVE, table /DV1/SEC* containing index SIDs is preserved and table /DV1/REC* is empty.

WRITER_INDEX_SEC_BUILD

when switched on (value "X"), Outboard's secondary index will be rebuilt during the NLS Writer adjustments in the archived area. The rebuild is done during the activation of data (for DSOs) or (for InfoCubes) during the load of data, which can prolong the activation/loading runtime.
when set to "P", the OutBoard secondary index will not be updated during the NLS Writer adjustments in the archived area, but can be updated to an active(usable) version using the report /DVD/NLS_INDEX_SEC_REFRESH (can be built into process chain) - when set to "", the OutBoard secondary index will not rebuild during NLS Writer adjustments in archive In this case the Secondary Index should be used, and will need to be rebuilt in the /dvd/outboard -> Browser. Recommended: Turned on (Value 'X') on DEFAULT level

INDEX_SEC_DEFAULT_STORAGE

the storage defined here will be used as default for the creation of secondary indexes

Default value: Empty, primary database. The ID of storage defined in OTB Settings should be inserted here.

INDEX_SEC_FILTERING_ON_POS

when switched on (value "X"), reading of NLS data is performed on enhanced position/row level – if the data is in a NLS package, the exact position is known and only relevant rows in NLS package are accessed.

Recommended: Turned off (Value ' ') on DEFAULT level. Turn on only for InfoProvider with SI to be used.

INDEX_SEC_USE_FOR_FILTERING

if switched on (value "X"), reading NLS data is performed using secondary indexes logic.

Recommended: Turned off (Value ' ') on DEFAULT level. Turn on only for InfoProvider with SI to be used.

INDEX_SEC_READ_PACKAGE_SIZE

in order to create the Secondary Index, the /dv1/sec* table will be accessed multiple times. The parameter determines the package for reading the /dv1/sec* table. If a higher number is chosen, it can increase performance but also memory usage.

Default value: 500.000

INDEX_SEC_SEARCH_MAPPING_TAB

enables or disables the pattern / hash ID search logic. This setting is turned off by default. Refer to chapter optional usage of SI (Secondary Index).

INDEX_SEC_SEARCH_REGEX

parameter for creating a custom string. Refer to chapter optional usage of SI (Secondary Index).

INDEX_SEC_HINT_BLOCK_FACTOR

used to define block factor parameter for ORACLE hints for SELECTs used in logic for secondary index rebuild – the higher the number, the better performance. However, if set to a very high number, the FAE condition will be rewritten to a range condition, which can slow down the performance (to be checked with person responsible for maintaining parameters in TA RZ11, which values is the most suitable).

Optional usage of Secondary index

Let us discuss this topic on one example scenario. Having an end-routine of transformation it may happen, that there are multiple lookups on same DSO with very small differences. The same lookup on archived data using different filtering (e.g. EQ conditions vs. NE conditions in filter) may result in different performance impact. Secondary Index logic could improve the performance for some of the lookups, but for others the usage of this logic can have a negative impact on the lookup performance.
In this case the enhanced logic for choosing the Secondary Index can be used. The lookup is then identified:

→ based on HASH ID of the second include generated during the lookup translation (in case NLS Lookup translator was used to adjust the SELECT to NLS Lookup API)

_{SELECT translated with OutBoard´s lookup translator}

→ or based on the HASH ID defined in a custom way (e.g. as an exporting parameter of a custom method developed only for this specific scenario). The HASH ID should be an unique 25 character string.

Having the HASH ID, the behavior is then determined based on the settings in table /dvd/nls_sec_map:
Turn off the SI functionality for specific lookup:

Table adjustment (1)
→The value of Index_ID should be '0'.

Use a specific SI for the lookup:

Table adjustment (2)
→The value of Index_ID should be the SI index ID to be used

Table adjustment (3)

→The value of Index_ID should be '-1' in case Datavard default algorithm should be used to determine SI (Seconday Index) to be used.

In case the /dvd/nls_sec_map is not maintained for a specific lookup and Secondary Index usage is switched on, one/multiple secondary indexes will be determined for usage by a default algorithm.

To allow this functionality, the following parameters have to be adjusted in OutBoard settings:

INDEX_SEC_SEARCH_MAPPING_TAB

when set to "X" the code of the e.g. transformation will be searched for the string "INCLUDE" and/or "CUSTOM STRING" (between two lookup API calls) and then for the HASH ID. This HASH ID has to be in the same row as the "INCLUDE" or "CUSTOM STRING".

Recommended: Set ''(blank) on default level and Set to 'X' only for DSOs where the enhanced logic for SI (Secondary Index) behavior determination is needed.

INDEX_SEC_SEARCH_REGEX
the string used to find the row with the HASH ID. E.g. if using an export parameter of a class method, enter here the name of the export parameter.
Default: Empty. In this case only string "INCLUDE" is used when scanning the code.

Aggregates

Aggregates

In an aggregate the dataset of an object (InfoCube, DSO) archived by OutBoard is saved redundantly and persistently in a consolidated and summarized form into the database. Using OutBoard Aggregates, it is possible to access the archived data very quickly in reporting.

For using aggregating on the archived data, OutBoard offers the Aggregates section. There are two types for OutBoard aggregates:

Basic: Supporting maximum 16 characteristics for the aggregate.
With Star schema: Aggregating on more than 16 characteristics, can be turned on via parameter AGGREGATE_FORCE_STAR_SCHEMA in OutBoard Settings (also for OutBoard aggregates with less than 16 objects). The purpose for the development of OutBoard Aggregates with star-schema is to support slicing and dicing on NLS data during reporting. In comparison to the basic aggregate stored as one transparent table, in this case there are multiple dimension tables created and also one fact table (similar schema to the star-schema of an InfoCube).

These aggregates can be only created for archived InfoCubes and can be created in external storage (the external storage needs to be available -> to be defined via report /dvd/sm_mvc_storage_setup).

_Aggregates

To access OutBoard Aggregates, enter the OutBoard Browser, right-click on an object and select "Aggregates". You will step into the OutBoard Aggregates screen.

_{Edit OutBoard Aggregates screen}

For creating a new aggregate, click "Create New Aggregate" (F5). A window with Aggregate Name and Description appears. When working with an InfoCube, you can copy already created aggregates in the Administrator Workbench for SAP BW. For choosing this option, select "Copy from existing Aggregates" checkbox and insert the name of the existing aggregate.

_{Outboard Aggregates Functionality}

The OutBoard Aggregates screen allows you to create new aggregates, edit existing aggregates, edit items in an aggregate, fill the aggregate with data, and access user logs.

When new data is added to the NLS archive of an InfoProvider, the active Aggregates defined in OutBoard Cockpit will be updated and used in reporting. This option can be turned off using parameter REBUILD_AGGREGATE in OutBoard Expert Settings. Read more in the description of the parameter.

These functions are accessible from the top menu (tab Aggregates), toolbar at the top or after right-clicking on an existing aggregate. The toolbar in the OutBoard Aggregates screen provides several functionalities for working with aggregates. The buttons, from left to right stand for:

F2	Refresh	F7	Switch
F5	Create New Aggregate	Shift + F2	Delete Aggregate
Shift + F7	Activate all	Shift + F5	Transport Aggregate Definition
F6	Activate and Fill	F9	Logs
Shift + F6	Deactivate	Shift + F1	Documentation
Shift + F1	Edit	Shift + F1	Documentation

For editing an Aggregate, click "Edit" (Shift+F1). When Edit mode is activated the Aggregate cannot not used. You are able to predefine also list of InfoObjects to be used for the aggregate:

_{Build aggregate from list}

For saving a specific aggregate, select the aggregate and press "Save" (Ctrl+S). For saving all the aggregates press Save and you will be asked if you want to save all the unsaved aggregates. Adding more items can be easily done, by using drag-and-drop feature, so by moving an item from the tree in the left menu into the aggregate.
For deleting an item from an aggregate, right-click on the item and select "Remove component" or just mark the item and click on the Delete icon on the top menu.
For activating the specific aggregate, select the aggregate and press "Activate and Fill" (F6). For activating all inactive aggregates, press "Activate all" (Shift+F7). During the activation process you will not be able to enter Edit mode. After activating, the aggregate is turned ON and is prepared for reporting. By switching (F7) the aggregate OFF, it is turned off for reporting. By deactivating (Shift+F6) the aggregate, the tables with data are deleted.

The central part of OutBoard Aggregates screen contains list of aggregates with information in individual fields:

_{Information on Aggregates}

Aggregates – name of the aggregate
Technical name – OutBoard technical name of the aggregate
Save – save icon is shown when the aggregate was changed and needs to be saved. Aggregate must be activated after saving.
Status – status of the aggregate. Can be:

Activated – aggregate is activated
Deactivated – aggregate is deactivated

On/Off – On/Off status icon of the aggregate. Icon can be:

Green – aggregate is turned ON for reporting
Red – aggregate is turned OFF for reporting

Description – description of the aggregate
Aggregated to request – name of request in which the aggregate was created

By expanding the Aggregate node, individual items can be seen.

_{Items in an OutBoard Aggregate}

Aggregate logs

For entering the Logs menu, right-click on the aggregate and select "View logs" or mark the aggregate and click on the Logs icon.

_{View Aggregates Logs}

Before viewing the Logs, the Analyze Application Log screen appears, here you can set the object, time restriction and other settings. You can enter the Display logs menu by clicking on the Execute (F8) icon.

_{Analyze Application Log Settings}

To display a specific log, double-click on the log. The log information can be seen below in the Message section.

_{OutBoard Aggregate Logs}

OutBoard Aggregate Settings (for Star schema aggregates)

There are multiple OutBoard parameters, which can be adjusted in order to tune the performance when creating and reading OutBoard star schema aggregates:

AGGREGATE_FILLING_BUFFER_PACK - This parameter sets how many records are pre-aggregated from NLS storage upon their retrieval and stored in internal table as aggregated package. Always at least one full NLS-package is aggregated.

After the range for aggregated package is read, the result is written into the database and new NLS packages are processed. DEFAULT VALUE: 300.000

AGGREGATE_FILLING_BUFFER_SIZE - Buffer size for dimension tables entries. Records are first inserted into internal tables until reaching size of this parameter. Once the boundary is reached records are inserted in the database. DEFAULT VALUE: 100.000
AGGREGATE_FLLING_MASS_READ - Specifies how many records at once are selected from the aggregate fact-table in database. The higher the value, the more complicated the SELECT is executed on the database. DEFAULT VALUE: 100
AGGREGATE_FLLING_MASS_INSERT – This parameter sets the number of records inserted into aggregate fact-table in one processing block.
AGGREGATE_FORCE_STAR_SCHEMA - This parameter forces aggregate with less than 16 characteristics to be built in star-schema mode in secondary database.
SET_DEFAULT_SM_STORID_FOR_AGG - Identifies in which storage from the storage management is the aggregate created. This feature is only supported for the transparent Oracle storage.

Browser not supported