A command asks Open BPM to act
A command is a request for an authorised change. A request to create rebooking work should identify the request itself, the person or system making it, the business record, the required result, responsible role and deadline.
Open BPM should accept or refuse the command explicitly. If delivery fails and the sender retries the same request, the request identifier lets the component return the original result instead of creating duplicate work.
An event reports what Open BPM accepted
An event reports an accepted fact such as a work item being created, claimed, released, completed or escalated. It identifies the work, accepted change, actor, time and the request that caused it.
A correlation identifier links related requests, events and work history so support staff can follow one journey across components. Internal debugging messages do not automatically become public events.
A rule returns a decision
A priority rule receives defined input facts and returns a decision, rule version and an explanation for that decision. Open BPM records the rule version, inputs and result needed to explain the work change.
cREXX is the proposed first rule language because its compiler and execution tools already exist. The Open BPM connection and surrounding controls for rule identity, activation, permissions and failure have not been built.
Add standards only with precise mappings
Workflow, case and decision standards are useful reference points. Interface and event-description standards may also help describe particular interactions. Open BPM should claim a mapping or supported subset only after the relevant examples and tests exist.
The first contract can remain small. A precise create-work command and work-created event are more useful than a broad compatibility claim with no working implementation.