Limitations of eMagiz definitions

Last modified by Danniar Firdausy on 2024/09/16 14:32

In this microlearning, we will delve into some crucial limitations you will need to be aware of when importing your definitions into eMagiz. Understanding these constraints will help you make informed decisions and avoid potential issues.

Should you have any questions, please contact academy@emagiz.com.

1. Prerequisites

Basic knowledge of the eMagiz platform

2. Key concepts

This microlearning centers around learning which limitations you need to take into account when importing your definition.

With eMagiz definitions we mean: Structured data models that represent how a message should look like at a certain point in the flow
With limitations we mean: Restrictions of what will and what won't work when importing your definitions

3. Limitations of eMagiz definitions

In this microlearning, we will focus on certain limitations when importing your definition in eMagiz. It is necessary to understand these limitations in order to make the correct choices before importing your definition into eMagiz. Identifying and knowing about these restrictions will improve your decision making the moment you want to import your definition

Imported files cannot be larger than 1MB
xs:all statements cannot be represented in the data model.
ref statements cannot be represented in the data model.
choice constructs cannot be represented in the data model.
Iterations (maxOccurs) over a threshold of 50 are not accepted
Cross reference between entities that could lead to an infinite loop are not accepted

Below we will specify per limitations what this exactly means.

3.1 Imported files cannot be larger than 1MB

As a normal user you are not allowed to upload files that are larger than 1MB. This to prevent people from uploading huge files that could potentially bring down the eMagiz portal for all users. In cases where you need to import a file that is larger than 1MB you need to contact your partner manager. This way we can analyze your exact needs and provide a tailormade solution that will help you import your definition.

3.2 xs:all statements cannot be represented in the data model

As specified before in earlier microlearnings, eMagiz defines the expected structure with the help of data models. Within a data model you need to specify the order in which entities and attributes follow each other. In XSD terminology this is called xs:sequence. In some cases your definition might have xs:all instead of xs:sequence. xs:all means that attributes and entities can arrive or be send in a random order. As this cannot be modeled out in a data model eMagiz will not support it.

In these cases you will have to change your definition to state xs:sequence everywhere the definition says xs:all. After that you can upload it without problems. Changing your definition in such a way could impact the validation of incoming messages. When the delivering party indeed sends its data in a random order everytime you need to take additional steps to ensure this will work in eMagiz. There are two alternatives when dealing with this problem:

Write a custom XSLT that will transform the incoming message to a structured messages that you can validate via the tooling
Use a custom XSD as validation and use the standard eMagiz tooling for your transformation, whereby you assume that your system definition has a defined structure

3.3 ref statements cannot be represented in the data model

As specified before in earlier microlearnings, eMagiz defines the expected structure with the help of data models. Within a data model you need to specify the association between entities. In XSD terminology this is represented as follows <xs:element type="itemsType" name="items"/>. However, sometimes we see a different notation that is not working when importing an XSD in eMagiz. This notation is <xs:group ref="status_group" />. To get this in you need to rewrite the association in your XSD a bit to reflect the first notation and mention that the assocation is optional (minOccurs="0").

3.4 Choice statements cannot be represented in the data model

As specified before in earlier microlearnings, eMagiz defines the expected structure with the help of data models. Within a data model you need to specify the association between entities and order within these entities. In XSD terminology this is represented as follows <xs:complexType><xs:element name="employee" type="employee"/><xs:element name="member" type="member"/></xs:complexType>. However, sometimes we see that a choice is offered in the XSD. This notation means that you can supply A or B. This notation is <xs:complexType><xs:choice><xs:element name="employee" type="employee"/><xs:element name="member" type="member"/></xs:choice></xs:complexType>. To get this in you need to remove the reference to the <xs:choice> and the </xs:choice> lines in your XSD and make each element within the choice optional (minOccurs="0").

3.5 Iterations (maxOccurs) over a threshold of 50 are not accepted

To prevent weird results when it comes to the creation of data models we do not accept maxOccurs above 50. To succesfully import your definition you should change the maxOccurs setting to unbounded. This way eMagiz will succesfully import the definition. As of today we have never encountered a practical case where this caused issues.

3.6 Cross reference between entities that could lead to an infinite loop are not accepted

In some cases we see definitions in which entities keep referecing each other. This could cause an infinite loop to occur when trying to build up the correct structure of your system message. Therefore we do an initial check when importing your file to safeguard ourselves against creating infinite loops in our portal that will in the end break the eMagiz portal.

4. Key takeaways

File Size Limit: Imported files must be 1MB or smaller to ensure system stability. For larger files, please contact your partner manager for a tailored solution.
No xs:all Statements: eMagiz cannot process xs:all statements which allow elements in any order. Convert these to xs:sequence to ensure compatibility.
No ref Statements: ref statements for element references are not supported. Use explicit element definitions instead.
No choice Constructs: eMagiz does not support xs:choice constructs. Modify your schema to make elements optional rather than using choices.
Max Occurrences Limit: maxOccurs values over 50 are not accepted. Adjust to unbounded if needed for successful import.
Avoid Infinite Loops: Cross-references between entities that may create infinite loops are not allowed. Ensure your definitions avoid such structures.

5. Suggested Additional Readings

If you are interested in this topic and want more information on it please read the help text provided by eMagiz and see the following links: