Versions Compared

Old Version 1

changes.mady.by.user Frank van der Vaart

Saved on

compared with

New Version Current

changes.mady.by.user Tijmen Daatselaar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

You start with an entity (2) that represents the begin and the end of the message. For every attribute/relation (3) you can select a name (4), what datatype (5) it is, if it is required (6) to be part of the message, if it is multivalued (7) and any additional documentation (8) that will be part of the Swagger feed. It is also possible to add validation rules types on the value (9).

Info
  • When you add the right column of the domain schema first, the left column will be prefilled with a copy of the name from the right column. When editing the left column then it is "user-set" and the automatic copy function will be disabled.
  • When an attribute or relation is selected, the fields on the right side of the screen are prefilled using the information of the attribute or relation. You may deviate from this chosen setting.
  • The validations can only be a validation type. It is not possible to use validation rules.
  • When optional elements of the messages are left out, the parser will set the value unknown for them. This is the same for NULL values in JSON.
  • When generating a JSON message, unknown values will be mapped to NULL. However, the element will be left out completely when the attribute is not required and the value is not user-set.
Note

A domain schema is case sensitive. The attribute in the right-hand column typically contains one or more uppercase characters (the use of CamelCase is a modeling guideline). This is copied to the left-hand column as a suggestion for the incoming attribute name. If the incoming response has the same attribute name, but not the exact same casing, this attribute is not found in the domain schema and the mapping won't work. This can be a problem that is easily overlooked.

Note

You can make translations between message and your application domain. For example, it is possible to store a single-valued attribute in the message in a multi-valued attribute in your application domain. You have to be aware that you can only make a translation into a more general data type. For example the other way is not possible. When sending a message, it is not possible to place a multivalued attribute of your application domain in a single valued attribute of the domain schema.


Anchor
ExampleJSONFormat
ExampleJSONFormat
After completing the domain schema it is possible to preview the message format by clicking the preview button, as shown below. It is possible to choose between XML and JSON format.

Unnamed arrays

Tip
titleNew feature
Starting with Blueriq 10.1 JSON messages can also be defined as unnamed arrays.

Example of a JSON message that consists of an unnamed array:

Code Block
[
	{ "John", 23 },
	{ "Rick", 30 },
	{ "Paul", 27 }
]

To define an unnamed array the 'Hide root element' checkbox corresponding to the domain schema root element must be ticked.

Simple example of use:

Say that you have a service that returns e-mail addresses of your new subscribers in form of a JSON unnamed array:

Code Block
[
	"John@sever.org",
	"Peter@sever.org",
	"Maarten@server.org"
]

The Studio coresponding domain schema should look something like this:

But now by clicking on the 'Preview' button you can observe that the generated JSON doesn't look like the expected message:

Code Block
{
  "email_address": [ "value" ]
}

To fix this, you can just click on the root element and tick the 'Hide root element' checkbox located on the right in the application domain. By doing this your JSON message should be correct and you should be able to map indeed all the values recieved in the email_address attribute.

Code Block
[ "value" ]
Warning

When making use of unnamed arrays, only one child (relation or attribute) can follow the root element. For instance, the following is NOT correct and hence the project will have validation errors:

Domain Schema in another Domain Schema

Tip
titleNew feature
Starting with Blueriq 10.3 other DomainSchemas can be included as domain properties in another DomainSchema.

A new option is available for selection in the drop-down for adding a new domain property , which consists of the domain property name, the relation name and the domain schema name.

When selecting the sub-domain schema, the following validations are applied :

  • a sub-domain schema can be added under the root entity or under a relation
  • the root entity of the sub-domain schema should be the target entity of the selected relation
  • the root entity of the sub-domain schema should have as base entity the target entity of the selected relation
  • adding a sub-schema which has root element hidden will trigger a validation message

Infinite loop

Because domain schemas can be referenced by other domain schemas, it is now possible that infinite loops are created.

For preview purposes, a hardcoded limit of 2 loops was set for the Studio preview.

For more information on how to set the infinite-loop-limit for Runtime, check the properties documentation page

Schema Element in Domain Schema

Tip
titleNew feature
Starting with Blueriq 11.4 custom schema elements can be included as domain properties in another DomainSchema.

A new option is available for selection in the drop-down for adding a new domain property , which consists of the domain property name and the custom schema element name. 

This feature can be used for adding extra explanation for the value of attribute domain properties in the domain schema, for example by adding the AQ_JustificationTree custom schema element. 

...