TA: /DVD/NLS_MENU

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 affected custom developments
Translating corresponding SELECT(s)
Also pattern search for enhanced search process is included (in Pattern Search)

_{Lookup tool menu (Transaction: DVD/NLS_MENU)}

_{Lookup Cockpit}

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

TA: /DVD/NLS_LOOKUP

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}

The NLS Lookup Tool is a powerful tool, to decrease the effort needed for the translation of the relevant code objects. However, using the tool doesn't guarantee acceptable Lookup performance after translation (e.g. after the translation of SELECTs inside loops, translations of selects inside field routines, etc.). The Lookup performance can be dependent on a number of factors, i.e., the setup of DAP, how the data is archived, the storage being used, which NLS data is accessed, and in which way. If additional support is needed to fine-tune the performance of Lookups, contact your consultant for extended consulting or refer to OTB Best Practices, where some additional information can be found.

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 a 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 the 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 analyzed by choosing the 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 analyzed (in that case specify the DSO name, transformation ID, and choose only object type "transformations"). In such a scenario, the Lookup Analyser can be run also in the dialog (analysis of one given object doesn't take 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 in 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 a specific InfoProvider. You can also mark some objects as "remove from scope", e.g. if these code objects are in the $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 the Syntax check.

TA: /DVD/NLS_LOOKUP

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

Translation was successful.

The translation was not executed due to unsupported SELECT form in Lookup translator. Manual correction of SELECTS with this statement is required before translation. After manual correction, delete the row with adjusted Lookup in Lookup Browser, run Lookup analyser again for specific InfoProvider to find adjusted Lookup, and run Lookup Translator. Only the following SELECT types are supported:

SELECT */list of fields FROM active DSO table INTO/APPENDING (CORRESPONDING FIELDS) OF TABLE, table FOR ALL ENTRIES IN internal table WHERE condition only with AND operators without brackets, value assignment without variables.

If FOR ALL ENTRIES that is referenced to an internal table and is defined using 'include', the translation will be marked successful, but during the execution, the load will fail. This can be corrected by defining the needed table e.g. by listing all the needed fields in the referenced structure. A similar issue occurs when INTO TABLE is defined as TYPE TABLE of Data Element.

Translation unsuccessful – A problem occurred during translation - check translation logs.

Syntax check was successful - the SELECT can be translated correctly using the translation process. The list of supported SELECT(s) can be found in the Lookup Translator description.

Empty

The development found for translation. No further information available.

Code object was marked as not relevant for translation and was excluded from translation scope (e.g. code objects in $TMP and/or code objects, not in productive usage). This status is given to the code objects based on user decisions (not automatically).

The previously found Lookup cannot be found on the same row in the code object

The code object is not active anymore.

_{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 checkmarks the object as 'Syntax check was successful'.The NLS Cockpit shows a table with multiple columns that are described here:

Code ID	Program/routine technical name
Line no	The line number of the SELECT statement in the code (when displayed directly)
Inv rout	Check, if it's an inversion routine
InfoProvider	The technical name of analyzed InfoProvider
Object ID	Program/transformation/routine technical name
Src type/Trg type	Type of source object/target object
Source name/Trg name	The technical name of the source object/target object of transformation or rule
Field name	Affected field of a Field routine
Stat	Translation status
Token	The value which caused the syntax check to mark the code-object as not automatically translatable
Hash used for code	Unique hash assigned to translated code, code is visible also in TA Se38.
User Name	Name of the user who ran the translation
Date/Time tran.	Date/Time of translation

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 the 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 the 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, this SELECT will not be translated again. Please note, that this works only for SELECTs translated with the Lookup translator functionality.

Lookup cockpit: Settings

Lookup translator settings can be accessed via NLS Lookup Cockpit -> Settings.

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 the "TRY. ...END TRY." block, because no exceptions can be handled there.

Error handling in the 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, etc.) 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 customize the error handling for all automatically translatable objects except for:

Transfer rules (field routines, start routines) – because it is not possible to use the "TRY. ...END TRY." block here
Includes – are not allowed (includes can be used in various places, where there could be a 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 is 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 exception 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, it should be referenced 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 end routine and cx_root exception the error handling implementation could look like this:
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:

Description:	Variable:
Error type: cx_rsda_access_error	gref_dvd_access_error_&&CNT&&
Error type: cx_rsda_action_refused	gref_dvd_action_refused_&&CNT&&
Error type: cx_rsda_input_invalid	gref_dvd_input_invalid_&&CNT&&
Error type: cx_root	gref_dvd_root_&&CNT&&
Look-ed Up InfoProvider	gv_dvd_infoprov_&&CNT&&

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 the "Search for pattern" field.

⇒ this pattern can be written in code using a maximum of 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}

TA: /DVD/NLS_MENU

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

Create Virtual InfoProvider: A Virtual InfoProvider has to be created with the same structure and restrictions as PartProvider and added to the MultiProvider.
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)).
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 of adjusting mentioned can be done using the Virtual InfoProvider Management in the Near-Line Storage Menu (TA: /dvd/nls_menu)

TA: /DVD/NLS_MENU

Virtual InfoProvider creation - process restrictions:

1. 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 the 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}

Browser not supported