Question

client side human service

Answer 1

A client-side human service (CSHS) is the BAW artifact that defines a user interface: its diagram runs in the browser (coaches, client-side scripts, decisions), and it calls the server only when it hits a service flow (server-side logic, integrations, data) or when the task is completed. Key facts:

• The flow between coaches executes in the browser - no server round trip for navigation, validation or scripting; this is why CSHS feels faster than heritage human services (where every step ran on the server).
• Data is held in tw.local in the browser; only when a service flow is called or the task ends is it sent to the server.
• Elements: Coach, Client-side script, Service flow call (nested), Decision, Stay-on-page events, Postpone / End, Error events, Timers are not available (use a UI timer control).
• Exposure: as a task implementation of a BPD activity, as a startable service (URL / portal tile), as a dashboard, or as an administration service.
• Toolkit: coaches are built from UI Toolkit (Spark) coach views and custom coach views.

// client-side script inside a CSHS (browser): validation before a coach
if (!tw.local.order || !tw.local.order.lines || tw.local.order.lines.length === 0) {
  tw.local.message = "Add at least one line";
  tw.local.valid = false;
} else { tw.local.valid = true; }
// -> Decision gateway on tw.local.valid: back to the coach or on to the "Save order" service flow

Compared with a service flow: a service flow has no coaches and runs entirely on the server (server scripts, Java, REST, SQL); a CSHS orchestrates coaches and calls service flows. Compared with a heritage human service: HHS run on the server with heritage coaches and are deprecated.

References

• BAW documentation - client-side human services
• BPM UI Toolkit