The Stardust Engine provides AuditTrail partitioning and enactment of process definitions for multiple user domains. The functionalities are described in this chapter:
AuditTrail Partitions define logical distinct subset of data inside an audit trail. The extent of any partition is defined by a set of models associated with this partition and their transitive closure of model and runtime data. For example if three models Ma, Mb and Mc are deployed to an audit trail, and models Ma and Mb are associated with partition p1, the extent of p1 is defined by all rows inside model element tables referencing models Ma or Mb, and all rows inside runtime item tables transitively referencing rows from those model element tables as their defining model element. As any runtime item is uniquely associated with a model element and thus with a model, model elements and runtime items are uniquely associated with a partition, too, thus making partitions fully distinct.
Partitions will be created, modified and dropped via the sysconsole tool's auditTrail command, as described in the chapter The Sysconsole Command.
Please note that using the tuning property Carnot.Engine.Tuning.DB.singlePartition in multi partition audit trails will result in exceptions during queries. This property tells the engine that only one partition exists.
In addition to creating users at runtime, the administrator may create domains. A domain represents an organizational unit of an enterprise or an enterprise group.
Domains provide scoping rules for workflow participant resolution. They augment modeling time workflow participant resolution rules with runtime user segmentation. A domain per se defines a set of users. The cardinality between domains and users is *:*, so for example any domain can contain an arbitrary set of users, and any user may be associated with an arbitrary set of domains.
Additionally, domains may be associated with an arbitrary set of model participants. Model participant resolution semantics can optionally use domains as scope when resolving the set of valid users qualifying as performers for activities. For example there are users U1, U2 and U3. U1 and U2 are associated with domain D1, U1 and U3 are associated with domain D2. All three users are members of role R1. There are several possibilities to resolve R1:
Consideration of domains for participant resolution is a runtime decision. Domains cannot be shared between partitions and are unique within a partition.
A Stardust Runtime Environment always contains a default domain.
Any Workflow Model will be part of an audit trail. It is possible to deploy unrelated models to the same audit trail, but to different partitions. To get more information on deploying a Workflow Model refer to the chapter Deploying a Workflow Model of the Deployment Guide.
The model itself is directly associated with the partition it is deployed to via a foreign key into the partition table. Any model is associated with exactly one partition.
Model elements are not linked with their partition via a direct foreign key reference, but indirectly via their model OID.
Domains are unique only within a partition. Thus only a domain/partition pair identifies a domain uniquely.
Currently only one default domain per partition is supported. The ID of the default domain has by default the same ID as the partition.
Users are associated with exactly one partition, effectively rendering user member parts of partitions. Users may be associated with an arbitrary number of domains from their hosting partition. By default, they are associated with the partition's default domain.
A realm defines the uniqueness scope for user IDs. For example two users from the same realm are required to have different IDs and accounts respectively, while users from different realms are not.
Realms are associated with exactly one partition, effectively rendering realm member parts of partitions. Any user is associated with exactly one realm.
Realms will be created and dropped via the console tool's realm command, as described in the section Commands of the chapter Console.
It is possible to share users between partitions logically (i.e. user IDs). This could be achieved in different ways, for example:
Data Cluster operation will be restricted to Audit Trails containing only the default partition. This implies that the following validation rules will be added to the system: