OpenActive Developers
Data ValidatorDataset DashboardW3C Community Group
  • Welcome to our community
  • Publishing Data
    • Data Feeds
      • How an RPDE data feed works
      • Types of RDPE feed
      • Implementing RPDE
      • Testing RPDE feeds
      • Scaling RPDE feeds
    • Activity list references
    • Including geo coordinates
    • Schedules
    • Dataset Sites
    • Virtual Events
    • On-Demand Events
    • Opening Hours
    • Data Quality
  • Using data
    • Harvesting opportunity data
      • Large Integers in JavaScript
    • Tutorial: Consuming an RPDE feed
    • Attribution
  • Open Booking API
    • Key Decisions
    • Implementing booking
    • Testing booking
      • Configuring Test Suite
      • Implementing the Test Interface
        • Test Interface Actions
        • Create Opportunity Endpoint
      • Random Mode: Generating Test Opportunity Data
      • Running Test Suite
      • Generating the Conformance Certificate
  • Data Model
    • Data Model Overview
    • @context and JSON-LD
    • Types Reference
      • Action
      • AudioObject
      • BabyChanging
      • Barcode
      • BookingService
      • BooleanFormFieldSpecification
      • Brand
      • ChangingFacilities
      • ConceptScheme
      • Concept
      • CourseInstance
      • Course
      • Creche
      • CustomerAccount
      • DataCatalog
      • DataDownload
      • Dataset
      • DropdownFormFieldSpecification
      • DynamicPayment
      • Entitlement
      • EventSeries
      • Event
      • FacilityUse
      • FileUploadFormFieldSpecification
      • GeoCoordinates
      • HeadlineEvent
      • ImageObject
      • IndividualFacilityUse
      • InternalApplicationError
      • InternalLibraryConfigurationError
      • InternalLibraryError
      • Lease
      • LocationFeatureSpecification
      • Lockers
      • MediaObject
      • OfferOverride
      • Offer
      • OnDemandEvent
      • OpenBookingError
      • OpeningHoursSpecification
      • OrderItem
      • OrderProposal
      • OrderQuote
      • Order
      • Organization
      • ParagraphFormFieldSpecification
      • Parking
      • PartialSchedule
      • Payment
      • Person
      • Place
      • PostalAddress
      • PriceSpecification
      • PrivacyPolicy
      • PropertyValueSpecification
      • PropertyValue
      • QuantitativeValue
      • Schedule
      • ScheduledSession
      • SessionSeries
      • ShortAnswerFormFieldSpecification
      • Showers
      • Slot
      • SportsActivityLocation
      • TaxChargeSpecification
      • TermsOfUse
      • Terms
      • Toilets
      • Towels
      • VideoObject
      • VirtualLocation
      • WebAPI
  • Specifications
    • Specifications Overview
  • Useful links
    • Data Visualiser
    • Data Validator
    • Dataset Dashboard
    • Non-technical Guidance
  • OpenActive on GitHub
    • Overview
    • Activity List
    • Community
    • Controlled Vocabularies
    • Dataset Publication
    • Documentation
    • Implementation Support
    • Programmes
    • RPDE
    • SKOS
    • Specifications
    • Validators
Powered by GitBook
On this page
  • OpenActive Validator
  • OpenActive Test Suite
  • Step 1: Install the test suite
  • Step 2: Run validation
  • Manual Testing Checklist
  • Most common implementation error
  • Feed integrity checks
  • Last Page checks
  • Data quality checks
Edit on GitHub
  1. Publishing Data
  2. Data Feeds

Testing RPDE feeds

PreviousImplementing RPDENextScaling RPDE feeds

Last updated 3 years ago

Please note that all feeds must pass the OpenActive Test Suite in order to be usable by the largest number of data users. As described below, the interactive OpenActive Validator only validates the first 10 items / first 20 pages of a feed, whereas the OpenActive Test Suite runs the same checks over all items, in all pages, of all feeds.

OpenActive Validator

The interactive online allows the user to perform two types of validation:

  • : attempt to consume only the first 20 RPDE pages of an RPDE feed and check for common errors with the RPDE implementation

  • : depending on the data supplied, check either (i) an individual item, (ii) only the first 10 JSON-LD items in a single feed page, or (iii) an Open Booking API request/response for validity

The OpenActive Validator is useful during development to get instant feedback on the basic data structure and feed implementation, however it is not designed to comprehensively validate a complete implementation.

OpenActive Test Suite

The downloadable includes an option for comprehensively validating OpenActive open data feeds. Behind the scenes it runs the same checks as the for every RPDE page in the feed, and for every JSON-LD item in the feed.

The OpenActive Test Suite produces a results page that allows the user to explore specific errors with individual data items, by loading those items into the interactive OpenActive Validator.

Step 1: Install the test suite

Clone the test suite repository locally, and install its dependencies.

version 14 or above is required.

git clone git@github.com:openactive/openactive-test-suite.git
cd openactive-test-suite
npm install

Step 2: Run validation

Validation mode does not require any specific configuration, simply run the following command with the URL of the dataset site to be tested:

npm run validate-feeds "http://reference-implementation.openactive.io/OpenActive"

Manual Testing Checklist

Things to check to ensure the feed is implemented correctly.

Most common implementation error

Misreading the query in the specification is the single most common cause of incorrect implementation. Please read it carefully and ensure that brackets and comparators are used correctly. > not >= for example.

--include WHERE clause only if @afterTimestamp and @afterId provided
   WHERE (modified = @afterTimestamp
            AND id > @afterId)
      OR (modified > @afterTimestamp)
ORDER BY modified,
         id

Feed integrity checks

  • Does the next url work as expected and return a valid page - it should never result in a 500 error.

  • "modified" must always be an integer, afterTimestamp / afterChangeNumber must also be an integer.

  • Does the afterTimestamp or afterChangeNumber of the next url always increase with each new page - if not the query has likely been badly implemented.

  • There should be "deleted" items in the feed. If these are missing, it is likely the feed has not been implemented correctly.

  • The next URL should be an absolute not relative URL.

  • Are all responses returned with header Content-Type: application/json

  • Check for duplicate IDs: items should not appear more than once in the feed if the source data is unchanging.

  • Pages should contain at least 500 items (this is a warning rather than an error).

  • Are the next URL parameters urlencoded?

Last Page checks

  • Is the next URL present on the last page? The next URL on the last page should match the URL of the current page.

  • Check that the items array of the last page is empty

To quickly access the last page:

  • afterChangeNumber: Put a high integer in for afterChangeNumber to return last page

Data quality checks

  • Does the feed include all historical data from the beginning of time and not just data in the future or from today's date?

  • Does the endpoint without any parameters return the first page (from the beginning of time)?

  • Does each page contain a "license" key?

Please ensure that you have implemented correctly:

afterTimestamp: If "modified" is an integer, put a high integer in for afterTimestamp to return the last page. (N.B. the spec currently allows for strings to be used for "modified", but a future spec will likely ).

OpenActive Validator
RPDE validation
JSON-LD validation
OpenActive Test Suite
OpenActive Validator
Node.js
this query
make integers a must here