Open topic with navigation

TIBCO BusinessEvents® Enterprise Edition 6.3.1

# Containment and Reference Concept Relationship Rules

Containment and Reference Concept Relationship Rules
Containment One concept is contained in another | Reference One concept points to another
--- | ---
Designtime Rules
One container concept can contain multiple different contained concepts, and a contained concept can itself also act as a container concept. One referring concept (that is, the concept that has the `ConceptReference` property) can have a reference relationship with multiple referenced concepts, and a referenced concept can also refer to other concepts.
A container concept can link to a contained concept using only one `ContainedConcept` p`roperty`. (Some other object-oriented languages do allow you to reuse object types in parent object properties.) | A referring concept links to a referenced concept using multiple `ConceptReference` properties. (That is, multiple `ConceptReference` properties can reference the same referenced concept.)
A contained concept can have only one container concept. | A referenced concept can be referred to by multiple referring concepts
Runtime Rules
When one contained instance is replaced with another: TIBCO BusinessEvents automatically deletes the instance that it replaced. You do not have to delete the replaced instance explicitly. | When one referenced instance is replaced with another: TIBCO BusinessEvents does not delete the instance that it replaced automatically. It may not be appropriate to delete the referenced instance. If you want to delete the referenced instance, do so explicitly.
When a contained instance is modified: The container instance is also considered to be modified. The reasoning can be seen by a simple example: a change to the wheel of a car is also a change to the car. Rules that test for modified instances would return the `Car` concept instance as well as the `Wheel` concept instance. | When a referenced instance is modified: The referring instance is not considered to be modified. The reasoning can be seen by a simple example: a change to the support contract for a customer is not a change to an order that references that customer.
When a container instance is asserted or deleted: The contained instance is also asserted or deleted, along with any other contained instances at lower levels of the containment hierarchy. | When a referring instance is asserted or deleted: The referenced instance is `not` also asserted or deleted.

See the provided Containment Example.

Did you find this helpful?

YesNo
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO BusinessEvents® Enterprise Edition

Copyright © 2004-2024. Cloud Software Group, Inc. All Rights Reserved.