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
• auth.userId: Authenticated user ID (from DSRequest.getUserId())
• auth.roles: User roles (from DSRequest.getUserRoles())

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

ServerDynamicCriteria in Process Workflows

DecisionTask and MultiDecisionTask criteria support the full ServerDynamicCriteria syntax, including:

• Authentication context: auth.userId, auth.roles
• Request context: context.operationType, context.operationId
• Relational FK references: dotted RelatedDS.fieldName references are resolved automatically via the foreign key chain defined in the DataSource. For example, if an Order DS has foreignKey="Customer.customerId", a criterion with fieldName="Customer.creditStatus" fetches the related Customer record and checks its creditStatus field
• Aggregation shorthand: ChildDS.#count and ChildDS.field.#sum compute aggregates over related child records. For example, if an Order DS has child LineItem records linked by FK, LineItem.#count resolves to the number of line items and LineItem.amount.#sum resolves to their total amount

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. When autoJoinTransactions is enabled, all DS*Tasks in the process (including DSAddTask, DSUpdateTask, DSRemoveTask, and DefaultOperationTask) share the same database connection, so they commit or roll back as a unit.

Server-Side Task Compatibility

Compatible server-side tasks: DefaultOperationTask, DecisionTask, MultiDecisionTask, ScriptTask, DSFetchTask, DSAddTask, DSUpdateTask, DSRemoveTask, StartProcessTask, EndProcessTask, StateTask.

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.

Example

An Order DataSource with a foreign key to a Customer DataSource. On add, the process checks whether the customer's credit is approved (SDC relational FK reference) and rejects if not. If approved, a ScriptTask sets the status and a DefaultOperationTask persists the record.