-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rules engine refactoring #1037
Rules engine refactoring #1037
Conversation
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/Rule.java
Outdated
Show resolved
Hide resolved
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/ValidationRule.java
Fixed
Show fixed
Hide fixed
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/ValidationRule.java
Fixed
Show fixed
Hide fixed
Added dummy definitions from design discussion
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/RuleLoader.java
Fixed
Show fixed
Hide fixed
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/RuleLoader.java
Fixed
Show fixed
Hide fixed
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/RuleEngine.java
Fixed
Show fixed
Hide fixed
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/RuleLoader.java
Fixed
Show fixed
Hide fixed
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/ValidationRuleEngine.java
Fixed
Show fixed
Hide fixed
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/ValidationRuleEngine.java
Fixed
Show fixed
Hide fixed
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/ValidationRuleEngine.java
Fixed
Show fixed
Hide fixed
Fix method names
Updated one of the failing tests
Use double checked locking on ensureRulesloaded
Update more test cases
All tests pass
…/CDCgov/trusted-intermediary into story/1024/transformation-engine
Update tests to work with refactoring changes
…/CDCgov/trusted-intermediary into story/1024/transformation-engine
...src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/validation/ValidationRule.java
Fixed
Show fixed
Hide fixed
Added test-case for base Rule class exclusive implementation.
Quality Gate passedIssues Measures |
etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/orders/OrderController.java
Show resolved
Hide resolved
@@ -133,7 +133,9 @@ public Map<HttpEndpoint, Function<DomainRequest, DomainResponse>> domainRegistra | |||
PartnerMetadataConverter.class, HapiPartnerMetadataConverter.getInstance()); | |||
// Validation rules | |||
ApplicationContext.register(RuleLoader.class, RuleLoader.getInstance()); | |||
ApplicationContext.register(RuleEngine.class, RuleEngine.getInstance()); | |||
ApplicationContext.register( | |||
ValidationRuleEngine.class, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first value in register should be an interface and the second should be the class that is defining the behavior for an interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As commented above, we need to be able to identify two different implementations of the rule engine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on doing a parent interface (RuleEngine), and two child interfaces that will extend the parent interface (ValidationRuleEngine, TransformationRuleEngine)? With this setup, you can use the child interface to register the implementation for each (ValidationRuleEngineImp, TransformationRuleEngineImp). The only challenge here is the naming for the parent interface, the child interfaces, and the implementations for each child interface. You register both engines with a unique interface for each.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the value we register in the ApplicationContext needs to be an interface, a lot of the existing ones are not. Is there a benefit in creating the interface even if it will have only one implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we generally wrap 3rd party dependencies in an interface to reduce dependencies
|
||
/** | ||
* Descriptive message when there's a rule violation Note: When implementing this method, make | ||
* sure that no PII or PHI is included in the message! | ||
* Do not delete this constructor! It is used for JSON deserialization when loading rules from a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, Jackson requires an empty constructor to de-serialize things, don't have to add this but something to think about
Rules engine refactoring
Refactoring to make validation rule engine code more generic and reusable for the transformation rule engine
Issue
#1024
Checklist