Glossary
Governance
repository
A back-end storage entity containing all the data managed by TIBCO EBX®. The repository is organized into dataspaces.
See also dataspace.
profile
The generic term for a user or a role. Profiles are used in data workflows and for defining permission rules.
Related Java API Profile.
user
An entity created in the repository in order for physical users or external systems to authenticate and access EBX®. Users may be assigned roles and have other account information associated with them.
See also user and roles directory, profile.
Related concept User and roles directory.
Related Java API UserReference.
role
A user classification, used for permission rules and data workflows, which can be assigned to users. Each user may belong to multiple roles.
Whenever a role profile is specified in EBX®, the behavior resulting from that designation is applied to all users that are members of that role. For example, in a workflow model, a role may be specified when defining to whom work items are offered. As a result, all users belonging to that role can receive the same work item offer.
See also user and roles directory, profile.
Related concept User and roles directory.
Related Java API Role.
administrator
A predefined role that has access to the technical administration and configuration of EBX®.
user and roles directory
A directory defining the methods available for authentication when accessing the repository, all available roles, and the users authorized to access the repository with their role assignments.
Related concept User and roles directory.
Related Java API Directory, DirectoryHandler.
user session
A repository access context that is associated with a user after being authenticated against the user and roles directory.
Related concept User and roles directory.
Related Java API Session.
Data modeling
Main documentation section Data models
data model
A structural definition of the data to be managed in the EBX® repository. A data model includes detailed descriptions of all included data, in terms of organization, data types, and semantic relationships. The purpose of data models is to define the structure and characteristics of datasets, which are instances of data models that contain the data being managed by the repository.
See also dataset.
Related concept Data models.
field
A data model element that is defined with a name and a simple datatype. A field can be included in the data model directly or as a column of a table. In EBX®, fields can be assigned basic constraints, such as length and size, as well as more complex validation rules involving computations. Automated value assignment using field inheritance or computations based on other data can also be defined for fields. Aggregated lists can be created by setting the cardinality of a field to allow multiple values in the same record. Fields can be arranged into groups to facilitate structural organization in the data model.
By default, fields are denoted by the icon 
.
See also record, group, table (in data model), validation rule, inheritance.
Related concepts Structure elements properties, Controls on data fields.
Related Java API SchemaNode.
The former name (prior to version 5) of "field" was "attribute".
primary key
A field or a composition of multiple fields used to uniquely identify the records in a table.
Primary keys are denoted by the icon 
.
Related concept Tables definition.
foreign key
A field or a composition of multiple fields in one table whose field values correspond to the primary keys of another table. Foreign keys are used to reference records in one table from another table.
Foreign keys are denoted by the icon 
.
See also primary key.
Related concept Foreign key.
table (in data model)
A data model element that is comprised of fields and/or groups of fields. Every table must define at least one field to act as the unique identifier, or primary key, of records. A table in a data model can be used to create a reusable type based on the table's structure, which can then be used to create other elements of the same structure in the data model.
Tables are represented by the icon 
.
See also record, primary key, reusable type.
group
A classification entity used to facilitate the organization of a data model. A group can be used to collect fields, other groups, and tables. If a group contains tables, the group cannot be included within another table, as the constraint that tables cannot be nested must be respected. A group can be used to create a reusable type based on the group's structure, which can then be used to create other elements of the same structure in the data model.
Groups are represented by the icon 
.
See also reusable type.
Related Java API SchemaNode.
reusable type
A shared simple or complex type definition that can be used to define other elements in the data model.
validation rule
An acceptance criterion defined on a field or a table. Data is considered invalid if it does not comply with all imposed validation rules.
The former name (prior to version 5) of "validation rule" was "constraint".
data model assistant (DMA)
The EBX® user interface includes a tool that aids the implementation of data models. It allows defining the structure of data models, creating and editing elements, as well as configuring and publishing data models.
See also Data models.
Datasets
Main documentation section Datasets
record
A set of field values in a table, uniquely identified by a primary key. A record is a row in the table. Each record follows the data structure defined in the data model. The data model drives the data types and cardinality of the fields found in records.
See also table (in dataset), primary key.
The former name (prior to version 5) of "record" was "occurrence".
table (in dataset)
A set of records (rows) of the same structure containing data. Each record is uniquely identified by its primary key.
Tables are represented by the icon .
See also record, primary key.
dataset
A data-containing instance of a data model. The structure and behavior of a dataset are based upon the definitions provided by the data model that it is implementing. Depending on its data model, a dataset contains data in the form of tables, groups, and fields.
Datasets are represented by the icon 
.
See also table (in dataset), field, group, views.
Related concept Datasets.
The former name (prior to version 5) of "dataset" was "adaptation instance".
inheritance
A mechanism by which data can be acquired by default by one entity from another entity. In EBX®, there are two types of inheritance: dataset inheritance and field inheritance.
When enabled, dataset inheritance allows a child dataset to acquire default data values from its parent dataset. This feature can be useful when designing a data model where data declared in a parent scope will be used with the same value by default in nested child scopes. Values that are inherited from the parent can be overridden by the child. By default, dataset inheritance is disabled. It can be enabled during the data model definition.
Inheritance from the parent dataset is represented by the icon 
.
Field inheritance is defined in the data model to automatically fetch a field value from a record in another table.
Inherited fields are represented by the icon 
.
Related concept Inheritance and value resolution.
views
A customizable display configuration that may be applied to viewing tables. A view can be defined for a given user or role, in order to specify whether records are displayed in a tabular or hierarchical format, as well as to set record filtering criteria.
The hierarchical view type offers a tree-based representation of the data in a table. Nodes in the tree can represent either field values or records. A hierarchical view can be useful for showing the relationships between the model data. When creating a view that uses the hierarchical format, dimensions can be selected to determine the structural representation of data. In a hierarchical view, it is possible to navigate through recursive relationships, as well as between multiple tables using foreign key relationships.
See also
recommended view
A recommended view can be defined by the dataset owner for each target profile. When a user logs in with no view specified, their recommended view (if any) is applied. Otherwise, the default view is applied.
The 'Manage recommended views' action allows defining assignment rules for recommended views depending on users and roles.
Related concept Recommended views.
favorite view
When displaying a table, the user can choose to define the current as their favorite view through the 'Manage views' sub-menu.
Once it has been set as the favorite, the view will be automatically applied each time this user accesses the table.
Related concept Manage views.
Data management life cycle
Main documentation section Dataspaces
dataspace
A container entity comprised of datasets. It is used to isolate different versions of datasets or to organize them.
Child dataspaces may be created based on a given parent dataspace, initialized with the state of the parent. Datasets can then be modified in the child dataspaces in isolation from their parent dataspace as well as each other. The child dataspaces can later be merged back into their parent dataspace or compared against other dataspaces.
See also inheritance, repository, dataspace merge.
Related concept Dataspaces.
The former name (prior to version 5) of "dataspace" was "branch" or "snapshot".
reference dataspace
The root ancestor dataspace of all dataspaces in the EBX® repository. As every dataspace merge must consist of a child merging into its parent, the reference dataspace is never eligible to be merged into another dataspace.
See also dataspace, dataspace merge, repository.
dataspace merge
The integration of the changes made in a child dataspace since its creation into its parent dataspace. The child dataspace is closed after the merge has completed successfully. To perform a merge, all the differences identified between the source dataspace and the target dataspace must be reviewed, and conflicts must be resolved. For example, if an element has been modified in both the parent and child dataspace since the creation of the child dataspace, the conflict must be resolved manually by deciding which version of the element should be kept as the result of the merge.
Related concept Merge.
snapshot
A static copy of a dataspace that captures its state and all of its content at a given point in time for reference purposes. A snapshot may be viewed, exported, and compared to other dataspaces, but it can never be modified directly.
Snapshots are represented by the icon 
.
Related concept Snapshot
The former name (prior to version 5) of "snapshot" was "version" or "home".
History
Main documentation section History
historization
A mechanism that can be enabled at the table level to track modifications in the repository. Two history views are available when historization is activated: table history view and transaction history view. In all history views, most standard features for tables, such as export, comparison, and filtering, are available.
Activation of historization requires the configuration of a history profile. The historization of tables is not enabled by default.
See also table history view, transaction history view, history profile.
history profile
A set of preferences that specify which dataspaces should have their modifications recorded in the table history, and whether transactions should fail if historization is unavailable.
See also history profile.
table history view
A view containing a trace of all modifications that are made in a given table, including record creations, updates, and deletions. Each entry includes transactional information, such as a timestamp and the user performing the action, as well as the data at the conclusion of the transaction. This information can also be consulted at a record or dataset level.
Related technical reference History.
transaction history view
A view displaying the technical and authentication data of transactions, either globally at the repository level, or at the dataspace level. As a single transaction can perform multiple actions and affect multiple tables in one or more datasets, this view shows all the modifications that have occurred across the given scope for each transaction.
Related technical reference History.
Workflow modeling
Main documentation section Workflow models
workflow model
A procedural definition of operations to be performed on data. A workflow model describes the complete path that the data must follow in order to be processed, including its states and associated actions to be taken by human users and automated scripts.
Related concept Workflow models.
The former name (prior to version 5) of "workflow model" was "workflow definition".
Workflow models are represented by the icon 
.
script task
A data workflow task performed by an automated process, with no human intervention. Common script tasks include dataspace creation, dataspace merges, and snapshot creation.
Script tasks are represented by the icon 
.
See also workflow model.
user task
A data workflow task that is made up of one or more work items performed concurrently by human users. User task work items are offered or assigned to users, depending on the workflow model. The progression of a data workflow beyond a user task depends on the satisfaction of the task termination criteria defined in the workflow model.
User tasks are represented by the icon 
.
See also workflow model.
workflow condition
A decision step in a data workflow. A data workflow condition describes the criteria used to decide which step will be executed next.
Workflow conditions are represented by the icon 
.
sub-workflow invocation
A step in a data workflow that pauses the current data workflow and launches one or more other data workflows. If multiple sub-workflows are invoked by the same sub-workflow invocation step, they will be executed concurrently, in parallel.
wait task
A step in a data workflow that pauses the current workflow and waits for a specific event. When the event is received, the workflow is resumed and automatically goes to the next step.
data context
A set of data that may be shared between steps throughout a data workflow to ensure continuity between steps.
Data workflows
Main documentation section Data workflows
workflow publication
An instance of a workflow model that has been made available for execution to users with the appropriate permissions.
The former name (prior to version 5) of "workflow publication" was "workflow".
data workflow
An executed instance of a workflow model, which runs the data processing steps that are defined in the model, including user tasks, script tasks, and conditions.
See also workflow model.
Related concept Data workflows.
The former name (prior to version 5) of "data workflow" was "workflow instance".
work list
A list of all published data workflows that the current user has the permissions to view. Users with the permissions to launch data workflows do so from their 'Work List'. All outstanding work items requiring action from the user appear under their published workflows in the work list. Additionally, if the user is the administrator of data workflows, they are able to view the state of execution of those data workflows in their 'Work List', and may intervene if necessary.
work item
An action that must be performed by a human user as a part of a user task.
Allocated work items are represented by the icon 
.
See also user task.
token
Tokens are used during data workflow management, and are visible to repository administrators.
Data services
Main documentation section Data services
data service
EBX® shares master data according to the Service-oriented architecture (SOA) by using XML web services. Since all data services are generated directly from models or built-in services they can be used to access part of the features available from the user interface.
Data services offer:
a WSDL model-driven and built-in generator to build a communication interface. It can be produced through the user interface or the HTTP(S) connector for a client application. XML messages are communicated to the EBX® entry point.
a SOAP connector or entry point component for SOAP messages which allows external systems interacting with the EBX® repository. This connector responds to requests coming from the WSDL produced by EBX®. This component accepts all SOAP XML messages corresponding to the EBX® WSDL generator.
A RESTful connector, or entry point for the select operations, allows external systems interrogating the EBX® repository. After authenticating, it accepts the request defined in the URL and executes it according to the permissions of the authenticated user.
lineage
A mechanism by which access rights profiles are implemented for data services. Access rights profiles are then used to access data via WSDL interfaces.
Related concept: Generating a WSDL for lineage.
Cross-domain
node
A node is an element of a tree view or a graph. In EBX®, 'Node' can carry several meanings depending on the context of use:
In the workflow model context, a node is a workflow step or condition.
In the data model context, a node is a group, a table or a field.
In the hierarchy context, a node represents a value of a dimension.
In an adaptation tree, a node is a dataset.
In a dataset, a node is the node of the data model evaluated in the context of the dataset or the record.
User guide table of contents