Fiftytwo on-premise APIs

The following APIs are available for on-premise use:

• 52API ARTICLE

  Use cases:

  • Mobile price checkers

  • Prices for web or apps

  • Price updates and changes in real time

  Selected features:

  • Push of all price changes per store to omnichannel controller

  • Article queries on master data and price in specific store

  • Free text article search

  • discount families

  • Article hierarchies (drill-down search)

  Learn more about the on-premise Article API (for developers who are going to work with the API on-premise)

---

• 52API ORDER

  Use cases:

  • Integration between web and physical stores

  • Sales through web and in-store purchases

  • As the basis for click & collect

  Selected features:

  • Consistent order handling

  • Orders delivered via omnichannel controller down to individual store controllers

  • Creation of new orders

  • Adding and changing of order lines and calculation

  • Payment registration (via Payment Gateway)

  • Registering of complete order – calculated by external system

  • Viewing of order status and receipt ID

  Learn more about on-premise Order API (for developers who are going to work with the API on-premise)

---

• 52API BASKET

  Use cases:

  • Basket and receipt calculation optimized for web and scalability

  • Makes discounts, etc. work exactly like they do with a regular till

  Selected features:

  • Exposed as a stateless REST interface

  • No persistence of basket or receipt

  • Possible to run multiple 52ViKING tills, which allows load balancing and scalability

  • Each 52ViKING till has a single import of articles and a single database, but multiple execution threads

  • Useful as a basis for automated test and verification of correct calculations

  Learn more about on-premise Basket API (for developers who are going to work with the API on-premise)

---

• 52API VOUCHER

  Use cases:

  • Ensure ability to use vouchers across physical stores, web, and other channels

  • Batch issuing of unique vouchers (for example for e-mail marketing)

  Selected features:

  • Ability to use vouchers across physical stores, web, and other channels

  • Reservation

  • Redemption

  • Viewing of individual voucher values

  • Issuing of unique vouchers

  • Ideal for use in conjunction with Order API and Basket API

  Learn more about the on-premise Voucher API (for developers who are going to work with the API on-premise)

---

• 52API BONUS

  Use cases:

  • Bonus point systems with accounts

  Selected features:

  • View balance

  • Reserve and use bonus points

  • Move bonus points between accounts

  • View “exchange rate”

  • Transaction history

  Learn more about on-premise Bonus API (for developers who are going to work with the API on-premise)

---

• 52API GIFT CARD

  Use cases:

  • Sale and redemption of gift cards via web

  Selected features:

  • Redemption of gift cards

  • Recharging of gift cards

  • Sale of new gift cards

  • Activation of gift cards

  • Balance inquiries

  • Viewing postings

  Learn more about the on-premise Gift card API (for developers who are going to work with the API on-premise)

---

• 52API PROMOTION

  Use cases:

  • Manage personal discounts through customer segmentation in external systems

  Selected features:

  • Creation and deletion of discount groups

  • Viewing of discount group master data

  • Linking to customer ID discount groups and vouchers

  • Store group management

  Learn more about the on-premise Promotion API (for developers who are going to work with the API on-premise)

---

• 52API SAVE RECEIPT

  Use cases:

  • Give external partners or tools the ability to store receipts on a 52ViKING server

  Selected features:

  • Upload receipts

  • Store receipts

  • Validate data format

  • Convert receipts to a transaction format that the 52ViKING store controller can handle

  Learn more about the on-premise Save receipt API (for developers who are going to work with the API on-premise)

---

• 52API ACCOUNT

  Use cases:

  • Offer account sales, which can be especially interesting for retailers who have B2B customers.

  Selected features:

  • Account balance queries

  • Reservations of payment amounts on accounts

  Learn more about the on-premise Account API (for developers who are going to work with the API on-premise)

To use the Fiftytwo suite of on-premise APIs in a unified commerce environment, you'll need at least one Fiftytwo omnichannel controller (OC).

The role of the Fiftytwo omnichannel controller is to make all of the vital components in your unified commerce environment communicate together seamlessly in real time.

We recommend that you use several instances of the Fiftytwo omnichannel controller because that'll help you distribute resources and even out loads so that you'll always have the capacity for handling calculations with acceptable response times, even during peak periods like, for example, Black Friday.

With multiple omnichannel controllers, you also avoid having a single point of failure, and you get more flexibility for service windows because the server instances can take over from each other as required.

Environment architecture examples:

---

High-availability environment with database cluster (recommended)

An environment with load balancing and a database cluster ensures high availability, capacity that's able to scale to accommodate even very high loads, and a fallback option.

---

Mid-level environment

An environment like this provides load balancing as well as a fallback option, but the database setup with mirroring between the primary and replica databases gives less flexibility, scalability, and robustness than a database cluster. Organizations with limited load and no great load fluctuations may be able to live with this.

---

Single omnichannel controller environment (not recommended)

An environment with a single omnichannel controller has several disadvantages: Single point of failure, all services on the server share the same resources, capacity is unable to scale with load, service windows will mean downtime, etc.

What constitutes acceptable performance depends on many factors, including environment and load.

For example, performance may go down exponentially as the size of a customer's basket grows, so that system request handling times (which is typically measured in milliseconds) may go up if customers have many items in their baskets. With 20 articles in your average customer's basket, it's not likely to be a problem, but if your average customer has 200 or 500 articles in their basket, it might be – especially if the customer is in a hurry, or you have many other customers who also want to be served.

What may be acceptable performance in one scenario, may be unacceptable in another, and that's why it's a good idea to think about possible scenarios and peaks.

Black Friday is an example of a peak scenario that's important to some retailers, even though it only happens once a year: They may be very happy with the performance of their unified commerce solutions on an everyday level, but on Black Friday, when loads can be much higher than normal, they may experience performance degradation, such as longer response times per request, or even failed requests that'll need to be resent.

Whether that's acceptable on a single day of the year, or whether you want to spend time and resources on optimizing your solution's components to be able to handle very high loads better, is a matter of individual preference. Our experienced consultants will gladly help you do an analysis of your specific solution and expected scenarios based on three important parameters:

• Cost

• Effort

• Benefits

Apart from using more powerful hardware and/or dedicated servers for separate purposes, there's a wide range of other technical adjustments that experienced consultants can make to ensure that, for example, a busy system handles processes as efficiently as possible, and/or that important processes on your system are given a higher priority than less important ones.

Three examples:

• FCGI is a protocol that facilitates communication between interactive programs and web servers. By modifying FCGI configuration parameters, such as FcgidMaxProcessesPerClass, it's possible to optimize how well a web server on a unified commerce system handles many concurrent requests.

• CPU time allocation can be controlled to give specific processes a larger share of a CPU's time, for example by modifying so-called nice (or niceness) values for processes on servers that run Linux.

• Cleanup routines on database servers can be modified to optimize performance.

Such modifications and prioritizations may of course have side effects in that they may affect other programs, processes, etc., so it's important to consider pros and cons against your expected scenarios.

Simply contact Fiftytwo for more advice.