DataMosaicDocs · Connecting to data
Systems
The systems your business runs, connected once so every Check can start from them.
The systems this business runs — the tills, the central database, the ERP — each connected once, so a new data source picks one instead of having its connection typed again.
A System is a product from the catalogue, as one instance you actually run, with its own connection. It is not a query and not a host list. It is the thing itself: your Xstore, your central database.
Set them up first and the rest of Mosaic gets easier, because every new data source can be filled from one instead of having a hostname and a password typed again.
#The catalogue
| Group | Product |
|---|---|
| Point of sale | Oracle Xstore · Point of sale |
| E-commerce | Shopify · E-commerce platform |
| ERP | SAP · Microsoft Dynamics 365 · Oracle NetSuite · ERP |
| Warehouse | Warehouse management |
| Product information | Product information |
| Payments | Payment acquirer |
| Databases | Central database · Interface database |
| Data warehouse | Data warehouse |
| Other | Custom system |
Each entry says what it is for — "The till estate: what each store rang up, read from the POS database", "The staging or log database an integration writes through between two systems" — and offers the drivers that product is usually reached through. Custom system offers every driver.
A product can be added as many times as you run it. Three Oracle databases are three systems.
#Adding one
Pick from the catalogue on the right, then give it a connection.
| Field | Notes |
|---|---|
| Name | Blank falls back to the product's name |
| Connection | Only shown when the product offers more than one driver. Changing it starts the connection details over |
| The driver's own fields | The same as a data source's, minus the Table field and the collection list |
| Where it runs | The business locations that use this system |
| Enabled |
Passwords behave as everywhere else: "A password or key typed here is encrypted and never sent back to a browser — leave the stored one as it is shown to keep it."
Test connection is available for SQL systems.
#Connecting Shopify
On the hosted service, a Shopify system is connected by signing in on Shopify rather than by pasting a token. Type the Store address — the store's myshopify.com address — and press Connect Shopify. Shopify asks the store's owner to approve the access, and sends them back to the system, which then reads "Connected to your-store.myshopify.com", when, and what it can read.
The access asked for is read-only: orders (including history past sixty days), products, stock and locations. Mosaic never writes to a store.
- Reconnect signs in again, for example after the store's owner changed what the app may read.
- Disconnect removes the access from Mosaic. It does not revoke it on Shopify's side — to do that, uninstall the app from the store's Shopify admin.
Connecting needs an admin of the workspace. On a self-hosted installation there is no sign-in: paste an Admin API access token into the connection as you would for any other API.
#Queries a system arrives with
Some products come with the questions everybody asks of them already written. Installing Shopify puts eight queries in the library, named after the system:
| Query | One row per |
|---|---|
| Orders | order placed in the date range — number, status, channel, store for POS sales, totals |
| Order lines | line of every order in the date range — SKU, quantity ordered and kept, line total |
| Order payments | money movement behind each order in the date range |
| Price by item | variant on sale — SKU, barcode, selling price |
| Stock available | variant — what can be sold now, summed over every location |
| Stock by location | item stocked at one location |
| Products | product as the store publishes it |
| Locations | place the store keeps stock and sells from |
The order queries ask for a date range: dateFrom is included and dateTo is not, and the defaults read yesterday. Stock by location asks for a locationId, which is the id the Locations query lists. None of them asks for buyers' names, emails or addresses.
They are ordinary library entries — add them to a Check, edit them, copy them. Two things are different about them:
- They follow the system's connection. A system is usually installed first and signed in to afterwards, so the queries are updated whenever the system's connection changes — connected, reconnected, disconnected or edited. Only how the system is reached is replaced; a query you have edited keeps its edits. A Check that has already added one keeps its own copy, as with any library entry.
- They show the system's logo in the library, and their tags name the system and the query, locked, because removing them would cut the entry loose from its system.
The system's own panel lists its queries under Queries in the Library. If some were deleted, Put back the missing ones adds them again and leaves the others alone; for a system added before its queries existed, the button reads Add its queries to the Library.
#Where it runs
Only shown once Business Locations has at least one open place.
Leave every box clear and the system runs everywhere. Tick some and it is restricted to those places — which is what drives the locations chip on the row, and what decides which places a linked host list covers.
#Filling a data source from a system
In a data source's header, Connect with a system offers every enabled system of the same driver type. If none fit, the control is not shown at all.
Picking one fills the connection — and the fill happens on the server, so the password never reaches the browser.
What is copied is the connection: host, port, credentials, TLS settings. What stays with the data source is the query, the binds, the table, its own host list and its row limits.