Diagram - Sequence Basics

#Usage

This component accepts an initial Sequence model and its page ID. Supply the records shown in a demo below. Copy the preset inspector files to the local import path and follow Setup for application styles and licensing.

<script setup lang="ts">
import { onBeforeUnmount } from 'vue';
import { Diagram, createDiagramStore, DiagramSymbolRegistry, type DiagramModel } from '@primeui/vue-diagram';
import { DiagramSequenceRoot, createDiagramSequenceModule, createDiagramSequenceSymbols } from '@primeui/vue-diagram/sequence';
import { DiagramSequenceInspectorUI } from './components/primeui/diagram/sequence';

const props = defineProps<{ model: DiagramModel; pageId: string }>();
const created = createDiagramStore(props.model, { notationModules: [createDiagramSequenceModule()] });
if (!created.ok) throw new Error(created.diagnostics.map((item) => item.message).join('; '));
const store = created.value;

const symbols = new DiagramSymbolRegistry();
for (const symbol of createDiagramSequenceSymbols()) symbols.register(symbol);

onBeforeUnmount(() => {
    symbols.dispose();
    store.dispose();
});
</script>

<template>
    <Diagram.Root :store="store" :page-id="pageId" :symbols="symbols">
        <DiagramSequenceRoot>
            <Diagram.Viewport label="Sequence model" auto-fit style="height: 30rem" />
            <DiagramSequenceInspectorUI />
        </DiagramSequenceRoot>
    </Diagram.Root>
</template>

The model is read once during setup. For file loading or Reset, replace the store deliberately and dispose the previous caller-owned store. The root owns its session. The copied inspector follows selection and creates its own DiagramSequenceInspectorHost; a custom form uses that host with useDiagramSequenceInspector() in a child component. Its snapshots are readonly refs. Read .value in setup and use the documented actions to change drafts or selections. Mounting a form does not install the notation module.

Use Sequence to describe an exchange between participants. The sd frame is the Interaction authority, separate from the page. Positions and heights are drawing coordinates, not elapsed time. Each lifeline holds explicit local occurrence order; there is no total Interaction order or execution engine.

#Start with a small exchange

Choose Focus submit, then use Edit selected element. Customer is an Actor participant and Orders is an Object participant. Submit is a synchronous call; accepted explicitly names that call in replyTo. Select a participant to edit its name/type/profile or select a message to edit its description and endpoints. Undo restores a complete edit. Read only keeps selection, Fit and inspection usable; Restart example restores the original snapshot with empty history.

The fixture uses public editor actions to construct reciprocal identities and projected geometry, then returns the finished model for a fresh enabled store. Construction resources are disposed. The mounted example owns and disposes its store and registry when replaced/destroyed.

#Bind messages and activations to occurrences

The Process activation uses the submit receive and accepted send occurrences as its start and finish. Choose an asynchronous sort and Add asynchronous message. Add standalone activation creates an activation with its own execution-boundary occurrences. Each Add action offers one specimen at a deliberate position. Undo each addition independently, or Restart, to make that specimen available again. Try reply before call attempts a separate reply whose two occurrences precede submit. It rejects without changing the accepted reply, Process activation or model history. Try rotation rejects because Sequence records remain upright.

An activation is descriptive execution notation, not a running function. It names one lifeline and stable start/finish IDs in one scope, with nondecreasing positions. A standalone atomic activation may share one boundary ID for start and finish. offset is a visible overlap lane from 0 through 8; overlapping/atomic executions on the same lifeline require distinct offsets unless their scopes are mutually exclusive alternative operands.

Every message has kind: 'message', interactionId, scopeId, sort, name, arguments, reciprocal sendId/receiveId and optional replyTo. Arguments are inert text, not evaluated values. A bound reply reverses the call's lifelines and follows that call. Reply/call scopes cannot be mutually exclusive alt operands.

#Describe creation and destruction

Open creates Orders; its visible participant header belongs at that scoped creation. Close is its destruction. Move work message updates the same send/receive occurrences and arguments. Try message after destruction rejects a later event on the ended lifeline. Undo restores the former positions with the same identities.

Each lifeline has at most one creation and destruction in each enclosing scope. Creation receive is first locally; destruction is final locally. Other occurrences and activations fit the scoped lifetime and visible creation-header clearance. Sibling alt branches have independent local lifetimes, so a creation/destruction in one branch does not truncate another branch or the root lifeline authority.

Messages run horizontally or downward. A self-message uses two distinct ordered occurrences separated by at least 16 drawing units. Distinct occurrences on the same lifeline and scope have strictly increasing drawing positions. Generic connector geometry does not author these identities: use the semantic editor to change the message or its occurrences so labels, ports and routes agree.

#Identity and ownership reference

Every owned record names an actual Interaction and its enclosing Interaction or operand scope. Visual parent and layer/page agree with that semantic owner. A node ID, a lifeline ID, an occurrence ID and its physical port ID are separate identities; changing a friendly name must not allocate replacements. IDs use the 128-character alphanumeric plus _ . : - syntax. Names/type text are at most 128 characters, message arguments at most 512. Omit unset optional fields. Unknown properties, unsupported versions or unresolved active payloads require explicit repair.

#Editing API and form ownership

Semantic Sequence edits use the shared connection/notation operation path, including approval, veto and controlled acknowledgement, and produce one complete history operation. Undo/Redo recheck current permissions. A rejection preserves the graph; a noop adds no edit, and pending belongs to the live store/connection owner. Copied forms keep draft fields separate from saved records and reconcile them when ownership or selection changes.

See Sequence fragments for alt/loop, nested operand membership and self-contained reuse. Gates, found/lost messages, general ordering constraints, timed traces, arbitrary rotation and executable Interaction behavior are outside this profile.

#Related Docs

• Choose a Notation
• Supported Profiles
• API