See also updated developer documentation
“Distributed Apps” is a new feature which allows personalisation apps to be hosted in multiple locations around the world.
The primary advantage of distributed apps is that a website using a distributed app can continue to take orders even without any connectivity to our main UK based CPP and OMS servers. In comparison, when using apps in a non distributed manner, there is always a dependency on the main UK servers, even when used in conjunction with the CDN. Distributed apps mean the client side personalisation software can be scaled to meet any amount of traffic.
Distributed Apps are essential for market places such as China where a reliable connection is not possible to a server outside of the China firewall
Each hosting location is called a “distribution”. A distribution is a completely self contained system which has its own copy of all needed data (such as product assets, fonts, etc).
A distribution is updated periodically by the primary UK based CPP servers with new or modified data and assets. The update process can occur in a variety of different ways depending on the distribution requirements (i.e. FTP, SFTP, S3, etc). Typically updates occur every hour.
The data and assets made available to a distribution is configurable (via programming), so that distributions may be limited to specific apps or specific sets of products. This allows larger customers to have their own instance of the personalisation platform and even host it themselves, whilst still allowing Gateway3D to maintain overall control of the system.
Distributions are responsible for the handling of any API calls made by the app. For example user image uploads and print job creation. In a distributed app, these API calls will no longer be dependent on contacting our central UK servers.
For example, once an end user clicks “Add to Cart” in a distributed app, the distribution itself will handle the print job API call. It will then pass data back to the central OMS system asynchronously (typically within a few minutes). This means that print jobs will not be immediately visible in Print Manager.
Note that a print job still requires an order to have been created before any artwork is generated. Order creation via the Order-iT API and anything related to fulfilment is still centralised to the UK and this is unlikely to change in the future.
A side effect of print jobs not immediately being visible in Print Manager means that it is possible for a website to send an order for a print job that is not yet available. If this happens then the order will be created with an “On Hold” status and an item type of “Print Job (Pending)”. As soon as the print job becomes available, the status and types will be updated automatically and the order can progress as normal.
Currently there is only 1 standard public distribution:
In addition, there are currently several private distribution for various customers
Distributed App URLs
Because distributed apps are stored as statically compiled HTML their URL format is different.
Example of URL:
It is now mandatory to specify both a locale (i.e. en_GB) and a configuration (i.e. default or a configuration code). Both the locale and the configuration are now a part of the path rather than URL parameters.
For more information on distributed links please refer to this knowledgbase:
Non Distributed Apps
Existing apps will continue to work without any changes.
New apps will be set to only work as distributed apps and will not be accessible from the old style URLs.
The CPP link builder will be smart enough to handle the different scenarios.
(for distributed apps only)
- The printJobId field passed by the app’s callback URL will now be a 32 character string. Some bespoke API integrations may handle this transparently however partner developers should be notified of the change.
- URL format change as described above.