eBiss 3

The type editor allows the creation and editing of system-managed Types by the user. For this a type definition is created either manually or based on a template (e.g. XSD, JSON, etc.), in a way similar to the creation of a map object in the mapping editor. The resulting structure can then be extended via the actions available in the context menu (tree view) and further adjusted using the detail view on the right.

Note: For creating datatypes with the type editor, it applies that C# keywords may not be used as data element names!

Type definitions of system-managed types can either be created fully manual or based on a number of templates:

• using an existing DLL containing map objects
• using an XML document
• using an XSD
• using an JSON document
• using a database table

When elements are manually created the user must differentiate between simple and complex field definitions.
Simple field definitions represent terminal a field of a simple value type (flags, strings etc.) while complex field definitions represent a collection or list of other elements.

When a complex field represents the same structure as another field, it is advised to use the reference properties. That way any changes in the referenced type will be translated to all complex fields that reference that field. The following order of steps needs to be followed when a reference should be enabled:

1. Determine the correct path to the referenced field. Starting from the root combine all elements with a dot. E.g. Invoice.OrderReference.DocumentReference
2. Enter the resulting path into the 'Reference path' property of the target field.
3. Toggle 'Reference enabled' to yes. If the property stays disabled the path in 'Reference path' is either incorrect or not pointing at a complex field.

Disabling the reference will copy the referenced structure into the complex field.

Elements inside the tree view can be modified via the actions made available by the context menu and their corresponding shortcuts or can be moved via drag and drop If an element is dropped on a simple field definition then it is placed below the target element. If it is instead dropped on a complex field definition, then it is placed inside it (appended). This behaviour can be modified by holding the shift key during the dropping action. The element is then placed before the target element regardless of the target elements definition.

Further properties of a field definition can be changed in the detail view located in upper right area of the editor.

In addition, the lower part of the detail view allow to further customize the field definition by the addition of attributes.
Attributes can be added or removed via the actions made available by the context menu of the list view on the left and can then be further edited by the detail view on the bottom right.

The XPath calculated field definition can be used to create any field.
A condition (XPath expression) is used to assign a specific value to the field.
This can be useful if e.g. within the header level the source object structure contains a list.
In a simple field inside one of the lists, there is e.g. information which you want to assign a MapFrame attribute (e.g. sender).
So in this case you could create an XPath computed field on which you put the MapFrame attribute.
This can look like the following:

Note: The XPath expression can be tested in the Map Debugger, where the XPath expression can be inserted in the mapping for testing from the point where the property is defined.

Several other actions are available if the type definition is created based on an XSD or a database table. Additional elements can be added to the structure or present elements merged with their corresponding definition inside the source.
This “merge” action can also be executed over the entire structure via a menu action present in the “Object definition” menu in the upper left corner.

You have to provide the connection string and type of connection prior to creating an object definition based on a database table. If a default system partner is specified in the current node and variables with the names “ebiss.dbadapter.connectionstring” and “ebiss.dbadapter.connectiontype” have been defined for this partner (see HowTo - database integration (DB adapter)) then the values of these variables will be used as a preset for the connection parameters.

If the created object definition is meant to be used in conjunction with the eBiss DB Adapter, please make sure that the “Usage” property of the system-managed type is set to the correct value.

Note: Until further notice eBiss supports only one namespace within a database, because the database “connection string” does not offer the possibility to select the namespace, usually the default namespace of the SQL user is used. (But the list of selectable tables shows tables of all namespaces within the database).

Below you'll find examples for commonly used connection string formats and connection types:

Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;

System.Data.SqlClient.SqlConnection

Server=myServerAddress;Database=myDataBase;Uid=myUsername;Pwd=myPassword;

MySql.Data.MySqlClient.MySqlConnection

Data Source=c:\mydb.db;Version=3;

Microsoft.Data.SqliteConnection

user id=SYSTEM;password=<Password>;data source=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<Host>)(PORT=<Port>))(CONNECT_DATA=(SERVICE_NAME=<Service>)))

Oracle.ManagedDataAccess.Client.OracleConnection

or

Oracle.DataAccess.Client.OracleConnection 

Views as a source for type definitions are only supported for the database adapters listed above.

Sample data can be created for a given type definition and actual message data loaded into the present structure.
The user can also export a structure filled in such a way or crate an assembly containing only the given system-managed type to allow for further debugging.