Most systems integrate today through APIs or direct database connections. Enterprise services buses are becoming a more popular alternative to API when it comes to creating integrations.  Events can easily be processed through ESB when they arrive or when the event happens.  Today most UI-based applications function based on trigger events; for example- when you click on a button, the code behind the click event of the button performs certain functionality and fires off a "next step" or "task". Take that same concept and apply it to the back end and you can perform functions when events fire off. We explain more below.  

There are many Enterprise service bus applications available to users so it's hard to decide between commercial and open source options.  FlowWright also includes a high-performance Enterprise Service Bus (ESB).  The next version of FlowWright integrates with many of the common ESBs, such as RabbitMQ and MSMQ. Triggering workflows can be based on events coming into these ESBs, but also on the ability to generate events with parameters into these common ESBs.

So, how do you collect data using events, and what do you do with it?  Events are not just "events" they carry data through their parameters.  Workflow processes today hand over processing to the ESB, whenever multiple systems need to be updated, the process will generate events to the ESB; where the workflow process can end processing and then hand over the processing to the ESB. 

Most hardware-based systems such as Universal Distributed Controllers (UDCs) can generate events in external systems through many ways.  Either through REST API calls, or other Network API functions, these events can carry data that participate in decisions or computations.  Most hardware devices perform functions based on events, but software events are also powerful in moving data between components or systems.