Requests

Failed requests

In the case the request fails for a reason, it can be fixed manually in the DataTiering 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 with its original condition. In the 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 the 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 the 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 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 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 into the transport.

Please keep in mind you can only add and not remove fields from a DataProvider in a modelling environment. If you're adding a key field, it must be the last in a key field sequence.

Target table regeneration

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 OutBoard DataTiering before every offloading, which checks the structure of source and target table. Adjustments performed by the user aren't necessary.

SAP Known issues and recommendations

Analysis Process Designer (APD) short dump

In the case one of the APD objects isn't in a consistent state, there might be a short dump during the execution of the Impact analysis. The same short dump occurs within RSA1 transaction, when you check an inconsistent APD object. Please check the SAP note 2252271 - ST22 Dump GETWA NOT ASSIGNED in CL RSCRMBW BAPI for a solution of this issue.

Browser not supported