Package com.smartgwt.client.docs

# Interface ServerProcess

public interface ServerProcess

### Server-Side Process Execution

Server-Side Process Execution

`OperationBinding.process` allows a declarative `Process` workflow to execute server-side as an alternative to `OperationBinding.script` or a `DMI`. The workflow is defined in the same XML format used by the `com.smartgwt.client.tools.WorkflowEditor`, making it visually editable by non-programmers.

When to Use Each Approach

Approach | Best For | Editable?
--- | --- | ---
`process` | Multi-step declarative logic: validate, branch, CRUD across DataSources, send email | Yes (WorkflowEditor)
`script` | Imperative logic: complex calculations, string manipulation, calling Java APIs directly | Code only
DMI (serverObject) | Heavy Java logic: third-party library integration, complex transactions, performance-critical paths | Code only

Input State

The process receives automatic input state from the DSRequest:

- `criteria`: Request criteria
- `values`: Request values (add/update)
- `oldValues`: Previous values (update)
- `operationType`: "fetch", "add", "update", or "remove"
- `dsName`: DataSource ID
- `operationId`: The operationBinding's operationId

These are available in `TaskInputExpressions` as `$criteria`, `$values`, etc.

Output / Response

The process produces a DSResponse via precedence:

1. If `process.state.dsResponse` is set → used directly
2. Else, output of last `DSRequestTask` that ran → its dsResponse.data
3. Else → empty STATUS_SUCCESS

Error Handling

If any task fails and has no `DSRequestTask.failureElement`, the process aborts immediately and returns STATUS_FAILURE. If the operation participates in a transaction (`OperationBinding.autoJoinTransactions`), the transaction rolls back.

Server-Side Task Compatibility

Only tasks that operate on data, logic, or communication work server-side. UI tasks (FormSetValuesTask, ShowHideTask, GridFetchDataTask, etc.) are NOT available and will log a warning if encountered.

Performance

Process execution uses server-side JavaScript context pooling. First invocation per pool slot incurs module loading overhead; subsequent invocations reuse the pre-loaded context with near-zero overhead beyond the actual DataSource operations.

See Also:
  - `OperationBinding.process`
  - `OperationBinding.script`
  - `DSRequestTask`
  - `DSFetchTask`
  - `DSAddTask`
  - `DSUpdateTask`
  - `DSRemoveTask`
  - `ScriptTask`
  - `DecisionTask`
  - `MultiDecisionTask`
  - `StateTask`
  - `StartProcessTask`
  - `EndProcessTask`
  - `OperationBinding.process`
  - `Process.getDataSources()`
  - `ScriptTask.getLanguage()`
  - `ScriptTask.getDataSources()`