The user can either create or delete Virtual InfoProviders needed for reporting on MultiProvider and also adjust queries here.
It is crucial to review the Logs after each execution of the program. Logs contain important information about adjustment process - this is provided by clicking on Display Logs. For example:
in case the needed objects were created successfully
in case filters (query elements) were successfully imported into transport request
in case there was a problem (collision with another request, $TMP objects, SAP standard objects etc.).

TA: /DVD/NLS_MENU

_{Virtual InfoProvider management}

In the main screen the user is allowed to:

Create Virtual InfoProviders for InfoCubes with DAP. From SAP BW 7.30 Virtual InfoProviders can be created also for DSOs with DAP.
Adjust chosen/all queries for InfoCubes/DSOs with already created Virtual InfoProviders
Delete Virtual InfoProviders or only delete adjustments in chosen queries.

Create virtual infoproviders

In the select option of InfoProvider Selection fill in InfoProviders you want to create Virtual InfoProviders (VPs).

There are two options of creating Virtual InfoProviders:

With support of navigational attributes – in this case the connection of Virtual InfoProvider to archived data is based on Function Module (API).
Without support of navigaes – in this case the connection of Virtual InfoProvider to archived data is based on DTP.

This option is relevant only for SAP BW less than 7.30, because for higher releases the NLS data can be included in query results automatically.

Steps:

1. specify InfoProviders to be adjusted. Then execute:

_{Creating a new Virtual InfoProvider}

2. In the following screen, you will see only those InfoProviders from your selection that are relevant, by fulfilling the two following conditions:

→ InfoProvider has an existing DAP
→ is a PartProvider in at least one MultiProvider

From this list you can choose those InfoProviders, which you really want to create Virtual InfoProviders for:

_{Displaying of new Virtual InfoProvider hat meet conditions}

3. When you push the button Run Process in BG, series of popups are displayed.

_{Creating new Virtual Provider - BAdl usage}

→ the first one is connected to the usage of BAdI and to define names for created Virtual InfoProviders.
→ if BAdI is not implemented and used, the names of the newly created Virtual InfoProviders will be OTBVP. Further into the process a popup will ask about development package – here choose $TMP if you don't want to transport the created objects to other systems or specify a custom development package – afterwards you will be asked for 2 transport requests:

First one is for adjustments which can be added to development/correction request
Second one is for SAP objects which need to be adjusted in repair requests

_{Creating new Virtual Provider - Transport Request}

4. After you execute the program and in TA: SM50 you cannot see the job /DVD/NLS_VP_CRT, you can review the final logs for the creation process.
Here you can access important information about the adjustment process for the MultiProviders such as successful activation of created objects and insertion of needed objects into chosen transport request.

TA: SM50

_{Log view}

InfoProvider specific settings

In some cases InfoObjects in Part Providers can have predefined provider-specific properties (e.g. predefined value of 0FISCPER). In this case such properties are also copied to the objects in the created Virtual Provider.

_{Provider specific properties}

Usage of BAdI

If the BAdI is not used, the names of Virtual InfoProvider are created as "OTBVP". If the BAdI is used, the implementation for BAdI /DVD/NLS_VP_NAME_DEF needs to be created.
Parameters of BAdI:

i_cube_name	Technical Name of InfoProvider
i_cube_txtlg	Long description of InfoProvider
c_vcube_name	Technical name of the Virtual InfoProvider
c_vcube_txtlg	Long description of the Virtual InfoProvider

Once, the Virtual InfoProviders are not needed anymore (i.e. by upgrade of SAP BW) they can be deleted. The deletion process will be described later on.

Adjustment of Queries

After creation of Virtual InfoProviders connected to NLS data, you can adjust filters in queries defined on MultiProviders accordingly (e.g. if query defined on MultiProvider contains a filter on PartProvider, a filter on Virtual InfoProvider should be added to the query).

TA: /DVD/NLS_MENU

_{Query adjustment}

Using the second option in Virtual InfoProvider Management for Queries, should only be considered for adjustments for MultiProviders containing PartProviders with DAP. Only a small number of these would be relevant for adjustment – i.e. those, which have filter on PartProviders. These can be found by choosing:

Search all Queries – all queries are searched for filters on chosen InfoProviders and relevant will be pushed to further selection later.
User Selection of Queries – only queries proposed by user are searched for filters on chosen InfoProviders and will be pushed to further selection later.

After execution, you will see in a first screen all queries, which are not relevant for adjustment (do not contain a filter on selected Part Providers or were already adjusted for selected InfoProviders).
At first, the program finds in table RSZRANGE all records with field IOBJNM = 0INFOPROV, which represents filters on InfoProviders in queries. Then all query IDs are found, that correspond to queries with those filters. All queries that don't contain the requested filter are considered not relevant:

_{Adjust queries}

Here information about inconsistent elements will be display –such as obsolete filters, which were created in the system by an non-standard operation and/or there exists no active query with with this element. In the following screen you can see all queries with filters for the selected InfoProviders – from this list it is possible to choose only those to be adjusted.

If there are two of the same rows in the list, they must be same as each other, either both are checked or both uncheck. These two rows represent two different query elements and for correct adjusment of query both elements need to be adjusted the same way.

_{Adjust Queries}

When executing this process it's important to specify:

the development package
transport for needed adjustments

⇒ here you will be asked for 2 transport requests. Keep in mind, that:

First one is for adjustments which can be added to development/correction request
Second one is for SAP objects, which need to be adjusted in repair requests

