📄️ Event processing
Event-driven architecture is an asynchronous architecture pattern used for scalable systems. The role of an event-driven system is to detect, consume and produce events.
📄️ Design patterns for event processing
Event-driven architecture gives you a type of solution where events are key. An event is something that happens in the real world, has a business meaning, and carries information. Depending on the business case and on system requirements, different patterns will emerge that turn out to achieve the best result. They can be classified as:
📄️ Event processing best practices
When you create an event processing model in USoft, you look at data flow in terms of information items that must be filtered and combined to achieve your goal. Multiple flows of data are processed continuously at the back end, without user interaction.
📄️ Event processing: Receiving events
Receiving events is about processing input events. An input event that is in scope for a USoft solution is something that happens in the organisation, is relevant to business conduct, and of which a signal is received by the USoft solution. The signal takes the form of an incoming message.
📄️ Handling events
The Rules Engine is responsible for handling received event data by processing business rules that apply to this data. These business rules are defined in USoft Definer.
📄️ Event handling Example 1: Job that processes queued input events
The following step-by-step instructions are for creating a job that processes queued input events. In the example, these are reservation events for a Travel Agency model.
📄️ Event handling Example 2: Queue service that processes input events
The following step-by-step instructions are for creating a queue service that processes incoming reservation events for a Travel Agency model in an asynchronous fashion.
📄️ Producing events
Producing events is about creating output events. An output event is a business fact that is deemed relevant for software outside the USoft application itself, and therefore is registered ("created") by the Rules Engine as a fact that must be advertised (signalled) externally.
📄️ Event production Example 1: Model and rules for creating output events
The following step-by-step instructions are for creating a data model and rules that will store output events for a Travel Agency model. The example is part of an asynchronous output processing pattern.
📄️ Event production Example 2: Job that processes queued output events
The following step-by-step instructions are for creating a job that processes output events.
📄️ Event production Example 3: Queue service that processes output events
The following step-by-step instructions are for sending an output event from a Travel Agency model. The example is of an asynchronous output processing pattern.