anchor.diff:  </div>
   ++++
   
  -or try it yourself by running the https://github.com/debezium/debezium-examples/tree/master/auditlog[audit log example].
  +Or try it yourself by running the https://github.com/debezium/debezium-examples/tree/master/auditlog[audit log example].
  
positive.code: </div>
  ++++
  
  As illustrated above, both processes are initiated based on incoming message. Then the logic afterwards is significantly different.
  
  The “Transaction context data” process is responsible for just retrieving the event and pushing it into processing phase - that
   essentially means to insert it into the so called “working memory” that is used for rule evaluation. And at that moment it’s done.
  
  The “Vegetable event” process starts in a similar way… it retrieves the message and then (first ignore snapshot messages
  in the same way as the log enricher service) will wait for a predefined amount of time (2 seconds) before matching
  vegetable and transaction context events. Once there is a match it will simple finish its execution. But if there is
  no match found it will create a user task (that’s a task that requires human actors to provide data before process
  
negative.code: Looking at the logs you can identify that it actually refers to the entry we just inserted (id 106).
  In addition to that, it refers to missing transaction context data that it cannot find. That is the
  consequence of doing it manually on database level instead of going through the  vegetable service.
  There is no corresponding data in the `dbserver1.inventory.transaction_context_data` Kafka topic and thus the log enricher cannot
  correlate and by that merge/enrich them.
  
  == Kogito to the rescue
  