This process is started in background - new filters with restrictions on Virtual InfoProviders are created and added into transports. Again it is crucial to review the logs because there may be conflicts with other transport requests.

Restriction

Only Filters with "equal" or "exclude" are supported. If PartProvider is a suitable range filter, then Virtual InfoProvider is not added to filter. This is recorded in logs and user has to adjust these queries manually, if needed.

Display logs to see information about adjustments and avoiding problems:

_{Display logs}

Afterwards the adjusted queries need to be generated using TA "RSRT". Once in "RSRT" click Generate Queries – each query will be regenerated during the next call-up. The generation will also need to called after transport with adjustments is imported:

TA: RSRT

_{Query monitor}

Handling transports – best practices

In case queries cannot be adjusted in each system separately, we recommend following this scenario:

Create Virtual Providers for chosen Part Providers and release all transports connected to this adjustment. Import these transports in system landscape.
Select all queries connected to the created Virtual Providers in the first step and release all connected transports. Import the transport in system landscape. Generate Queries after transports are imported.
Start to adjust other queries only if previous two steps are already executed and were successful. We recommend following this process – based on our experience with multiple queries need to be adjusted and usually multiple transport requests are created. In case this is not done as proposed, the user may find many conflicting transports – with the handling of such conflicts may be time consuming.

Deletion of Virtual InfoProviders

In the deletion process the adjustments are done in the same way as for the previous cases, but instead of adding the objects where needed, the objects are deleted from filters in queries or MultiProviders. If adjustments of MultiProviders are not needed anymore or some queries need to be adjusted to a previous state, this can be done using the third option in the Virtual InfoProvider Management.

TA: /DVD/NLS_MENU

_{Virtual InfoProvider deletion - only Query elements}

The second option Delete only Query Elements, in this case only filters are deleted from queries (only Equal and/or Exclude filters). The user needs to specify the queries to be adjusted and Virtual InfoProviders, which should be removed from filters.

If there are two of same rows in the list, both should be checked or unchecked. These two same rows represent two different query elements and for correct deletion both elements need to be adjusted.

When the program is started, a similar series of popups will be displayed as in the process for the adjustment of queries. Background job is started, which adjusts the filters accordingly. It is important to review the deletion logs to ensure the jobs were completed successfully. Now let us discuss the process Delete VP and Query Elements. In this case only Virtual InfoProviders to be deleted have to be specified and all relevant queries will be adjusted automatically.

_{Virtual InfoProvider deletion - VP and Query elements}

When the process is executed, chosen Virtual InfoProviders and all needed queries will be adjusted accordingly. In the process the user is again asked to specify two transport requests:

First one is for objects which can be adjusted in development/correction request
Second one is for SAP objects, which need to be adjusted in repair requests.

The deletion report /DVD/NLS_VP_DEL is executed in background. This report deletes all objects connected with the chosen Virtual InfoProviders such as: Deletion of transformation, DTPs, Function modules; removing Virtual InfoProviders from MultiProviders and adjustment of filters in queries. For SybaseIQ storage see also Best Practises document – under the topic of master data replication is discussed there in detail.

Navigation attribute support

As of OutBoard release in November 2013, navigation attributes in reporting are supported. In reporting, when filtering on navigation attributes, standard SAP functionality doesn't send the filtered values to NLS; therefore all the data is returned from NLS and the filtering is then done on OLAP side. Although this method is working and only the relevant values are returned in the output, however using this logic may lead to long runtimes and even memory problems.
A new logic has been implemented to improve runtime. By combining the Virtual InfoProvider and table buffering, runtime speed is comparable with reporting on an online database. This combination allows for filtering data on NLS side (Virtual InfoProvider) and returning output in a very good runtime (buffering).SybaseIQ is supported by OutBoard since Spring release in 2014. Using a similar logic, it is possible to filter data directly on SybaseIQ and send only relevant entries for further processing. This is achieved by loading Master data tables to SybaseIQ and then using JOIN statement on the archive table. This allows filtering directly on NLS side, either when navigation attributes are used in query filtering or in selections.
To enable this functionality the user should follow steps:

Enable the functionality in Outboard settings
Create Virtual InfoProvider (as described above)

Outboard settings relevant for navigation attribute support:

NAV_ATTR_SELECTION – parameter to turn the navigation attribute support functionality: on (1) or off (" "). This setting can be edited on InfoProvider level. It is recommended to turn off this parameter for SybaseIQ archiving storage, because needed filtering is done on the database level and there is no need to use the standard Outboard navigational functionality in this case.
NAV_ATTR_BUFFER – parameter to define how many records can be buffered
NAV_ATTR_FILTER_POS – this parameter is only relevant if "RANGE" functionality is used for filtering on NLS data. It defines the order of filtering, value 0 – filtering first on navigation attribute and then the rest, value 1 – first general filtering and then filtering on Navigation attribute. This can affect the runtime, depending on query filtering settings, if there's more filters on Navigation attributes than the value 0 is recommended, If there are more filters on non -navigation attributes then the value 1 is recommended.
NAV_ATTR_IN_SIQ – this parameter defines if the new logic based on Virtual Provider using function module is used.

_{Navigation attribute support settings}

Aggregates support

As of winter release February 2014, OutBoard aggregates are supported in conjunction with Navigation attribute support.Translation of selection on navigational attributes. When reporting on the selection condition in navigational attributes is smaller than 100 entries, this is automatically translated to a condition on normal characteristics. Now it is possible to avoid time-consuming processing of navigational attributes by moving the processing to normal characteristics.

Browser not supported