A new update for TMS BIZ products has been released today. It's the third update in the last three months - yep, we are working hard on it, as usual.

You can check in details the latest improvements in the following links:

• TMS Aurelius release notes.
• TMS XData release notes.
• TMS Sphinx release notes.
• TMS Sparkle release notes.
• TMS RemoteDB release notes.
• TMS Scripter release notes.

But in this blog post I want to focus on a nice improvement in TMS XData: automatic validation parameters for service operations.

You can now apply validation attributes to parameters and DTO classes to make sure you receive parameters and classes with the expected values. This saves you from needing to manually add validation code and returning error messages to the clients.

For example:

  [ValidateParams]
  [HttpGet] function ListCitiesByState(const [Required, MaxLength(2)] State: string): TList<TCity>;

The method above adds validation attributes Required and MaxLength to the State parameter. If a client invokes the endpoint without providing the State parameter, or passing it as empty (null string), or even passing a value longer than 2 characters, XData will reject the request and answer with a status code 400. Also a detailed error message will be provided for the client in JSON format in request body indicating what's wrong and what should be fixed.

When implementing your method, you can safely rely that the State parameter will have the valid value and won't need to worry about checking for wrong values.

When a parameter is a class, then the object itself will also be validated, i.e., all the mapped members will also have the validation attributes applied:

  TFoo = class
  strict private
    [Range(1, MaxInt)] FId: Integer;
    [MaxLength(10)] FName: string;
  public
    property Id: Integer read FId write FId;
    property Name: string read FName write FName;
  end;

{...}

  [ValidateParams] procedure AcceptFoo([Required] Foo: TFoo);

In the above example, when AcceptFoo is invoked, XData will apply the Required validation to it. If Foo is nil, the request will be rejected. But also, even if Foo object is provided, the request will only be accepted if the Id property is positive, and Name property is not longer than 10 characters.

For example, if the following JSON is sent to the endpoint:

{
    "Id": 0,
    "Name": "ABCDEFGHIJKL"
}

The endpoint will answer with a 400 Bad Request response including the following detailed content:

{
    "error": {
        "code": "ValidationFailed",
        "message": "Validation failed",
        "errors": [
            {
                "code": "OutOfRange",
                "message": "Field Id must be between 1 and 2147483647"
            },
            {
                "code": "ValueTooLong",
                "message": "Field Name must have no more than 10 character(s)"
            }
        ]
    }
}

For the complete reference of available validation attributes, please refer to the Data Validation chapter in TMS Aurelius documentation.

Data validation is a powerful feature of TMS BIZ, and applies to both XData parameters and DTO classes, and Aurelius entities. Stay tuned for upcoming updates - many more to come in near future!

And, while I have you here, are you aware of our Training Days 2023 event? A great event to learn more about TMS libraries and Delphi development, for both beginner and advanced developers, and with plenty of opportunities for networking and direct contact with our team members and other users. I will be there!

TMS Training Days 2023 will happen on May 11th and 12th in Bruges, and we hope to see you there. 

Click here to visit the TMS Training Days 2023 web site to learn more and and register for the event!

(*) Photo by Laura Ockel on Unsplash