When data is loaded into SAP BW it can be accessed from customer developments (e.g. transformations, reports and function modules). In cases where data is partially archived and corresponding objects are accessed via SELECT(s) or other methods, these developments need to be adjusted in order to read (also) archived data.

Using SAP standard  functionality this is possible for SELECT(s) on DSO active tables (/BIC/A00). In the OutBoard NLS Lookup Cockpit the user is guided through the translation process (adjustment of SELECT statements to read also NLS data), which includes steps as:

• Finding affected customer developments and checking if these developments can be translated
• Viewing the effected custom developments
• Translating corresponding SELECT(s)
• Also pattern search for enhanced search process is included (in Pattern Search)

<sub>Lookup tool menu (Transaction: DVD/NLS_MENU)

Lookup Cockpit</sub>

The NLS Lookup Cockpit Menu can be started using TA: /dvd/nls_menu or from OutBoard cockpit Run -> Expert Tools or via transaction /dvd/nls_lookup.

_{Expert tools}

→ the Cockpit should be used as a central point for maintenance of lookups

In the NLS Lookup Cockpit, the user is able to make a sub-selection of objects for the display (using standard screen filtering) or  work with the data without any selection (all found code-objects with lookups will be displayed):

_{Lookup cockpit}

Lookup cockpit: Analyse

In the first step all developments should be found with SELECT(s) on InfoProvider(s) with archived data. For this purpose double-click "Analyse" and specify DSO(s) to be analyzed. If running the analysis for all object types, the job should be executed in the background (based on system size and number of custom developments, this can take some time):

_{Lookup analysis}

The analysis can be started:
a/ as a dialog
b/ background job
Results can also be viewed later in NLS Lookup Cockpit. It is recommended to run this analysis for a few objects at each time – scanning the whole system for custom developments can be a very time consuming process.
During the analysis all of following custom developments specified in the selection will be searched for SELECT(s) on active DSO tables:

• Transformations: Start routines, End routines, Field routines, Expert routines, Global codes
• Update rules: Start routines, Field routines
• Transfer rules: Start routines, Field routines
• ABAP codes: Programs, Includes, Function modules, Class methods in Z* and Y* namespace and Includes in Z* and Y* and L* namespace.
• APD routines

