importer

Sistema de Alertas-Notificaciones de Eventos

Se requiere de poder configurar mediante un tiempo la frecuencia de las alertas, para lo cual un usuario configurará los tipos de eventos con su respectivo tiempo.

Importer Dir
Account has_many :importer_logs

ImporterLog
account_id, user_id, total_rows, status (error, en_cola, procesado, etc), importer_log_candidate_id:references
belongs_to :importer_log_candidate
has_one_attached :file

ImporterLogCandidate (se sube a aws para previsualizacion)
file_path, status, preview_quantity
has_one :importer_log




Alcance primera etapa:

Importadores
---fecha-vencimiento
----tipo-documento

---Agregar documentos una vez creado el vehiculo
Revision Tecnica




eventos
stop: Velocidad de detención
overheating: Máxima temperatura
speeding: Máxima velocidad


Soluciones
1-Se creará un modelo de Configuración para los eventos

EventsConfiguration(id: integer, account_id: integer, event_type: string, event_attribute_value: float, frequency_time: integer, created_at: datetime, updated_at: datetime)

El cual tendrá relación con la cuenta. Una cuenta puede tener muchas configuraciones de eventos.
Dependiendo del evento algunos pueden tener una variable especial event_attribute_value, como es el caso de "speeding", "overheating" y "stop", en donde por ejemplo el evento "stop" esta asociado a la velocidad de detención de un vehículo.

Ejemplo de la configuración para evento "stop" para la cuenta (donde se aprecia el valor de event_attribute_value en 1.0, lo cual indica que a esa velocidad el vehículo se detendrá, a su vez posee una frecuencia de 5, lo cual esta expresado en minutos)
id: 21,
account_id: 1,
event_type: "stop",
event_attribute_value: 1.0,
frequency_time: 5

Ejemplo de configuración para evento "inside_origin_warehouse", el cual no necesita el atributo event_attribute_value, solo importa su frecuencia.
id: 22,
account_id: 1,
event_type: "inside_origin_warehouse",
event_attribute_value: nil,
frequency_time: 5

De este modo se pueden configurar los tipos eventos y sus frecuencias para una cuenta y posterior alerta.

1.1 Alertas-Eventos

-Una vez se ha configurado la frecuencia y valores de las alertas, se debería poder enviar alertas con el valor frequency_time, para lo cual con el modelo actual, es un tanto engorroso esto debido a:

Al momento de mostrar cada uno de los eventos por frecuencia (posible endpoint), se debería consultar por el antepenúltimo
registro en la base de datos (por tipo) y revisar sí hay una diferencia entre el valor de started_at de ambos (último y antepenúltimo) y si coincide con la frecuencia configurada para ese tipo de evento.

PSeudoCode
Controller
@trip = @trip = current_account.trips.where(id: params[:id], active: true).first
# se obtiene el antepenúltimo evento por tipo para un viaje
last_events = %w[overheating speeding stop].map do |el|
   Event.where(trip_id: @trip.id, event_type: el).select(:id, :event_type, :started_at, :created_at).second_to_last
end.compact
# se obtienen las configuraciones de eventos para la cuenta actual
configurations = current_account.events_configurations.select(:id, :event_type, :frequency_time)

EventSerializer
attribute :event_configurations do |object, params|
   configurations = params[:configurations].as_json
   last_events = params[:last_events].as_json
   frequency_event = configurations.detect{|el| el['event_type'] == object.event_type }['frequency_time']
   ant_event = last_events.detect{|el| el['event_type'] == object.event_type }
   ((object.started_at - Time.parse(ant_event['started_at'])) / 1.minute) == frequency_event
end

PseudoCode Solo Controller
def trip_events
          from = parse_datetime(params[:from])
          result = from.present? ? @trip.events.filter_by_created_at(from) : @trip.events
          result = result.not_internal
          antep_events = %w[overheating speeding stop].map do |x|
            Event.where(trip_id: @trip.id, event_type: x, ended_at: nil).select(:id, :event_type, :started_at, :created_at).second_to_last
          end.compact.as_json
          configurations = current_account.events_configurations.select(:id, :event_type, :frequency_time).as_json

          final = result.map do |object|
            frequency_event = configurations.detect{|el| el['event_type'] == object.event_type }['frequency_time']
            ant_event = antep_events.detect{|el| el['event_type'] == object.event_type }
            object.id if ((object.started_at - Time.parse(ant_event['started_at'])) / 1.minute) >= frequency_event
          end
          result = result.not_internal.where(id: final.compact)
          render json: json_api_serializer(path: 'events_api_v1_activities_trip_path',
                                           object: result,
                                           resource: Event)
        end

Se debe Agregar columna read:boolean a modelo Event, además de varios scopes como el de unread

PRO:
Quizás puede ser una forma rápida de la solución

CONTRA:
El performance es bastante perjudicial al realizar tanta comparación.

2- En un comienzo se utilizaría el punto 1 para los eventos y configuraciones
2.1 - Alertas-Eventos

Se crearía un modelo Notification
notifiable, events, trucks, etc
Notification(:account_id, :notifiable_type, :notifiable_id, :read:bool)

Una vez que se dispara un evento con el algoritmo de procesamiento de puntos, mediante algún servicio más un worker se procesarían las alertas

PseudoCode
frequency_time = account.events_configurations.where(event_type: 'event_type').frequency_time
Se verifica si existe una notificación, sino se crea, luego cuando llegue la segunda notificación, se verifica el tiempo
actual (started_at) del evento y de la última notificación, si estos dan como resultado que valor de la frecuencia para ese tipo de evento es mayor o igual se envía otra notificación

last_notification = Notification.where(notifiable: event)
event_stop = Event.started_at
((event_stop.started_at - last_notification.created_at) / 1.minute) >= frequency_time

PRO:
Se delega la responsabilidad en un modelo con relación al evento
Mejor performance
Reutilización de modelo para posteriores alertas

CONTRA:
Dependiente de algoritmo, realizar algunos cambios