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

Information about individual fields:

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:

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

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

Filter (F5)

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 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.

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

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.

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

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).

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.

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}

Usage of secondary index

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

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

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

1. Basic: Supporting maximum 16 characteristics for the aggregate.
2. 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.

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:

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 of storage management is the aggregate created.