The ApiHawk Eventor is an API-based workflow automatization software and an event-to-function communicator. This means it works by creating specific chain reactions after a certain system process occurs. These are predetermined but at the same time flexible.&
The Eventor is versatile and highly customizable. Its main goal is to create automated system flows without the interference of a developer or changing the source code. It's a vital tool for Administrators as it is cost-effective, saves time on staff resources and on performing system operations.
This article will explain the main functionalities of the Eventor software. For full detail on creating an Eventor Flow, please click here.
It is so that there are other software that perform automated tasks. Still, Eventor makes for a good investment thanks to the fact it is so customizable. The tool doesn't require any modifications to its code in order to be tailored for the specific business or to automate system flows. Hence, it is subject to support at any moment and at low cost.
Moreover, the tool is designed to work with variables, which is how it can create so many different system flows. Each chain of actions Eventor sets would require specific data for the event to gather. Most times, the resources of the event are not configured to have access to that data directly. So ApiHawk's Eventor obtains any needed varying information by finding a chain of related resources, while other similar softwares only have a list of predetermined functions for each event. This makes other systems finite in their capabilities and functionality.
The Eventor works with Events and Listeners. Put together, these factors create numerous possible reactions the system can have to any occurring event, called Flows. Let's first see the definitions and details for all of them:
Events include all system occurrences in the Billia engine; they are automatically generated as Eventor entries the very first time they occur, e.g. when a user registers, when they place an order, when the system processes an order modification, etc. The Events section of the Eventor is mostly an automatically generated list of system actions, that are a part of the base to creating automatic system flows.
To check the list of all Events go to Billia Management Panel > Management > Eventor > Events.
An Event's title consists of the category of a resource, its version, and the name of the actual resource affected. That resource is affected by a specific system action, e.g. create, edit, delete, etc. This way, the title and the action comprise into an entire Eventor Event.
Database\V1\Label::update = Event's Category \ Event's Version \ Event's Resource :: the resource is affected by the system action to be updated
Events also work with and include variables. These variables depend on the type of the event and represent data relevant to it, i.e. the factors which comprise that event.
In the case where an event is about a new purchase being placed, the variables included would logically be the purchaseid, date, paymentid, and others related to the resource "purchase". But variables not connected to that resource and have no relation to that event, would hence not be included.
Note: Events can also be custom created, i.e. they can be created manually. In the case a developer or DevOps needs, they can use the backend code to manually create an event and trigger it in Eventor.
|ID||- The unique ID for that event.|
|Title||- The name of the system events. It contains specifics on the category of the event, its version, and secures that the event information has not been altered.|
|Action||- Specifies the system action for this event, the base of the event, e.g. create, renew, etc.|
|Example data||- See the variables and their information for the event.|
|Edit||- Edit the details on the event variables.|
Note: Altered event data creates a new version of that event (V2, V3, etc.), and a brand new entry in the Events section of the Eventor.
The Example data displays the event variables categorized by type and with their respective information.
The Listeners section of the Eventor consists of the actual functionalities that can be attached to events. Listeners are designed to carry out specific actions when set up in Flows, in order for a specific effect to be achieved in the system, e.g. for an email to be sent. Listeners are the second base part of creating an Eventor automated system flow. Listeners are pre-configured on the backend of the system and are usable from within the Management Panel. They have their own conditions.
New Listeners can be registered via API and created manually, when connecting a consumer to the Billia MQ server.
Example - Let's take the case where you need to create a custom Listener, which will add a user to your ticketing system via a specific protocol. You connect this custom consumer to the Billa MQ server and register the Listener via the Gear’s Listener API into the system, while specifying the exact params, that the consumer requires in order to operate.
Note: Listeners cannot be created or set up from within the Billia Management Panel.
|Details on Fields||- Displays all the fields for the Listener. These are its conditions - the type of information required by the Listener. E.g.- a Listener can have a field called "user_id" of type "text", which means that in order for that Listener to work properly, it needs that information entered as a simple text.|
|Edit||- Edit the Listener's fields and configuration.|
|Delete||- Delete the Listener.|
Please see an example of the Listener's fields:
Editing a Listener can modify its configuration and the information it requires. The Example below is for a Listener that would perform the action of sending an email to a customer, so it requires certain data to be able to perform that. Logically, in this case, that would include the user to whom the email would be sent and a base for the email (а template).
The Listener can be modified in its name, description, and fields. Already existing fields can be removed or modified, and new ones can be added, depending on how the Listener needs to be edited.
Note: Listener Fields are the conditions, or information, the Listener requires from the system in order for it to carry out its action correctly. The Listener Fields, much like the Listener itself, are custom and preset in the backend. The Admin who is creating an Eventor Flow completes the Listener Fields at the certain step of the Flow setup.
Flows are sequences of events and effects that follow each other. They are created manually by using Events, Listeners, and specific for the action variables.
|ID||- The unique ID of the flow.|
|Flow name||- The name of the flow, usually briefly explains its purpose.|
|Description||- More details for the flow.|
|Event||- Displays the system event used for the flow along with its unique ID.|
|Expand||- Expand the Flow to view the Listener(s) connected to it.|
|Modify||- Modify the Flow from here. Will take you through the entire process of setting it up in order to apply any changes.|
|Execute||- Manually execute the flow.|
|Add new||- Create a new flow.|
By default the preview list with Flows displays the Events related, but in order to view the Listeners, as well, one needs to expand the Flow from the respective button.
The Listener is then viewable and with available control options.
|Sort||- In case more than one Listener is present, their order of activity can be changed.|
|Activate/Pause||- Activate or Pause the Listener, which will effectively enable or temporarily disable the flow itself.|
|JSON description||- See the actual JSON details, including the rules for the Listener, actual message, and conditions.|
|Edit||- Edit the Listener, which will transfer over to a page to modify the parameters and their conditions.|
|Delete||- Delete the Listener, which will permanently deactivate that Flow. The details for the Flow will however remain in the list.|
According to the definition of Eventor, the Flows are automatic. Still, there is an option to execute them manually from the respective button. It is, though, needed to add JSON descriptive data to the execution process.
Due to its length and complexity, the information on creating or editing an Eventor Flow has been collected into a separate article. To view it, please click here.