Upload Changes from a Table Layout

When you click the Upload Changes button for a Table layout, here's what happens:

1. The add-in checks the table for pending changes. If there are no pending changes, upload is skipped.
2. If a Pre-Upload macro is configured, it is invoked. If the macro throws an exception or returns any value other than true, the upload process quits.
3. For pending Create and Update operations, the rows are first validated locally, for example, data type, required, and so on. See Data Validation. Any failures are marked as failed and skipped (these rows do not produce requests on the business object service).
4. Pending changes are generally processed as follows:
   1. Updates result in a PATCH or PUT request on the item path.
   2. Creates result in a POST request on the collection path.
   3. Deletes result in a DELETE request on the item path.
   4. Rows marked for action result in a POST request on the item action path.

   For more details on how rows are sent in separate requests, see Upload Table Changes Using Separate Requests for Each Row.

   Note:

   Multi-Row processing is handled differently. See Upload Changes Using Multi-Row Requests.
5. Success and failure is noted in the Status column. Rows with warnings are indicated with a warning icon.
   
   
   
   Errors and warnings are cached and displayed in the Status Viewer when the business user selects a row. Here is a sample of the Status Viewer showing three warnings on 8 successful changes.
   
   
   
   
6. Successful Create rows are updated from the service if possible. These rows are converted into existing rows that can be edited.

   Note:

   If the service does not return the updated row, you will need to download again.
7. Successful Delete rows are removed from the Excel worksheet.

For Create and Update operations, the request payload only includes values for editable cells in a new or updated row. Read-only fields and custom action payload fields are not included. Whether a value is included for an editable cell depends on your add-in settings:

• For updated rows, the request payload includes a value for each editable field unless Send Only Changed Data for Updates is enabled in the Layout Designer. When enabled, only values that have changed since the last download or upload are included in the payload. See Send Only Changed Data During Upload.

• For new and updated rows, the request payload includes a null value for each empty cell in the row unless Omit from payload if value is empty is enabled for a field in the Business Object Field Editor.

  When this check box is enabled and the corresponding cell is empty, the field is not included in the request payload. When this check box is not checked and the corresponding cell is empty, the field is included in the request payload with a null value. See Omit Empty Values During Upload.

The add-in may send up to four requests to the service at a time for improved performance (on different threads). As a result, the order in which the rows are sent to the server is non-deterministic. It is not guaranteed to be in the same order as in the table. See Enable Parallel Requests During Upload.