In my current project we have the following list of requirements for one of our microservices:
Any object can have the list of custom validation rules and validation rules might differ between objects (it might even be that an object has the list of unique validation rules)
Those custom validation rules can be configured from UI by a user who created initial version of the object
Any time when some specific events happen with the object(changes and updates) we need to verify that the changes do not violate any of custom validation rules entered in the beginning
We also should have the list of standard checks like date range checks, number of some items and elements in the object
For now we are going to save all of this validation rules for objects either
as JSON object that will contain details of validation rule
or serialized Groovy object (*Validator)
In both cases it will be saved in database and used any time when it is needed to go throught the list of validations rules and execute them.
I am not sure that both options are the best and may be there are some other ways to implement it. Do you know any patterns or approaches that can help to implement custom validation rules?
Thank you
For custom validations implementation I'd suggest you to use Java validation API. It's very powerful in conjunction with validation groups.
You initialize beans / appropriate POJO instances based on the user inputs, and then simply call validations like: Validator.validate(T object, java.lang.Class... groups)
Related
Well I will explain all about my case.
Im trying to set up Azure alerts that sends a custom mails, to do so I need a logic app that parse the info about the said alerts.
The problem is, even if I enable the common alert schema, and fill the custom properties field, as you can see in the image.
But what this alert sends to my Logic App in the customProerties field is a Null value, I don't get why.
But more than that, if I disable the common alert schema, the custom properties field will be sent without problems.
I don't understand if common alert schema doesn't allow customProperties, or if Im doing something bad, I need help.
Thanks for read and ask for it if anything of this post is bad explained.
I have just confirmed this issue with Microsoft support.
If I point an Activity Log Alert Rule to an Action Group Webhook with Common Schema enabled then the Custom Properties don't appear in the JSON payload. If I disable the Common Schema then the property does appear in the payload.
If I do the same for a Metric alert or Log Query alert, the Custom Properties do appear at the Webhook endpoint regardless of whether the Common Schema is enabled or not.
Microsoft pointed that the schemas for each type are documented (no custom property on the Activity Log Common Schema) and that this is not a bug. Well... the Alert Rule form does allow to configure the Custom Properties for each type of alert so... ah well, nevermind.
They also said "There are plans to align the behaviour on all alert types including activity logs, although there is no definite ETA though. For now, the best option for you to be able to customize the payloads of activity log alerts is by using logic app as an action group."
I need to store the values of devices' attributes with the right type in OrionCB's MongoDB.
As I was unable to perform that I dived into the code and found that IoTAgentUL (as well as IoTAgentJSON) uses OrionCB's API v1 instead of API v2.
As I can see API v1's updateContext sends data to MongoDB without it's type, so every measure is stored as text.
In the other hand I found that API v2's update entity send data to MongoDB with it's type. It produces that I can store attribute's values with it's type which benefits me when manipulating data (i.e. creating indexes, sorting, etc).
My question is if is there any workaround to solve this using the current implementations of IoT Agents.
The only workaround I can imagine is, once entities are automatically created by the IoT Agents, to update the type of such entities by your own. I mean, AFAIK, you can update both the value and the type of an entity.
In more details, I can think on a script that subscribes for all entities of certain type (those created by the agents). Then, when an entity is created this is notified to the script, which automatically updates the type of the entity's attributes.
Please observe you only need to modify the attribute's types once, just when the entities are created, not when an entity's attribute is updated; thus, something like an array or cache of already modified entities is needed in your script.
We want to send some events to Application Insights with data showing which features a user owns, and are available for the session. These are variable, and the list of items will probably grow/change as we continue deploying updates. Currently we do this by building a list of properties dynamically at start-up, with values of Available/True.
Since AI fromats each event data as JSON, we thought it would be interesting to send through custom data as JSON so it can be processed in a similar fashion. Having tried to send data as JSON though, we bumped into an issue where AI seems to send through escape characters in the strings:
Eg. if we send a property through with JSON like:
{"Property":[{"Value1"},..]}
It gets saved in AI as:
{\"Property\":[{\"Value1\"},..]} ).
Has anyone successfully sent custom JSON to AI, or is the platform specifically trying to safeguard against such usage? In our case, where we parse the data out in Power BI, it would simplify and speed up a lot some queries by being able to send a JSON array.
AI treats custom properties as strings, you'd have to stringify any json you want to send (and keep it under the length limit for custom property sizes), and then re-parse it on the other side.
I'd like to create an Apigility REST service which accepts POSTs of, for example, a user object which has a field containing an array of address objects. I can define the field without validators and process the raw JSON in my code, but I'm wondering if there is a better way to do this where the nested objects can also be validated by Apigility?
Apigility has a module called content-validation -- it allows you to configure input filters for your services, and request data will be passed through the input filter for validation and an appropriate ApiProblem response is returned when validation fails. (see https://apigility.org/documentation/api-primer/content-validation)
That still leaves the onus on you to configure an input filter that will suit your needs.
I would check packagist.org for a JSON Schema validator library which can take a JSON schema and a JSON payload and verify that the payload is well formed according to the schema. Then you can easily implement a custom InputFilter and bind it to your services. This will give you validation that the main object and sub objects are well formed (ie: user has name, email, birth date and address field contains objects that all have address/street/zip/etc).
I want to set an arbitrary attribute for rendering to JSON.
I had followed the answer in this question: how to append data to json in ruby/rails? to do
model = Model.find
model[:extra_info] = "More detail."
model.to_json
It works perfectly, but in my tests I'm getting a deprecation warning that setting arbitrary attributes is no longer supported, use attr_writer.
I tried using
model.write_attribute(:extra_info, "More detail.")
which works in unit testing, but on the server, raises an exception:
private method `write_attribute' called for Model
What's the non-deprecated clean way to do this.
I'm aware I could set it in the JSON call with methods as in Add virtual attribute to json output, but in this case the variable to be added is not part of the models concern, so it doesn't have access to the data needed to construct the extra attribute, and it would be nasty and messy to do so.
So what's the correct way for the controller to get this data pushed into the model so the JSON renders properly?
In Model model, put
attr_accessor :extra_info
Then in controller
model.extra_info = "more detail"
Nick's answer above is the best in terms of creating well structured, well documented code.
Update
*It seems I was wrong on the below*
The code below still creates deprecation warnings on my development server.
In this particular case, I don't want to clutter the model up with extra accessors for very specific once off cases, so I'm using
s.send(:write_attribute, :extra_info, "more detail")
Inside a helper, inside the controller.