Business logic

All business objects in the Multivers API depend on business logic. Business logic includes all business rules, data validation, manipulation, processing, and authorization for the application. One definition from Microsoft is as follows:

The combination of validation edits, login verifications, database lookups, policies, and algorithmic transformations that constitute an enterprise’s way of doing business.

Business rules

Business logic is realized by business rules. A business rule implements a part of the business logic, business rules are used to validate input, automatically load default values, authorize actions and more. Each property of each business object can be associated with zero or more business rules. Business rules are automatically run when creating a business object or modifying existing properties on a business object. Not all properties have business rules associated with them, but many do. For example ensuring that required fields have a value is done by business rules.

Broken rules

Each response from the WebAPI contains a messages property. This property contains an array of messages that describe wich rules are broken. Below is an example of a response when the ShortName value for a customer is empty.

    {
        "messages": [
            {
                "message": "ShortName is verplicht.",
                "messageType": "Error",
                "path": "/shortName"
            }
        ]
    }
    

As seen in the JSON code above a message exists out of a text, a type and a path. The message property is a text describing the rule that is broken and the type explains the severity of the problem. This value can be either Error, Warning or Info. The last property is the path. It can be used to determine on wich property the rules breaks. The following structures are possible for the path:

Description	Path
Root	/
Property	/name
Item of array	/children/0
Property of item of array	/children/0/name

The casing of these paths is based on the format that is being used. For JSON it will be camel casing and XML uses pascal casing.

Exceptions

Exceptions are also given in the messages format. It works the same way as the other messages but it includes an exceptionId property. The following is an example

    {
        "messages": [
            {
                "exceptionId": "232eb043-c5f3-406f-9e5c-7ef0047d5710",
                "message": "Error ocurred....",
                "messageType": "Error",
                "path": "/"
            }
        ]
    }