FD1 Client Protocol

Using Fieldpine from External Website

Fieldpine as a retail application allows you to completely control the visible user experience. There is no one size fits all in retail operations, so while we provide a range of HTML interfaces and menus, retailers are able to replace all or parts of it, even down to using your own domains and external websites.

Users
Applications
«--» Your Website «--» Fieldpine Servers instore
«--» Fieldpine Cloud Servers
«--» Backup Servers

You can create your own domain "myretail.example.com" and create your own web pages or applications. These web pages open a FD1 websocket to Fieldpine servers to read/write retail data. You don't have to start from scratch, you can copy Fieldpine resources, or replace only parts of it, such as menu pages.

Architecture

At its heart, Fieldpine Retail provides a [large] number of API functions you can call to run your store(s). You run multiple Fieldpine servers, and these transparently communicate in the background. Your users and applications communicate to Fieldpine using API calls.

Conceptually Fieldpine is simply a "pipe" of data/transactions going in and out.

For redundancy and high uptime, Fieldpine servers are a mix of cloud, inhouse and instore. Your applications switch between these silently without users being aware of a change. In computing, everything fails sometime, so the architecture is built to remove as many single points of failure as possible.

Technical Notes

  1. A website such as example.com cannot directly call standard Fieldpine servers due to CORS restrictions. You will need to allow CORS support. Using CORS however can result in preflight messages for every request. This can slow your application down, so in general we dont recommend enabling CORS.

    CORS is not robust security measure, it is designed solely for web browsers and is trivial to bypass using command line tools instead of a browser.

  2. Opening a websocket can be made from any domain without CORS restrictions. Mixed content rules, connecting to http: from an https: endpoint still apply. Fieldpine websockets require your first message to be a login credential. Websockets in browsers have their own special rules around headers. For security reasons, Fieldpine servers generally restrict websocket connections to a known list of countries, this is good for security, but means if you go on holiday overseas you may need to open the range of permitted countries. This applies to the user location as reported by their IP address when browsing, not your server location.
  3. Fieldpine detail web pages, such as single_product_overview.htm have embedded menu links, such as a link to /report/pos/sshome_products.htm. This enforces a menu structure on your application which might not be suitable. We are changing all our pages to use a "URL Space" which defines these links in a way that you can override.

    What we are really saying here is that you can use single_product_overview.htm without modification, and externally influence the links on the page

  4. Fieldpine does not usually use a service worker, but we may in the future.

Intercepting Navigation Links

Most Browsers support navigation request intercepts, meaning a web page can see and influence a hyperlink when the user clicks on it. You do not need to add special tags to every <a> anchor and other places. This means you can

  1. Insert custom JS file onto every page. Fieldpine can optionally add a site supplied JS script file to each page.
  2. This page adds a navigation listener to capture when user attempts to navigate away.
  3. Your script can do whatever it wants.

Intercepting fetch Requests

Historic Fieldpine pages assume the origin webserver is also the API server. If you are running your own custom front end, or the page is able to dynamically which server for failover purposes, then the origin webserver is unlikely to be able to process REST API calls.

A technique called monkey patching can be used to capture all fetch() style requests, and can dynamically alter or replace the request. If you are including a custom JS script, as described above in navigation links, then this script can also easily redirect all data requests.