There are two ways to insert data into a DataStore object (advanced) using API. One is the Write Interface for ADSO types with an inbound table. The advantage of this technique is that you can see the changes to the inbound table before you activate the data to make it available for reporting, just as you can with a standard DTP-based load request. The other method requires a special modeling type of ADSO, the ADSO for direct update. Here is a list of the APIs that can be used.
APIs for ADSO with Write Interface
| Task | Target Table | API for Local Use | API for RFC Use | Description |
|---|---|---|---|---|
| Load | Inbound Table | RSDSO_WRITE_API | RSDSO_WRITE_API_RFC | Loads data from an internal table to the inbound table |
| Activate | Active Data | RSDSO_ACTIVATE_REQ_API_RFC | RSDSO_ACTIVATE_REQ_API_RFC | Activates all loaded requests |
The following APIs are available for a DataStore object for direct updates.
APIs for Direct Updates ADSO
| Task | Target Table | API for Local Use | API for RFC Use | Description |
|---|---|---|---|---|
| Load | Active Data | RSDSO_DU_WRITE_API | RSDSO_WRITE_API_RFC | Loads data from an internal table to the inbound table. |
| Delete | Active Data | RSDSO_DU_DELETE_API_RFC | RSDSO_DU_DELETE_API_RFC | Truncates or deletes data selectively from the table of active data. |
| Status | Active Data | RSDSO_DU_CLEANUP_API_RFC | RSDSO_DU_CLEANUP_API_RFC | Deletes API requests with errors. Red requests block further load requests by DTP or by API. |
There are different scenarios for the request administration. Let's review the options and use cases.
Scenarios for Write Interface
| Scenario | Request Administration | Effort and Complexity |
|---|---|---|
| Send Data Without Request (One Step) | A new request is opened for each data call. | Easy to implement. Suitable for scenarios with low frequency of data transfer, since otherwise too many requests can be created, thus making housekeeping necessary. |
| Send Data with Request (Write into Request) | The following sequence is used for this: Open Request, n times Send Data (with request and package), Close Request. | Complex implementation, since the sending system (for example, the ETL tool) must manage Open Request, Close Request, and Send Data with a consistent ID from the data package. Suitable for scenarios with higher frequency of data transfer. |
| Send Data with Message Request (Messaging Request). This option is introduced with SAP BW/4HANA 2023. | A new data package is opened internally for each data call. If no requests are opened, a request is opened when data is sent. A maximum of one request per object is open. | Easy to implement. Suitable for scenarios with higher frequency of data transfer. The request must be closed in the SAP Datasphere, SAP BW bridge system using a process chain. |
For scenarios with a high frequency of data loading, there is now a new way to load data into the corresponding object, the messaging request. To to use this option, you have to include the new process type, PUSH_MSGR, Close messaging request, in your process chain. Note the technical specifications when you are using the messaging scenario:
For HTTP, pass the request=MESSAGING parameter when calling the dataSend URI.
- For RFC, pass the MESSAGING=X flag when calling function module RSO_PUSH_SEND_STRING.
References
For more details refer to following sources: