In Store Server Website

Each store typically runs a local Fieldpine Store Server. This is essentially a mini web server to interact with devices in that store.

Running a local server removes network delay and hides many "network is down" issues
This is optional, and stores can run directly to a head office server, or Fieldpine Online

While the store server webserver is quite controlled and not a general purpose webserver, it can be used for alternative purposes.

Creating Secondary Domains

Retailers may wish to have a secondary domain that provides a custom website experience while still having access to Fieldpine data under the hood. A common case is where say warehouse staff need to access a small subset of Fieldpine and want their own menu structure and to be restricted from other areas.

Note, These are internal domains, not open to the general internet unless specifically enabled

http://192.168.22.88 ⇘	https://tokyo-store.example.com ⇙	https://web-orders.example.com ⇓
Points direct to "standard Fieldpine" ⇓		Custom Menus and Options ⇙
Fieldpine Store Server Or Head Office Server

Secondary domains are typically added at HO level, but can be added to any Gds/Store Server.

This is advanced setup and requires directly editing Fieldpine control files.

In the \fieldpine\gds2 folder edit the file gds.ctl using a text editor such as notepad.
Add the following lines, changing as needed.

-------------------------------------
host web-orders.example.com
use-environment=mystore
type=webserver
root=C:\somefolder\with\web\files

In the above section "use-environment=mystore" names which environment (ie Retail operation) should be used. Somewhere in gds.ctl will be some lines similar to this
```
-------------------------------------
environment mystore
...
```
This is providing the name of the environment. The "mystore" needs to match the "use-environment" in the details in point #2 above.
If your environment does not have a name, add one.
Save the file and restart Gds
In the root folder (C:\somefolder\with\web\files in our example), create an index.html file, eg
```
<HTML>
<BODY>
Hello World
</BODY>
</HTML>
```
Open a browser and browse to http://web-orders.example.com and your index file should appear

We now have a functioning simple web server, but it only serves static files. To access your Fieldpine Store Server the URLs must be specifically enabled using a file named _urlrules.json (in the root folder; C:\somefolder\with\web\files in our example)

Example

{
  "/pick.htm": "/report/rr/sales_pickonly.htm",
  "/pack.htm": "/report/rr/sales_pickscanout.htm",
  "/sales_pickscanout.htm": "/report/rr/sales_pickscanout.htm",
  "/report/elink/*": true,
  "/report/theme/*": true,
  "/geni/*": true,
  "/gnap/*": true,
  "/o3/*": true
}

This file says

The url http://web-orders.example.com/pick.htm is valid and uses the standard web page /report/rr/sales_pickonly.htm
The url http://web-orders.example.com/pack.htm is valid and uses the standard web page /report/rr/sales_pickscanout.htm
The url http://web-orders.example.com/sales_pickscanout.htm is also valid and uses the same standard web page. This rule is required as "pick.htm" has a hyperlink to "sales_pickscanout.htm"
Any url starting /report/elink/* is passed through. All the lines that have "true" as value are passed through. These are the various APIs used by the page.
Using wildcards like this means a skilled user may be able to directly calls APIs. If this is a concern, do not use wildcards and list each URL.