Skip to content
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

Merged
merged 36 commits into from
May 3, 2024
Merged

Rules engine refactoring #1037

merged 36 commits into from
May 3, 2024

Conversation

basiliskus
Copy link
Contributor

@basiliskus basiliskus commented Apr 23, 2024

Rules engine refactoring

Refactoring to make validation rule engine code more generic and reusable for the transformation rule engine

Issue

#1024

Checklist

  • I have added tests to cover my changes
  • I have added logging where useful (with appropriate log level)
  • I have added JavaDocs where required
  • I have updated the documentation accordingly

@basiliskus basiliskus changed the title Transformation rules engine implementation Rules engine refactoring Apr 26, 2024
@basiliskus basiliskus marked this pull request as ready for review April 29, 2024 18:35
basiliskus and others added 2 commits April 29, 2024 16:28
Added test-case for base Rule class exclusive implementation.
Copy link

@@ -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,
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor

@jorg3lopez jorg3lopez May 1, 2024

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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
Copy link
Contributor

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

@basiliskus basiliskus merged commit 32abaaf into main May 3, 2024
16 checks passed
@basiliskus basiliskus deleted the story/1024/transformation-engine branch May 3, 2024 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants