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>
  ++++
  
  Once the `Use case` and `User name` are provided the process will create a new transaction context event and push it
  to the Kafka topic and completes itself.
  
  After the missing transaction context data event has been put on the topic the log enricher will resume its operation
  and you will be able to see in the logs the following lines:
  
  [source, plain]
  ----
  
negative.code: </div>
  ++++
  
  As illustrated above, both processes are initiated based on an 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
  