Pulse allows building real-time finance data apps fast. To ease on-boarding Pulse we've outlined answers to common enterprise queries below.

Note, we do offer a SAAS hosted solution but unless otherwise stated the answers below refer to our self-hosted offering.

What type of software is Pulse?

  • Pulse is a server or desk application that runs using java.
  • It can run on every OS platform including windows, mac, linux.
  • It's a terminal application with a browser frontent.

How is it easiest to deploy Pulse Firm wide?

A single shared instance on a linux server which users then connect to via browser.
Additional options are available for horizontal scaling and failover.

Are packages versioned

yes, all installer and jar packages contain version information and are digitally signed using SHA384RSA to prevent tampering. Pulse uses semantic versioning and all changes are listed in the release notes.

How does licensing work?

Pricing is per user and detailed on our pricing page.

This pricing is based on companies that accept a low level support arrangement with minimal training and setup. If you are deploying Pulse to 100+ users contact us to discuss your exact requirements. We can offer up to 24x7 coverage within defined SLAs globally if required.

What are your terms and conditions?

See Pulse Terms.

Application

What is the architecture of your application?

Our architecture involves a java backend server based on the micronaut framework, connecting to data sources using the latest vendor supplied drivers, then forwarding the data to a react based client (Any chrome based browsers) via secure websocket. These are widely used industry standard frameworks that are best of breed in their area.

Which protocols are used for communicating?

Pulse uses:

  • HTTPS for serving web content.
  • Secure websockets for communication between browser and server.
  • Your selected JDBC drivers and configuration for onward communication to data sources. For example we provide the latest KX driver for kdb+ that allows for TLS encryption.

Is it self-hosted or SAAS?

We can provide either.

If accessible from the Internet how is our application instance isolated from those of others?

Smaller users receive a shared instance with App based controls to restrict access to only the data connections and dashboards they are permitted to. Larger customers receive a dedicated instance which allows greater security customization.

Where will our data be stored? Vendor-managed servers/databases, in the cloud?

Note: We do not host any databases or streaming systems, Pulse is only a frontend layer for displaying data. We hold data only for the smallest time possible to allow serving the UI and to provide caching. When Pulse is shutdown, no data is stored at rest. Pulse stores user queries used in dashboards.

Our SAAS cloud offering is hosted on Akamai/Linode.

Where does Pulse store it's settings?

Pulse stores all dashboards, database connection details etc. to one single database file pulsedb.mv.db. Pulse provides a number of actions to backup this data or H2 is a widely deployed database with associated tools for backup etc.

Resilience

Will our data be backed up?

Pulse can be backed up by regularly copying the single database file, or by exporting a restoration script from within the web interface.

Security

What type of Authentication is used?

Pulse allows configuring a range of authentication methods including:

You can choose which options to make available and even have full control by specifying a plugin.

Can we integrate our own SSO solution?

Yes. Either by using an Apache proxy or by using a custom plugin.

Does Pulse support kerberos? OAuth?

Yes. Pulse and QStudio use the same data engine. Data Intellect have implemented OAuth integration with QStudio at a number of firms.

Is access controlled? How is authorization handled?

Every user is linked to a specific role that dictates their authorized actions within the system. These permissions define the activities that a user is capable of carrying out in the system.

Does the solution use TLS? What are the configured cipher suites?

Our recommended solution is to place Apache proxy in front of Pulse.

Apache is an open source webserver started in 1995. Apache served 23.04% of the million busiest websites in 2022. Its proven stability, extensive documentation, and active community support make it a trustworthy option for firms seeking a secure and scalable web proxy solution.

If the solution accepts digital certificates. Does the solution verify their revocation status via CRL/OCSP/SCVP or other methods?

Yes. By default it verifies the certificates using the industry standard java certificate process. Firms can add their own cert to the keystore and can control the ciphers etc. accepted using environment variables.

Yes. If you use the Apache proxy your apache conf files (i.e. default-ssl.conf) using variable: SSLCARevocationCheck chain

Can you provide information on how the keys are generated?

Apache is an industry leading webserver used by 37,000 companies, it allows a range of key generation methods.
Openssl is one: https://docs.bitnami.com/aws/apps/dokuwiki/administration/create-ssl-certificate-apache/

Audit Trails

Where are the logs stored?

Logs are output to the terminal. All major user actions are captured in these logs in a structured format that would allow downstream processing.

Software

Are vulnerabilities documented and tracked to remediation?

Yes. Automated scans are performed on Pulse source doe and all upstream dependencies on a regular basis. Any dependencies found to have a vulnerability are upgraded as quickly as possible, typically within days. Any vulnerabilities identified instantly become our number one priority.

Are there managed processes for identifying and managing supply chain risks?

Yes. See comment above on vulnerabilities. In addition, all official builds are only build on secure servers via github actions. That package is then signed with our software key and automatically uploaded to the website. No human or desktop PC is used for building the released package. All changes are via auditable processes that require sign-off.

How is the software tested?

We use an automated build process with testing at each step and subsequent manual testing:

  1. JEST is used to test the react frontend.
  2. JUnit is used for testing the server backend.
  3. Integration Tests are then performed on the combined package, including headerless browser tests that verify screenshots look valid.
  4. Manual tests are ran on Windows/Linux/Mac using Chrome/Edge and Firefox.
    (Note FireFox is not officially supported but is tested as it can highlight edge cases.)
  5. A limited roll-out for internal usage is performed and validated.
  6. General users can then download the update from the website.
  7. Finally on a periodic basis we nominate LTS versions for our larger enterprise customers.

Do you deliver software updates to clients through automatic downloads?

Currently no. Our clients are large firms with highly customized release processes, they prefer to manage it themselves and be in full control. If you would like release via a store platform please let us know and we can consider the request.

Do you offer software Escrow?

Yes. Customers can receive full access to all Pulse source code.

Enterprise Only Features

Vendor Onboarding

Are you an official vendor to our company?

We may be, you would need to check your internal system, search for Timestored Ltd.
In the past we have onboarded via third-parties including SHI.

If onboarding is required, this is a process we have completed numerous times and can provide assistance to complete.

What are you company details for Vendor purposes?

  • Our Address: 74 Medland House, 11 Branch Road, London, UK
  • Email: info@timestored.com
  • Phone: +44 (0) 20 3397 7535
  • Company Number: 8342890
  • VAT Registration Number: 153 1258 34
  • DUNS Number: 218757681

Company policies for Vendor onboarding?

Some documents useful for onboarding include:

What else do you offer enterprise customers?

  • Defined Support SLAs
  • Onsite Visits - At start of contract to enable setup and requirements gathering
  • Monthly Scheduled Calls to agree development priorities and roadmap items
  • Initial Online Training Sessions