Upload Changes from a Form-Over-Table Layout

When a user clicks the Upload Changes button for a Form-Over-Table layout, here's what happens:

1. The add-in checks the form for a pending Update or pending Create operation and the table for pending changes. If there are no pending form or table 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. When the form has a pending Update or pending Create operation:
   For a pending Update:

   1. A GET request is sent to the parent's item path.
   2. Form field values (for example, data type, required, and so on) are validated; read-only fields are skipped. If validation failures exist, the upload is stopped and no subsequent REST requests are made.
   3. When all form fields are valid, a request (PATCH/PUT) is sent to the parent's item path. The payload for this request contains the values of all form fields that have been changed. If configured, empty values are skipped. See Omit Empty Values During Upload.
   For a pending Create:

   1. Form field values (for example, data type, required, and so on) are validated (see Data validation in Managing Data Using the Oracle Visual Builder Add-in for Excel); read-only fields are skipped. If validation failures exist, the upload is stopped and no subsequent REST requests are made.
   2. A POST request is sent to the parent's collection path. The payload for this request contains a value (possibly empty) for every editable form field in the form. If configured, empty values are skipped. See Omit Empty Values During Upload.

   The child table is not involved in this step.

4. The results of the form upload are reflected in the status viewer immediately.
5. If the form upload fails, the add-in stops and does not attempt an upload on the child table.
6. If the form upload succeeds, the add-in proceeds with the child table as follows:
   1. Checks the child table for pending changes, creates, deletes, custom actions, etc.
   2. If changes are found, the child table upload proceeds in the same manner as a Table layout upload with one important difference: the child business object's paths are used for each request.

The number of requests used in the upload depends on the scope of the changes as well as the state of the Send Descendant Rows in Parent Payload check box. If this check box is selected, the add-in sends parent changes and all child changes in a single request. See Upload Parent and Child Changes in the Same Payload.

If this check box is deselected and the form and table both have pending changes, then the add-in sends the changes using a minimum of two requests: one for the form and one (or more) for the child table.

For the form changes, notification of success and failure is noted in the Status Viewer.

For table changes, success and failure is noted in the table's Status column and well as in the Status Viewer. See Upload Changes from a Table Layout for more information about table status after Upload.