Table of Contents:

Requests

Failed requests

In the case the request fails for a reason, it can be fixed manually in the SNP OutBoard™ Data Tiering Request Browser.

Failed offloading request

In the case of a failed offload request, it can be either repaired automatically in the next scheduled run or you can repair it manually by clicking the button in the Activity field. The manual correction can also be scheduled.

In the case of a failed reload request, you can only repair it manually by clicking the button in the Activity field. The manual correction can also be scheduled.

While failed reload requests exist, any further DataProvider processing is not possible, as it could cause inconsistency of data. Therefore, you must repair it manually as described above. The information about the failed reload can be viewed in the log of the specific request.

A failed offloading request will be always repaired in its original condition. In case you change the offloading condition before the repair, the request will contain the original condition.

Locked requests

During data offloading, data reloading, or writer processing, the DataProvider is locked. For this reason, only one operation can be performed at a time on a DataProvider.

If there are 2 or more operations scheduled at the same time, only one will be processed. The request logs of the other operations will contain the information about the locked DataProvider. To restart these stopped operations, wait until the first operation is finished and then click on the button in the Activity field.

Change of DataProvider structure

After you archived a DataProvider successfully, the structure of a DataProvider may change in the future. For example, a DSO1 is archived as a DataProvider with 20 fields, but later, the DSO1 is enhanced with an additional 21^stfield.

After such a change in the structure, the target table and the VirtualProvider must be regenerated. This regeneration is performed automatically for the target table and semi-automatically for the VirtualProvider in the Wizard.

In the case this regeneration fails, perform the following steps in DataProvider Wizard:

VirtualProvider regeneration

In our example, VirtualProvider linked to the DSO1 must be adjusted and transported. You can view that the regeneration failed through the RSRT transaction when you execute a query. The red-marked message informs us that we must perform the regeneration.

You can find the information about a failed regeneration also in the third step of the Wizard, Object adjustment.

To regenerate the VirtualProvider, go to Object adjustment, click on Queries, select the particular DataProviders and click Execute. After this step the VirtualProviders will be adjusted to include a new field and can be added to the transport.

Please keep in mind you can only add and not remove fields from a DataProvider in a modeling environment. You can find a list of supported changes in the chapter (2205) Functional Limitations.

Target table regeneration

The structure of a target table will be adjusted automatically after a change in the structure (in our example, the program will add the 21^st field will be added to the definition of the target table). This change is automatically performed by SNP OutBoard™ Data Tiering before every offloading, which checks the structure of the source and target table.

This adjustment can be also triggered manually by executing a report available in Expert tools. Go to the menu Other in the SNP OutBoard™ Data Tiering main screen and choose Expert tools.

SAP Known issues and recommendations

Analysis Process Designer (APD) short dump

In case one of the APD objects isn't in a consistent state, a short dump may occur during the execution of the Impact analysis. The same short dump occurs within the RSA1 transaction when you check an inconsistent APD object.
Please check the SAP Note 2252271 for a solution to this issue.

Browser not supported