Блог

Я новичок в drools / fusion (7.x) и не уверен, как решить это требование. Предположим, что у меня есть объекты событий в виде события{long: метка времени, идентификатор: строка}, где идентификатор идентифицирует физический актив (например, трактор), а метка времени представляет время, когда событие произошло относительно актива. В моем сценарии эти события не поступают в мою систему в «реальном времени», что означает, что они могут опаздывать на секунды, минуты или даже дни. И моя система правил должна отслеживать несколько активов. Учитывая это, когда правила оценивают, часы должны быть относительно отслеживаемого актива, это не могут быть часы, охватывающие активы. Я знаю о Псевдочасах, есть ли способ назначить псевдочасы для каждого актива?

Я предполагаю, что часы всегда должны двигаться вперед, иначе временные функции не будут работать должным образом. Возьмем для примера следующий сценарий: Факт А для актива 1 прибывает в 1:00, он вставляется в память и правила срабатывают. Затем факт B прибывает для того же актива 1 в 2:00. Он тоже вставляется и правила срабатывают. Теперь Факт Z прибывает для актива 2 в 1:30 (- 30 минут от времени). Я предполагаю, что мне не следует просто переводить часы назад и оценивать, кроме того, я бы хотел вернуть время на 2:00, так как это были «последние» данные, которые я получил. Теперь предположим, что я отслеживаю тысячи активов, и все они отправляют данные в разное время…

Лучший способ, который я могу придумать, чтобы решить эту проблему, — это сохранить часы для каждого актива, а затем сохранить состояние двигателя при оценке данных каждого актива. Могут ли отдельные сеансы KieSession иметь разные часы или они находятся на уровне контейнера?

Пример правила: Когда Факт 1 приходит после факта 2 для одного и того же актива.

Вы неправильно подходите к проблеме. Независимо от того, используете ли вы часы реального времени или psuedo, вы используете часы. Вы не можете сказать: «Факт № 1 использует часы A, а факт № 2 использует часы B.»

Вместо этого вы должны использовать теги метаданных для событий, в частности @timestamp тег. Этот тег указывает Слюням, что определенное поле внутри события на самом деле является меткой времени для События, а не фактическим временем, когда факт попадает в рабочую память.

Например:

 import com.example.SampleEvent

declare SampleEvent
  @role( event )
  // this field is actually in the object, it's not the time the fact was inserted
  @timestamp( createdDateTime ) 
end
 

Не зная ничего о том, что на самом деле делают ваши правила, основная проблема, которую я могу здесь предвидеть, заключается в том, что если ваши правила полагаются на временные операторы или определяют срок действия ( @expires ), они не будут работать, и вам нужно будет их перепроектировать. Особенно для истечения срока действия: как только событие истекает, оно удаляется из рабочей памяти; когда приходят ваши внеполосные события, все ранее истекшие события уже исчезли и с ними нельзя работать.

Конечно, это беспокойство было бы справедливо независимо от того, используете ли вы @timestamp или ваш первоначальный план «другие часы psuedo». В любом случае вам придется смириться с тем фактом, что события не могут вечно храниться в рабочей памяти-в конечном итоге у вас закончатся ресурсы, и ваша система выйдет из строя. События должны быть удалены в какой-то момент, поэтому вам нужно будет разработать это как в ваших моделях, так и в ваших правилах.