(SP33) Settings Mass Archiving

DAP Creation

For a group of Objects, the user creates the Data Archiving Process in the first step.
OutBoard Mass archiving allows a user to:

• Create DAP (F8) for Objects without DAP
• Reactivate DAP (CTRL+F11) for selected Objects

_{DAP Creation}

_{Group archiving - settings}

Press:

Press:

For ChangeLogs and PSAs the DAP Settings are always the same – the data will be archived based on requests.
Information about individual tabs:
Data Archiving Process – the possibility to edit DAP parameters is only offered for a group of standard InfoProviders.
For ChangeLogs and PSAs, the DAP Settings are always the same – the data will be archived based on requests. For a group of InfoProviders you can set here:

• Characteristic for the Time Slices (only common Time Slices characteristics of all InfoProviders are optional)
• Maximum Size in MB and Maximum Number of Data Objects
• Package for DAP has to be specified here ($TMP or by user-created package). When DAP is created it is automatically assigned to this package. In case of DAP reactivation, the package in the Settings will be not assigned (if changed) - the user has to change the Package in case of reactivation manually. Default value for Package is $TMP. Object from $TMP cannot be transported!
• In SAP BW Release higher than 7.30 you are allowed also to archive non-compressed data via mass archiving
• If using OutBoard storage management, the Aging profile for data should be defined here. Make sure to reactivate existing DAPs each time, when the storage profile is changed in Massarchiving Settings

In case you are archiving PSAs or Changelogs, the archiving is based on the request's date (when the data were loaded into Object) by default. Additional partitioning is now possible with the exception of the Primary characteristic for time slices. In Mass archiving, additional portioning is also possible.

_{Additional Partitioning}

When specific additional partitioning characteristics are chosen, both the Initial and Scheduled run, will provide further options for the setup archiving request – option "Set characteristic values" becomes visible in both tabs.

_{Additional partitioning characteristics}

This condition is then automatically used when new archiving variants are created.
Semantic group – semantic group for the Mass archiving can be specified – only common InfoObjects of InfoProviders appear in the selection. This tab is only provided for standard ODSes and InfoCubes. Automatic creation of semantic group – since OutBoard summer release 2014, it is possible to create a Semantic group automatically for DSOs. With the new option in Mass archiving settings "Automatic creation of Semantic Group" all key fields of the DSO will be used in the Semantic group of the DAP. When this checkbox is enabled (can be found in the "Data Archiving Process" Tab), the "Semantic Group" tab is no longer required.
Initial run – overview of parameters needed for Initial Run Archiving Requests. A detailed description of Initial run settings can be found below.
Scheduled run – overview of parameters needed for Scheduled Run Archiving Requests. A detailed description of Scheduled run settings can be found below.
DAP can be created immediately or based on your selection in the standard Start Time screen.

_{DAP column with an indicator (ZVH_KO has created DAP)}

When creating the DAP (button Create DAP (F8) in Group Menu), the user can start the process based on his choice in the standard SAP scheduling screen.

_{Setting the start time for creating DAP}

Based on the given Package (not $TMP) in the Settings, the user will be asked, in which transport request the DAP should be added. If there already exist DAPs assigned to more requests, the one transport request corresponding to the DAP with the highest priority will be offered. The DAPs, which are created here, will be then automatically added to this provided transport request.

_{Group archiving - Transport request}

The DAP creation process can be monitored by refreshing the screen (Refresh button in the Application toolbar or F5). After the DAP of a particular InfoProvider has been created, it can also be viewed by clicking on the DAP icon in the table of InfoProviders (jump into TA RSDAP). Although it is possible to edit DAP here, it is only recommended to change DAP on a group level – functionality reactivate DAP.

Reactivate DAP

To reactivate DAPs for InfoProviders of the group, select them and go to the Menu Bar → Actions → DAP → Reactivate DAP (Ctrl+F11). To watch the process of reactivation; go to the Application Toolbar → Display Logs (Shift + F6). By the DAP reactivation, the user is again asked, in which transport this request should go – in the screen is the one proposed, which was given by the DAP creation.

