Ah, Services…they’re a centerpiece of Vantiq’s low-code, event-driven strategy; easy to modularize, share, and maintain. For developers who like tight, tidy and reusable grouped resources dedicated to accomplishing specific jobs, Services are perfect for this.
Conceptually, Services take in events, process them, and send out changed events with the desired outcome(s):
But, have you noticed over the last couple of releases or so, Vantiq Services seem to have been getting “pickier” about the kinds of events that enter?
Public?
Private?
Source? Service?
Topic; really?
And these are in the Implement Tab, not the Interface Tab?
Yeah, let’s discuss.
First: The Interface Tab Events
Here’s familiar ground. Click on those plus signs and set up Inbound and Outbound events with their schema.
Do the incoming event origins matter? Nope; as long as you can direct them to the incoming Service Event yourself. This was done in the past with Internal Event Handlers that could process events right where they were or be published to the incoming event type of the same Service without coding. Alternatively, we could write a Rule that intercepts the event and redirects it via a Publish statement to the incoming Service Event, e.g.:
RULE Interceptor
WHEN EVENT OCCURS On “/sources/someAPI”
PUBLISH event.value to SERVICE EVENT “z.z.biff/SendToMe”
Thus, Services aren’t any “pickier” than they’ve ever been. Vantiq integrates; that’s one of its super powers. What’s changed is that Vantiq has made it easier to bring events from anywhere into Services.
So, wrapping up the Interface Tab events: These will enter the Implement Tab as Public Events. Upon starting a Visual Event Handler for them, the resulting EventStream will already be configured from the Interface settings and not changeable:
Next: The Implement Tab Events
The Service Builder UI has undergone a few changes of late, mostly in the Implement Tab, and for greater developmental clarity. Instead of dumping every event not directed exactly toward the Service into an “Internal Event,” now we have easy-to-understand categories for them. And not just for events, but for Procedures, too!
Private Events, like Private Procedures, aren’t visible or accessible from outside of the Service. For instance, a Rule trying to publish directly to a Private Event will generate an error:
But Publishing to it from inside the Service works just fine.
Source Events are sourced from, well, Sources. The EventStream for this is an orange color to distinguish it as a source EventStream. 
By Sources, of course we’re referring to anything from an MQTT message … to something from a remote API, an Enterprise Extension, etc.
There’s a curious thing about Source and Service Events from this UI, however, and that is that they can be configured to be something else. And if you do configure them to be something else, upon saving, the Service neatly lists the Event in its proper place:
Notice that by default, neither Type nor Topic Event Handlers appear in the Implement Tab Event Handler list…but they do if there’s an event for them!
Service Events take input from Service Event, yes; but these can be either Inbound or Outbound. This is very handy from an asynchronous event processing standpoint – an event sent to one Service could be simultaneously received by one or more other Services for processing:
Or, the event flow could be chained from one Service to another:
The connections, and therefore the applications, are limitless, depending on which Service Events are set as the intake for event flow processing.
In Conclusion, here’s what it looks like to have at least one of every type of Event Handler possible:
And my question is this: Do you agree having all the different types of Event Handlers categorized like this makes the Service “tidier” and easier to understand?
Your comments are welcome below!
As always, at Vantiq, we hope we’re continuing to make your job developing real-time, aware and smart systems ever easier.