The user can also make a pre-selection of objects to be analysed by choosing only subset of the pre-defined object types. This can be handy, if e.g. for  some reason only one given transformation has to be analysed (in that case specify the DSO name, transformation ID and choose only object type "transformations"). In such scenario, the Lookup Analyser can be run also in dialog (analysis of one given object doesn't tale very long).

_{Lookup analyser - transformations}

Lookup cockpit: Maintenance

The results of the Lookup Analyser can be displayed in the Lookup Cockpit including additional information about the translation status and developments found for the translation process. After switching into 'Edit Mode', you can also delete rows in cases where some Lookup code was adjusted already or there is the need to re-run the analysis for specific InfoProvider. You can also mark some object as "remove from scope", e.g. if these code object are in $TMP package and therefore not relevant for the productive translation. It is also possible to change the status of some development, in order to re-run Syntax check.

 One of the two most important output fields in the Lookup Browser is the Translation status field, which gives you following information:

_{Lookup Cockpit - results}

The second most important column is the Token value. Here the information can be found as to why the Syntax checks that marked the code-object as not automatically translatable. In order to translate – the Select condition has to be adjusted so that the Syntax check marks the object as 'Syntax check was successful'.The NLS Cockpit shows a table with multiple columns that are described here: 

Lookup cockpit:Syntax-Check and Translate

In the NLS Lookup Cockpit the Syntax-check and Translation process can be started:
a/ In order to execute one of the operations, one / multiple rows must be selected first (use standard ALV functionalities to restrict data for the operation).

_{Syntax check and translation}

b/ When the Syntax-Check is started, the translation process is simulated and in case an issue is found, the columns "Translation status" and "Token" are adjusted accordingly.

⇒ During the Syntax-Check SELECT(s) will be checked against supported type of SELECT(s) If a select is marked with "Yellow status", there are adjustments needed, before such select can be translated automatically in the Lookup Cockpit.

c/ During the translation process SELECT(s) are replaced with generated code containing SAP standard method for Lookups on archived data and includes containing variable assignments.

⇒ If needed, the NLS Lookup usage can be switched on/off in the Expert OutBoard Settings using parameter NLS_LOOKUP_TRANSLATION (as Default Setting for all InfoProviders and also InfoProvider specific).

d/ During the translation the user will be asked to specify two transport requests:

1. TR1 = is for generated includes (has to be imported into system first)
2. TR2 = if for adjusted code objects

e/ During the transport into the system landscape it's important to make sure, that the transport TR1 with generated includes is imported first. If not, this can cause problems during activation while importing TR2.
In case the translation will be started for a SELECT already translated before, these SELECT will not be translated again. Please note, that this works only for SELECTs translated with the Lookup translator functionality.  

Lookup cockpit: Error handling

There are three exception types that exist for the select method of the NLS Lookup API class cl_rsda_infoprov_query.
These three types of errors/exceptions can be handled for the "select" method:

• CX_RSDA_INPUT_INVALID
• CX_RSDA_ACCESS_ERROR
• CX_RSDA_ACTION_REFUSED

→ general CX_ROOT exception can be handled after the Lookup API call and is supported in the lookup translation tool.
→ all of these exceptions need to be handled in the „TRY. ...END TRY." block. Hence, in obsolete transfer rules, it is not possible to use "TRY. ...END TRY." block, because no exceptions can be handled there.

Error handling in Lookup tool

The error handling functionality in the Lookup tool allows you to create custom error handling based on the internal guidelines and best practices (it is optional only).
⇒ if using custom error handling in the Lookup tool, the user is responsible for the error handling to be syntactically correct and re-usable
It is recommended to run an automatic translation for each code object and subobject type (transformation, program, update rule, start routine, field routine...) and review ⇒ if the result is as expected (if the error handling was implemented correctly, the code object should be active after the translation).
The error handling maintenance is accessible from the NLS Lookup Cockpit -> Error Handling:

_{Error handling in NLS Lookup Cockpit}

Here you can customise the error handling for all automatically translatable objects except for:

• Transfer rules (field routines, start routines) – because it is not possible to use TRY. ...END TRY. block here
• Includes – are not allowed (includes can be used in various places, where there could be limitation for usage of TRY. ...END TRY. block). In this case you can adjust the error handling after the translation.

The error handling behavior can be defined at the object level or sub-object level:

_{Error handling customizing}

a/ If both, error handling on the object level and error handling on the sub-object level are defined for a specific error type, then the sub-object error handling will be used.
b/ If the error handling behavior is defined only on the object level, it will be reused for all the „not-implemented" sub-objects error handlings too.

⇒ it is recommended to define the error handling for each sub-object separately, to avoid possible misunderstandings.

By default, the CX_ROOT exception is caught in all (allowed) code objects translation (whether the error-handling behavior is defined in Lookup Cockpit or not). The other exceptions types are caught only if the error handling behavior is defined.
During the translation process, the CATCH <error_type> INTO gref_dvd_<error_type_ID>_&&CNT&& is written in the translated code object automatically.
CATCH example
Here the variable gref_dvd_<error_type_ID>&&CNT&& is defined before the translation process and can be reused. In order to reuse, it should be referenced to as gref_dvd_&&CNT&& (the place holder &&CNT&& will be replaced by the unique ID during the translation process).
For example, for the transformation's endroutine and cx_root exception the error handling implemenation could look like:
monitor_rec-msgid = 'RSDMDT'.
        monitor_rec-msgty = 'E'.
        monitor_rec-msgno = 123.
        monitor_rec-msgv1 = gv_dvd_infoprov_&&CNT&&.
        monitor_rec-msgv2 = gref_dvd_root_&&CNT&&->get_text( ).
        APPEND monitor_rec TO MONITOR.
        RAISE EXCEPTION TYPE CX_RSROUT_ABORT.
Variables for specific error types/InfoProvider name:

Limitation: There is a limitation for number of characters in a row to be inserted into error handling – 72 characters max. Therefore you should limit the number of characters for each row based on this limit.

Pattern Search

To find patterns with a hidden selection on an archived DSO the user can use this pattern search.
To run the search, write the pattern into "Search for pattern" field.

⇒ this pattern can be written in code using  a maximum 5 lines.
⇒ the code scans all Z* and Y* InfoProviders and all Z* and Y* ABAP programs. Pattern search also accepts wildcard characters and it is recommended to start with , e.g. *SELECT*PATTERN.

_{Pattern Search Selection}

Pattern Browser

After the Pattern Search was executed, the results can be seen in Pattern Browser – Simply specify the pattern to be shown:
The description of the output list is similar as for Lookup Browser:

_{Pattern Browser results}

Reporting on a Multiprovider

When reporting on a MultiProvider in SAP BW before version 7.30, this MultiProvider needed to be adjusted for it to read the archived data of a PartProvider. If navigational attributes support was required when reporting on MultiProvider, the same adjustment was also needed (no matter the SAP BW Release):

1. Create Virtual InfoProvider: A Virtual InfoProvider has to be created with the same structure and restrictions as PartProvider and added to the MultiProvider.
2. Connect with archived data: This Virtual InfoProvider should be connected (only) with the archived data from the PartProvider (up to SAP BW 7.30 this is done by using standard transformation and DTP, for support of navigational attributes the connection is based on Function Module (API)).
3. Adjust filters in Queries: Any restrictions done on the PartProvider in Queries also have to be aligned for Virtual InfoProvider (Filters in Query must be adjusted to include/exclude created Virtual InfoProviders).

⇒ the three steps adjusting mentioned, can be done using the Virtual InfoProvider Management in the Near-Line Storage Menu (TA: /dvd/nls_menu)

Virtual InfoProvider creation - process restrictions:

1. The Virtual InfoProviders can be created only for Part Providers that already have DAPs created
2. Only Equal and Exclude filters will be adjusted accordingly in queries. Queries with range filters need to be adjusted manually by user (the user will be informed in logs, if such a query was found)
The name given to Virtual InfoProviders can be created in OutBoard using a naming convention or defined by a BAdI.

_{NLS management
Reporting on Multiprovider}