3.1.4.2.112 ApiExecuteBatch (Opnum 113)

(Protocol Version 3) The ApiExecuteBatch method instructs the server to perform a transacted series of modifications, relative to the designated key, to the cluster registry. The contents of the registry are changed only if all the modifications succeed; the first failure causes all previous modifications to be backed out.

The modifications are described in a CLUSTER_REG_BATCH_UPDATE structure, as described in section 2.2.3.17. Each batch update command instructs the server as to how the registry is modified.

The server MUST NOT fail this method if the key identified in a CLUSREG_CREATE_KEY already exists. The server MUST NOT fail this method if the key identified in a CLUSREG_DELETE_KEY command or the value identified in a CLUSREG_DELETE_VALUE does not exist.

The server MUST maintain a current key pointer that is initially set to the designated key and is changed to the key identified in a CLUSREG_CREATE_KEY command when it is executed. The current key pointer is cleared when a CLUSREG_DELETE_KEY command is executed requiring a subsequent CLUSREG_CREATE_KEY command to be executed before any CLUSREG_SET_VALUE or CLUSREG_DELETE_VALUE commands can be processed. After the key pointer is cleared, the server MUST fail this method with ERROR_INVALID_PARAMETER (0x00000057) if a CLUSREG_SET_VALUE or CLUSREG_DELETE_VALUE command is encountered prior to a CLUSREG_CREATE_KEY command.

The Name field for the CLUSREG_CREATE_KEY and CLUSREG_DELETE_KEY commands is the path to the key to be created/opened or deleted and is relative to the designated key. The key namespace is hierarchical, and each level in the hierarchy is separated by a Unicode backslash ("\"). The following are examples of properly formed key names: "test", "test\KeyToDelete".

The following table describes the command type, how the Name and Data fields are interpreted for the command, and the effect the command has on the key pointer.

The server MUST accept an ApiExecuteBatch request for processing if it is in the read/write state, as specified in section 3.1.1.

The server MUST require that the client have a security access level of "All" (section 3.1.4).

 error_status_t ApiExecuteBatch(
   [in] HKEY_RPC hKey,
   [in] DWORD cbData,
   [in, size_is(cbData)] UCHAR const * lpData,
   [out] int * pdwFailedCommand,
   [out] error_status_t *rpc_status
 );

hKey: The RPC context handle for a key that was previously obtained by a call to ApiGetRootKey, ApiCreateKey, or ApiOpenKey. The key represented by this parameter is the initial key from which all commands in the buffer of the lpData parameter are executed.

cbData: A 32-bit integer that provides the size, in bytes, of the buffer pointed to by the lpData parameter.

lpData: A pointer to a buffer containing a variable-length CLUSTER_REG_BATCH_UPDATE structure, as described in section 2.2.3.17, that contains a series of commands describing a set of modifications to be applied to the cluster registry.

pdwFailedCommand: A pointer to a 32-bit integer that is written, upon failure of the method, with the number of the command that caused the failure. Commands are numbered beginning at one and increase monotonically.

rpc_status: A 32-bit integer used to indicate success or failure. The RPC runtime MUST indicate, by writing to this parameter, whether it succeeded in executing this method on the server. The encoding of the value passed in this parameter MUST conform to encoding for comm_status and fault_status, as specified in Appendix E of [C706].

Return Values: The method MUST return the following error codes for the specified conditions.

Return value/code	Description
0x00000000 ERROR_SUCCESS	Success.
0x00000006 ERROR_INVALID_HANDLE	The data that is pointed to by the hKey parameter does not represent a valid HKEY_RPC context handle.
0x00000057 ERROR_INVALID_PARAMETER	A CLUSREG_SET_VALUE or CLUSREG_DELETE_VALUE command has been encountered prior to a CLUSREG_CREATE_KEY command.

For any other condition, this method MUST return a value that is not one of the values listed in the preceding table. The client MUST behave in one consistent, identical manner for all values that are not listed in the preceding table. The client SHOULD treat errors specified in section 3.2.4.6 as recoverable errors and initiate the reconnect procedure as specified in section 3.2.4.6.