Edge++: Rails Framework

From Datonis
Revision as of 12:49, 12 June 2020 by Sayali (talk | contribs) (Pages and functions for operator screens:)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Factory Server

This is the main environment in which our operator screens will be developed and served to users. This by default runs on port no 3001.

  • In order to cache master data, one needs to schedule master_data_cache function with appropriate frequency. This function by default will cache models configured in generic edge_master_data_config. One can create account level function with the same name to override edge_master_data_config that suites one's use case.
  • Functions and pages (generic/account level) in which edge++ flag is true on production will be recurrently cached onto this local setup. One can always develop function/page on local setup directly keeping in mind the name should be uniquely different from any function/page present on production as we recurrently sync our database with production.
  • While developing functions for data processing one should update Redis keys as per use case which you can later refer in the operator screen.
  • To configure session time on local rails server we need to update ttl in edge.yml in edge_plus_plus repository

Branching Details:

We have created a long living branch edge++ in github factory repository. This branch is forked from rel_4.8_dev and have kept to its bare minimum so to have only UI components and Faas Infrastructure. On committing to this branch github action will create new docker container image on docker hub which is altizon/factory.

Developer Workflow

Developers should login using email and password. On successful login you'll see only single account for which license_key is configured in .env file.

Event processing function:

  • This function will be executed by factory rake task for every event. This event will be available in args[:event].
  • While performing business logic one should update contextual variables in Redis as per the use case.
  • This function should return processed event in the end which one wants to send to datonis
  • In case if we don't want to push anything in output queue, we should return nil in the end of this function.

On saving your event processing function, its name will be cached in Redis by background worker and will be available in Edge to be configured for related Adapter.

You need to click sync_edge___functions to get new function available in settings tab.

Following is the sample function screenshot:

Sample event processing function.png

Pages and functions for operator screens:

These can be developed on similar lines as done for production environment. All the UI components available in production factory environment are available here as well.

The pages and functions developed locally here should be committed by developers for version management.

Redis

Some well known keys that should not be directly touched by functions in Factory server are as follows:

Redis Key Significance
__access_key__ This should be account admin access key on Datonis. It is updated automatically once Edge is configured with access key.
__number_of_input_queues__ Degree of parallelism for processing event stream. This is internally updated while booting.
__faas_functions__ Set of names of faas_functions available in local MongoDB
__input_queue_i__ These are input queue names by default. Lets say if you configure number of input queues in .env file to be 5, these queue names will be __input_queue_1__ to __input_queue_5__
__output_queue__ The messages to be sent to Edge are pushed to Redis output-queue
__thing-key_alert_queue__ For each thing-key, 15 latest alerts are pushed to Redis. For example: __d9a3cb4f52_alert_queue__