Importing Tool
Last updated
Last updated
We've received many different kinds of requests over the years for handling data. The most common of these are orders without a "customer" attached, and legacy data.
In the past, we have rejected these kinds of requests due to limitations in the core underlying software (no support for orders without a user), or due to data incompatibilities (legacy data in a wide array of different formats).
The expectation should be that the new product would support order-level data with or without an attached customer out-of-the-box, thus eliminating the first problem.
To solve the second, an on-premises import tool should be developed that can be used to easily import a vendor's legacy data into the Spoonity platform.
This tool would be installed by a vendor's IT department, and would be connected to our systems. Users would then be presented with two options:
translate your data into the "Spoonity" format by hand to be pushed into the import tool, or;
build a "translator" schema document that would instruct the import tool how to handle the data.
The import tool would then accept a supplied input and push it to a vendor's data shard to be available to us to work with.
The import tool's core responsibility is to take input (a vendor's data), and to push it to our servers to be imported.
Using option A as noted above, a vendor's data would simply be imported wholesale into our systems by using a standardized data format.
When using option B, a translator schema would be required. A translator schema is meant to be a single text document, written in either a JSON or YAML format. This document would include specific information about how a vendor's existing data would need to be translated internally by our import tool before being processed and imported.
Users would append that translator schema to their data as part of the upload process, and it would instruct the import tool on how to restructure the data before pushing it to the Spoonity servers.
The import tool should be built in a way as to handle as many different input formats as possible. Since the goal of this tool is to be flexible, the system should automatically detect a data format and provide feedback for the user.
To start, our tool should support the following formats:
CSV (and other delimited formats)
Microsoft Excel
JSON
a direct database connection
This information would be configured by the user using the import tool. In most cases, the user would simply upload a file to the tool (and optionally specify a translator schema). In the case where the user was connecting our import tool to a database, they would need to enter the database access credentials.
