Extension Review and Certification Process

In Enterprise environments, MQTT Brokers are rarely deployed without deep integration to existing systems. HiveMQ was built to be ultra-flexible and can be integrated with virtually any existing application for message processing, security, monitoring or complex business logic. The open extension system allows to hook in almost any functionality to the MQTT messaging core. The HiveMQ extension review process ensures that your custom-built extension scales with your broker deployment and the broker installation. This saves you and us a lot of time and increases the quality of your extension.

Your Extension Review Advantages

• The extension review makes sure that your extension is ready for production and peak load scenarios.

• We analyze the extension for potential performance and scalability issues and suggest fixes for these
  issues.

• All successfully reviewed extensions are 100% supported by our support team for existing 24/7
  HiveMQ installations.

• You will receive a Review document with recommendations and hints with different action levels
  including actionable recommendations to achieve even greater scalability, performance or use case
  improvements.

• We will run a performance test of your extension within a simulated infrastructure that mirrors your
  setup and the peak load.

• You will receive a Load test document and the related HiveMQ Swarm scenario, that is designed for
  testing your use case.

Steps of the Extension Review and Certification

• You fill out this extension review ticket including the extension source code and accompanying
  documents (like architecture and business case documents).

• The Professional Services team will start with the extension review process. If some is missing or
  unclear, we will get in touch with you and will discuss further issues.

• After the review phase, we will send you a detailed extension review document that shows potential
  issues categorized in different severity levels, together with actionable recommendations to improve
  the extension.

• The reworked extension will be sent back to us so that we can start the second phase of certification.

• If no issues are revealed that endanger a production deployment, we will execute a performance test
  and finally you will receive the results, the performance-test setup and the certification for the
  extension.

• In case of adding new Features, you can submit the extension code again for a short Recertification,
  with less effort.

Extension Review Prerequisites

To perform the review process, we include information about the files that should be provided:

Source Package

• Source Code
  Complete source code package (.zip/.tar.gz) with all external libraries provided. It is important that all dependencies are included.

• Build Instructions and build files
  All of the required build files, binaries and set of instructions on how to build binary package. Build process should be performed to make sure that all of the files are included. It is important, as some missing files may forbid from building the binary

• Configuration files
  Some custom extensions may require external configuration files to configure extension operation. These files should be included in the package with clear description of configuration options.

External Integrations information (If any are present)

Extension might communicate with external systems for proper operation. It is vital that information about these integrations is gathered and they well described.

Approach A: Integration using mocks of external systems (recommended)

External systems can be simulated using mocks. This allows for testing the extension in isolation and a full control over communication, so performance testing results are repeatable and concentrate on extension performance. Choosing this approach is an simplification of an actual, real deployment so some considerations have to be taken into account:

• mock are only a mockup services that simulate parts of real system

• mocks will not reflect the impact rate of messages and connection rates have on an actual, real system

• mocks need to be correctly configured with latencies to be as close to real system as possible

• compared with real system - mocks may handle much more traffic as there is a limited business logic in them

• as mocks will be deployed in the same network space as the extensions, network latencies may be lower than in real system.

Required documentation and files:

• High level connectivity diagram
  To show the interconnections between the extension and external systems. Should show the types of connections and protocols used information about payloads that are exchanged

• Description of external systems connected
  Some extra information about external systems should be provided, which specifies their responsibilities. This information should include: latencies, supported rates of messages, connection rates, explanation of mechanisms employed when overloaded

• Mocks of external systems (binaries and or source code)
  In order to test the extension in an isolated environment, mocks of external systems need to be deployed. Deployable and configurable mocks of such dependencies should be provided by the client.

• External mock configuration files
  Mock configuration files should be provided. Options documented. Configuration file should allow control of the network addressing to allow flexibility in test environment deployment and ensure connectivity.

Approach B: Integration using real running systems for which access is given.

Extension also can be tested by setting up test environment in such a way that real running external systems are contacted. These systems would be part of client infrastructure deployment. For this to be successful, certain conditions have to be met.

Some concerns need to be considered when using this approach:

• External systems need to be exposed and accessible

• Load testing of the extension will impact the external systems used by extension

• Due to network communication, latencies may be affected

Required documentation:

• High level connectivity diagram
  Shows the connectivity and entry points to able to reach external systems. These need to exposed in such a way that connection is able to be established from Test Environment

• External system connection data
  All data that is required to connect to the external services needs to be provided. Thos should include network address/port and/or URL + User/Password/API Key data.

• Sample request to test connection to each external system
  A clearly described way to test the connectivity, send request and obtain a response

• Confirmation that no personal data will be processed/returned when requesting data from external systems