View Logs

Press:

_{Mass archiving - logs}

Priority

OutBoard Mass archiving allows a user to prioritize the creation of DAP, Initial Run, and Scheduled Run and archiving for selected Objects of the group. To update the priority user has to select Object(s) and use the function Set priority (Ctrl + F12).

_{Setting the priority for InfoProvider}

Priorities are integer numbers and the lower the priority number, the higher the priority set for an Object (e.g. Object with the Priority set to 1 will proceed before Object with the Priority set to 2, etc.). This functionality is also accessible from Menu Bar → Actions → Set Priority. When a priority is set, this will be visible in the priority column

_{Mass archiving - Priority column}

As mentioned before, the group settings are dependent on the type of group. Based on the type of group you are able to change the Group Settings and define the way, how the objects will be archived.

Settings for Archiving

The user has two options:

• Create and execute Initial Run - Used to execute an initial archiving of data. In the settings of the Initial Run a user specifies the start of archiving, end of archiving, and by defining the archiving step in how many requests should be the mentioned time period divided.
• Create and execute Scheduled Run – Used to execute a scheduled archiving of data. This archiving can be scheduled in a process chain and could be used for example to archive once a year data older than a year.

Initial Run and Initial Run Settings
In order to create user-specific archiving requests, there is the need to edit the Settings → Initial Run tab.

_{Settings - Initial Run tab}

With user-specific Settings, one or more archiving variants are created for each InfoProvider/Object. Later, when the Initial Run is started, these variants are used to create archiving requests and the archiving can be executed. As mentioned before, the group settings in mass archiving are dependent on the type of objects (i.e. PSA or Cube).
Based on the type of group you are offered different options for archiving data and also transporting group objects. In the technical settings for Initial Run following parameters can be specified:
Run settings:

• Duration of Initial Run: After this time the creation and execution of archiving request will be stopped and the Initial Run has to be restarted in order to continue with the archiving. Default value 0 means no time limitation for archiving. Values given in minutes i.e. 2 hours duration would be given as 120.
• Max degree of archiving object parallelism: Number of background jobs for Initial Run. When changed during runtime, the new number will be updated.
• Max degree of archiving variant parallelism: Number of archiving variants running in parallel for an object for when end-deletion is used.

_{Run Settings in Initial Run tab}

Archiving conditions:
In this tab, you define how the data will be archived. This can be done either relative or absolute. In the following we will describe each of these two options:

_{Select Conditions in Initial Run Tab}

Relative mass archiving

_{Relative Select conditions in Initial Run Tab}

On this screen, the user defines archiving conditions relative to the current day. In the example above the characteristic for time slices is 0CALMONTH, therefore the user can view also a specification of the month in the red brackets. In this example, the user fills this screen in a then-current day in the year 2015 and sets the rounding unit "Year(s)", therefore only completed years are archived. When the user executes the archiving on the current day according to the above settings, the following three archiving requests are created:

In the first archiving request data older than 4 years is archived, so in this case, all data older than or equal to the year 2010 is archived, in the second archiving request all data older than or equal to the year 2011 is archived, and in the last archiving request data older than or equal to the year 2012 is archived.

Parameters that specify the archived data are the following:

• Time Shift when Initial Run Starts: This value specifies the start of the first archiving request. This step archives data into the past, therefore data older than the entered value is archived, but it is rounded according to the "Unit for Rounding the Time Shift" value. In the example above, it is the then-current day in the year 2015. The user enters the value 4 years as a time period, so the system sets the date of archiving start to 12.2010 ("Unit for Rounding the Time Shift" is set for whole years) and archives all data into the past (starting from the month 12.2010 into the past).
• Step of Initial Run: represents the time difference between the archiving date of the last created archiving request and the next archiving request. Based on this value, which is entered by the user, the archiving requests are repeatedly created and the archiving date for the next archiving request is shifted according to the “Step of Initial Run” value. It starts right after the value set in the Initial Start Run (first red rectangle) and continues until the date set in Initial Run End (second rectangle).
• Time Shift when Initial Run Ends: This value specifies the archiving start of the last archiving request. In the example, the user enters the value 2 years, so the system calculates the year 2012 as the end of archiving.
• Unit for Rounding the Time Shift: Only completed time periods are archived.

