Difference between revisions of "Edge++: Rails Framework"
(Tag: Visual edit) |
(→Pages and functions for operator screens:) (Tag: Visual edit) |
||
(5 intermediate revisions by 2 users not shown) | |||
Line 8: | Line 8: | ||
== Branching Details: == | == 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. | + | 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 == | == Developer Workflow == | ||
Line 18: | Line 18: | ||
* This function should return processed event in the end which one wants to send to datonis | * 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. | * 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: | ||
+ | |||
+ | [[File:Sample event processing function.png|border|800x800px]] | ||
+ | |||
+ | ==== 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 == | == Redis == | ||
Line 36: | Line 48: | ||
|__input_queue_i__ | |__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__ | |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__ | ||
|} | |} |
Latest revision as of 12:49, 12 June 2020
Contents
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:
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__ |