52MASTERPRICER APIs & architecture

This topic is primarily for administrators and other people who manage a Fiftytwo solution

Overview of the APIs in the 52MASTERPRICER suite as well as overall architecture recommendations.

Fiftytwo CTO Peder Herborg explains how 52MASTERPRICER works from a technical perspective, and how 52MASTERPRICER solves complex challenges and provides correct pricing when retailers tie their physical and digital sales channels together.

  • Duration: 6.11

  • Language: Danish with English subtitles

An API (Application Programming Interface) is a set of building blocks that together provide an interface for consultants, software developers, and others who need to access a system's features and data in order to integrate the system with other systems.

Fiftytwo offers two series of powerful APIs that let you work intelligently and flexibly with all aspects of your unified commerce environment:

  • Cloud: One that is cloud-based (experience the cloud-based APIs on api.fiftytwo.com )

  • On-premise: One for on-premise use (described in the following).

Use of the APIs requires software developer skills. If you don't have software developer skills in your organization, a Fiftytwo consultant can help your organization use the APIs.

The following APIs are available for on-premise use:

  • 52API ARTICLE

    Use:

    • 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:

    • 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:

    • 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:

    • 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:

    • 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:

    • 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:

    • 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:

    • 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:

    • 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 52MASTERPRICER and its suite of APIs in a unified commerce environment, you'll need at least one Fiftytwo omnichannel controller (OC).

While the primary role of 52MASTERPRICER itself is to ensure pricing consistency across channels, 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 highly 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.

* Provided that system requirements are met.

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. That's why our recommendations cover minimum requirements that we've tested, so that we know that they'll generally work satisfactorily.

Whether our general recommendations will be good enough for your organization's specific environment and needs is of course another matter, and that's why our experienced consultants will gladly help you do a cost/effort/benefit analysis of your specific solution and expected scenarios.

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 advice.