You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 22, 2019. It is now read-only.
CDO transactions spport transacation handlers. NFS transaction context provider component collects transaction handler services and adds them to transactions it creates. It all allows declarative listening for changes about to be committed to the repository. Changes are fine-grained - at the feature level. Rules can be added to the NFS-based system by, say, creating a rules component which would collect rules from extensions and expose a transaction handler service firing rules. Extension point definition shall allow to link rules to object EClass and, optionally, a feature name. Rules chaining can be implemented using a number of ways, including another extension point which defines rule implementation class and types of input facts. Fact correlation queues can be stored in the repository, e.g. in a resource dedicated for storing rules structures, and as such correlations will survive JVM restart.
Decision tables can be implemented as an ecore model populated using sirius edition tables.
Hot deployment can be done with p2.
Rule configuration can be saved in the repository.
CDO transactions spport transacation handlers. NFS transaction context provider component collects transaction handler services and adds them to transactions it creates. It all allows declarative listening for changes about to be committed to the repository. Changes are fine-grained - at the feature level. Rules can be added to the NFS-based system by, say, creating a rules component which would collect rules from extensions and expose a transaction handler service firing rules. Extension point definition shall allow to link rules to object EClass and, optionally, a feature name. Rules chaining can be implemented using a number of ways, including another extension point which defines rule implementation class and types of input facts. Fact correlation queues can be stored in the repository, e.g. in a resource dedicated for storing rules structures, and as such correlations will survive JVM restart.
Decision tables can be implemented as an ecore model populated using sirius edition tables.
Hot deployment can be done with p2.
Rule configuration can be saved in the repository.
EContentAdapter can be used instead of transaction handlers to fire rules, see example
The text was updated successfully, but these errors were encountered: