Destination Defined Data Structure

It is supremely important to think about the target or destination in terms of data shape/hierarchy/levels as this will dictate the shape your data needs to be in.

Data can be flat (i.e. have one level), or hierarchical (i.e. have multiple levels) in structure.

In order for external applications to read data correctly, the data needs to be in the structure the application expects.

one Level

The most simple data structure, as it has only one level the user does not have to consider the nature of hierarchy.

Example: Customer Account Details

This will be the top level of customer information, i.e. customer Id and email address etc.

Connectors

Only one transaction type needs to be mapped.

Writers

Able to select which fields to include.

As there is only one level, will only have one transaction type to select from the drop-down.

Tasks

The expando field used to reference the data will include the Transaction Id for the relevant transaction type.

Again, at this level it is simple, as there will be only one transaction type available.

two Levels

A more complex arrangement, which utilises a hierarchical data structure.

Example: Order or invoice

Information in the header record, such as Customer Id, and Order Number will be mapped to the top level through the connector. While, order details, such as Item number and Shipping Address, will need to be mapped to the detail level in the external application.

Connectors

The application the connector is exporting to will dictate how it needs the data to be structured, as each transaction type will need to be mapped at the appropriate level in the structure.

Writers

The drop down in the field mapping tab will have two transaction types to choose from. It is vitally important that the header and details are mapped to the correct fields and the detail's relationship to the header is defined.

Tasks

The expando field will need to reference the correct transaction type, and thus the correct level.

three or More Levels

This is the most complex hierarchical structure, and can continue indefinitely.

Example: Item details on an order

In this example, if an application needs the children to have child attributes (such as available suppliers, pack sizes or units of measure) these records would need to be mapped with their parent transaction identified. Otherwise, the connector would not create them.

Connectors

The application the data is being exported to will dictate the structure the data needs to be in.

Writers

The drop down at the top of the field mapping tab will have three or more transaction types to choose from.

It is vitally important to map the records, with each transaction connected to the correct parent: Order details would need the header as it's parent Id, while Item details, would have Order details selected as it's parent Id.

If these relationships are not defined correctly, an error will occur.

Tasks

The expando fields will need to reference the correct Transaction Type, and through doing so will reference the correct level.