LogoLogo
Fredhopper Integration Guide
Fredhopper Integration Guide
  • Fredhopper Integration Guide
  • Fredhopper Integration Guide
    • Data Integration
      • Item Data Structure
        • Full Feeds
          • Full Feed JSON Data Format
          • Full Feed CSV Data Format
        • Incremental Feeds
          • Incremental Feed JSON Data Format
          • Incremental Feed CSV Data Format
        • Full and Incremental Feed Uploads
      • Suggest Service Data Feeds
        • Suggest Service Data Format
        • Suggest Data Uploads
      • Custom Data Feeds
        • Custom Data Format
        • Custom Data Uploads
        • Services API Fail Safe Features
    • Front-End Integration
      • Understanding the Fredhopper Query API
      • Using the Fredhopper Query API
      • Fredhopper Query Language
      • Redirects - REST vs. SOAP
      • Query API Fail Safe Features
      • Integration Best Practices
      • Suggest
      • Definitions
      • Fredhopper Query and Response Samples
    • Glossary
Powered by GitBook

Copyright @ 2024 Crownpeak Technology, Inc. All rights reserved.

On this page
  • Overview
  • Services API
  • Infrastructural Components
  • Front-end
  • Internet
  • DNS Authority
  • Data API Node
  • Mechanisms
  • Integration guideline
  1. Fredhopper Integration Guide
  2. Data Integration
  3. Custom Data Feeds

Services API Fail Safe Features

PreviousCustom Data UploadsNextFront-End Integration

Last updated 8 months ago

Overview

This section is an extension of the information provided in the API reference documentation and describes the fail-safe setup of the API end-points of Fredhopper Services and provides a guideline for the integration of these APIs.

Services API

The Services API accepts requests to supply or retrieve data and trigger the data processing. Although we support both the FTP and REST protocols to interface with the Services API, we strongly recommend using REST.

The diagram below depicts the overview of the infrastructure setup and indicates the fail-safe components:

Infrastructural Components

Front-end

By front-end we mean the complete set of components in the web application on the customer's side involved with the integration of the Services API. One could think of the application back end servers and the underlying infrastructure, proxies and other network appliances etc.

Internet

The front-end web application connects to the Services API endpoint via the Internet.

DNS Authority

The hostname alone does not identify any specific service instance. Instead, the service instance is referenced in the path, e.g. https://my.<region>.fredhopperservices.com/<service>:<instance>

Data API Node

Each of the Data API servers (or nodes) fulfil the following functions:

  • Authentication Each request gets authenticated based on the supplied account credentials

  • Processing Once authorised, the request gets processed. Depending on the type of the request, it might be either handled directly by the Data API node, or by other internal components.

  • Storage The data supplied via the Services API gets stored for a short period of time alongside the information regarding the trigger processing etc.

All Data API nodes have identical configuration and functionality, they also share the same underlying storage and processing clusters.

Mechanisms

Data flow (Full load, automatic id)

  1. The front-end prepares the data export, compresses it, calculates the md5 checksum and sends it to the Services API endpoint.

  2. The Services API endpoint DNS name gets resolved. The DNS authority answers with the external IP of one of the Data API nodes.

  3. The front-end sends the data to the IP address, indicating the service instance in the path and supplying the account credentials.

  4. The Data API node processes the request, verifies and stores the data and assigns it a data ID, which it sends back as the response.

Integration guideline

DNS resolving and caching

  • Make sure the DNS record is resolved each time before a request is sent and only send 1 request to 1 IP at a time.

  • Make sure the TTL advertised with the DNS record (30 seconds) is respected.

Implementation optimisation

  • For a given service instance, send the requests sequentially, awaiting the response each time. For example, if the data uploading process is still running, sending a trigger would result in a failure.

We register the DNS names for the API end-points with a 3rd party DNS service provider. To ensure high availability, each DNS record for the Services API endpoint contains a set of public IP addresses of our Data API servers and adheres to the principle. In short, this means that every time the DNS name gets resolved into an IP address that is different from the previous time. In order to minimise the chance of issues related to DNS caching, we set the to 30 seconds. Your Technical Consultant can provide you with a full list of the IP addresses in our range so that you can ensure that these are whitelisted on your-side, if this is required.

Round-Robin DNS
TTL