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 the 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, within 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 the chosen destination folder.

PSAs and Change Logs

For proper management of temporary data (such as PSAs and ChangeLogs), a Housekeeping solution: ERNA has been developed.

Selecting the PSA or Change Log

To 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 in 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 choosing the Object from the context menu, 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}

After choosing the object from the context menu and 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 the "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 a maximum of 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 the 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 the 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 means 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 the NLS lookup API method (refer to the documentation part for NLS lookup).

The archived data is stored in the 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 the primary database. In comparison to the OutBoard Secondary index, which can also be stored in an 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 the 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 the OutBoard Browser -> context menu of the archived InfoProvider. If not available, contact your consultant to allow this functionality in your environment (parameter INDEX_SEC_ALLOWED):

_{Secondary Indexes via Outboard Browser}

A 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 the secondary index. The "REC" table number of rows is equal to the number of rows in the archive.

To view secondary index (SEC and REC tables) created other than primary database use report /DVD/SM_DATA_BROWSER via transaction SE38. This report allows you to check the 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 an already created one, use the buttons at the top of the screen (as above). After the user chooses to create a new secondary index, the following screen will appear:

_{Creating a new Secondary index}

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

_{Change the 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 the 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 built 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 the 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 the rebuild of the 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 the next archiving/reload of data and will be set to disable (not usable). In cases where the Secondary Index should be used, there is the need to be rebuilt in the /dvd/outboard -> Browser.

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

WRITER_INDEX_SEC_BUILD

• When switched on (value "X"), the 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 the process chain) - when set to "", the OutBoard secondary index will not rebuild during NLS Writer adjustments in the 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 a 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 the NLS package, the exact position is known and only relevant rows in the NLS package are accessed.

Recommended: Turned off (Value ' ') on the 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 the 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 the person responsible for maintaining parameters in TA RZ11, which values are the most suitable).

Optional usage of Secondary index

Let us discuss this topic in one example scenario. Having an end-routine of the transformation it may happen, that there are multiple lookups on the same DSO with very small differences. The same lookup on archived data using different filtering (e.g. EQ conditions vs. NE conditions in the filter) may result in different performance impacts. 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 the 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 the default algorithm should be used to determine SI (Secondary 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 the 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 a maximum of 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 of 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, choose the object from the context menu, 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 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), the toolbar at the top, or after choosing an existing aggregate in the context menu. 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 the Edit mode is activated, the Aggregate cannot be used. You are able to predefine also the 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 the 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, choose the item from the context menu 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 the OutBoard Aggregates screen contains a 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. The 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, choose the aggregate from the context menu 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 an internal table as an aggregated package. Always at least one full NLS package is aggregated.

After the range for the 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 table entries. Records are first inserted into internal tables until reaching the size of this parameter. Once the boundary is reached records are inserted into the database. DEFAULT VALUE: 100.000
• AGGREGATE_FLLING_MASS_READ - Specifies how many records at once are selected from the aggregate fact-table in the 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 an 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 the secondary database.
• SET_DEFAULT_SM_STORID_FOR_AGG - Identifies in which storage from storage management is the aggregate created. This feature is only supported for transparent Oracle storage.