Hi,
I noticed that the Unary Protocol Thread feature was not covered in the training, do you have any suggestion on how I would go about learning that material? Right now my organization is investing in my training (i.e. I need stuff to do and this looks good).
Thanks,
Ben
There’s no training materials b/c there’s so few use cases.
The best way to learn is to examine the two integrations that use it:
Clover is a point-of-sale hardware device, so it is impossible to test without their POS hardware. The Clover integration is an example of a “global webhook”, where Clover has a single webhook to the APIANT system and all data for all customer accounts flows through that single webhook.
Jabber is another example:
Jabber is easier to test. Jabber is already running on dev.apiant, so you would have to copy the assemblies and run your own protocol thread via the admin console to test your own.
“Per-Trigger Protocol Threads” are documented on page 105 here:
They have not been used yet, so no examples are available. The reasoning for adding was b/c we have a customer who eventually wants to have automations invoked by messages placed into message queues. The thinking is that each trigger needs a listening thread to monitor for new messages placed into message queues.
So, it seems that the rationale for protocol threads depends on sockets. If you need to use a protocol thread, then you need to be using a socket, is that correct?
I’m not familiar with socket programming, do you care to add anything to my education in that area?
Also, it seems that automations are all already running and listening for events in parallel, so why do we need to introduce threads here…well, that must go back to the fact that we need to maintain a socket sometimes, right?
Protocols typically use sockets as the underlying transport. Typically a Java library is used within protocol threads instead of doing raw socket programming. E.g. for the Jabber integration a Java library called Smack is used for the XMPP protocol.
No, automations do not directly listen for events, except for per-trigger protocol threads which haven’t been built yet. All automations are currently invoked via a work queue. Work is placed into the queue when webhooks are received, when it is time to execute the automations based on their polling cycle or date/time triggers, or when data is received via a unary protocol thread.
A work queue is necessary to avoid exhausting server resources and to scale processing by adding more servers.
OK, I think I understand all this. Thanks for your explanations!