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

ApproachBest ForEditable?
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: