Submit operation example

1. Use the same mechanisms to create, update, and delete records in JSDO memory as is described for each respective Create operation example, Update operation example, and Delete operation example.

When you call saveChanges(true) to synchronize pending changes with the server database, this executes the OpenEdge ABL server routine that implements the Data Object Submit operation. This operation processes all pending record changes sent from the client in a single network request and returns the results of all these changes from the server in a single network response.

Note that this Submit operation is supported only for OpenEdge Data Object Services, where the Data Object is implemented for a ProDataSet resource with one or more temp-tables that supports before-imaging. This method call relies on client before-image data to identify all pending record changes for the network request since the last invocation of the fill( ) or saveChanges( ) method on the JSDO. The server then relies on the before-image data to identify and process each record change according to its type. If a ProDataSet resource and the JSDO that accesses it are not defined to support before-image data, making this call to saveChanges( ) raises an exception.

When you call the saveChanges( ) method to invoke a Submit operation on a supported resource, if jQuery Promises are supported in your environment, it returns a Promise object on which you can register callbacks to handle the results for all record changes in the request. Otherwise, you can subscribe event callbacks to handle the results of the request.

Operation results are thus returned as follows:

1. For each record change that the Submit operation completed, the JSDO fires an afterDelete, afterCreate, and afterUpdate event for each record change of the corresponding type in order to execute any callbacks you have subscribed to handle these events.

2. The JSDO fires an afterSaveChanges event to execute any callbacks you have subscribed to handle that event. In addition, any returned Promise object executes the Promise callbacks that you have registered, depending on the overall Submit operation results. (Note that the signatures of all Promise callbacks are identical to the signature of the afterSaveChanges event callback.)

After the saveChanges( ) method completes a Submit operation successfully, no working records are set for the tables in the JSDO.

Note: If a Submit operation results in successful record create or update that includes changes to the record on the server that was sent from the client (for example, an update to a sequence value), JSDO memory is automatically synchronized with these server changes when the request object with the operation results is returned to the client.

Note: If an error occurs on the server for a Submit operation, and the autoApplyChanges property has the default value of true, each record change is automatically accepted or rejected in JSDO memory based on the presence of an error string that can be returned by calling the JSDO getErrorString( ) method on the record. If you want to accept and reject record changes to synchronize with any server transaction that handles for the Submit operation, you must set autoApplyChanges to false and call the appropriate accept*Changes( ) or reject*Changes( ) method to handle the results.

For more information on handling saveChanges( ) method results for a Submit operation, see the description of the saveChanges( ) method.

Following is an example showing an OpenEdge ABL implementation of the Submit operation and its invocation on a JSDO.

Note: The bold code in the JavaScript examples primarily trace the path of referenced JSDO method and callback parameters, as well as key code elements in the example, including those elements that are directly or indirectly referenced in the example description and notes.