If the information about the time shift change to make these changes take effect; press the Enter or "Confirm date settings" button.

Absolute mass archiving

Here, the user can define absolute values for archiving – the format of these values should be the same as the ones that are chosen for time-slice characteristics. Choose Display/Create Variants and define values for the absolute archiving:

_{Absolute select conditions in Initial Run Tab}

 _{Mass archiving - variant definition - add multiple rows}

Variants Definition also offers an opportunity to Export the Absolute Archiving condition to the file and Import the Absolute Archiving condition from the file. Expected is an excel file in the .csv format.

_{Format of Excel (*.csv) table}

Use BADI to define variants - When the field is checked, BAdI defined by the user can be implemented to create variants for archiving.

_{Absolute Select Conditions (BAdl) in Initial Run Tab}

The user can define variants for archiving based on absolute values, instead of relative archiving. Developers have only to create BAdI implementation for BAdI /DVD/NLS_INTIAL_RUN_VARIANTS. The output format of the BAdI implementing class method /DVD/NLS_CREATE_INIT_VAR should be table type /DVD/NLS_TT_VAR_LIMITATION. The values of the output should have the same format as values for absolute archiving. What means in BAdI it should have the same format as Primary Partitioning Characteristic for DAP  - i_partnm. When this BAdI returns no values the initial run will be created the standard way.
The input parameters used for BAdI are the following:

Create custom variants - In case the restriction of data for archiving is complicated and requires using not only time-characteristic to determine data to be archived but also one or multiple additional characteristics, then you can use the functionality for uploading from the file. To use this, OutBoard custom variants should be created/added into mass archiving:

_{Custom variants}

After choosing Display/Create Variants the user will jump into the screen, where the custom variants can be created.

_{Custom variants in mass archiving}

An archiving variant is created based on the rows specified in the Variants-Definition -> the first four columns with the same value are used to define one archiving variant. In the example above this means the first archiving variant is created to archive data that satisfies the condition:
          0CALDAY between 05.01.2010 and 31.01.2010 AND
          ZCARRID equals 'LH' AND
          ZCONNID does not equal '0001542538'.
The variants can be also uploaded from a .CSV file separated by semicolons :

_{Import File}

In the uploaded file only the following values need to be filled with relevant data:
InfoProvider;Variant number;Characteristic;Sign;Option;Lower limit;Upper limit

Supported Signs:
I: Include
E: Exclude

Supported Options:
EQ: Equal
BT: Between
LE: Less equal
GE: Greater equal
LT: Less than
GT: Greater than

Process Flow Control

_{Process Flow Control in Initial Run Tab}

• Deletion-phase in last step only: For performance optimization reasons is suitable to delete the data at once for all Initial Run archiving variants. When this field is checked, Initial Run Archiving is done to the phase "50 - Verification Phase Ended Successfully" for each archiving variant except the last. After these Variants from Initial Run are executed to the Verification phase, the deletion phase will be started. If in Initial Run settings you choose Start of Initial Run a higher number than End of Initial Run, only the deletion archiving variant will be created here.
• Without starting deletion – When this field is checked, the deletion variant will not be created for Initial Run. Therefore all archiving requests will be executed only to the phase "50 - Verification Phase Ended Successfully" and no deletion will occur. The deletion can still be scheduled, i.e. in Process chains.
• Autom. Req. Invalidation After Error – An archiving request with an error will be automatically invalidated.
• Rebuild BWA index: when this field is checked, the BWA index is rebuilt when data is archived.