In opscotch version 3, file access was introduced, along with the fileWatcher step trigger. File watching is a capability that allows you to request the agent to call a step when a file is changed—for example, when a log file is updated, you can receive the new lines as a step payload. As security is always a top priority, file access is strictly controlled in several ways.

An exciting change in version 3 of opscotch is the introduction of workflow-available high-performance persistent FIFO queues. This was the missing functionality that allows opscotch workflows to robustly buffer outbound data - essentially acting as a log aggregator, among other uses.

In opscotch workflows, by default, a step can be run at any time, even if there is already a run on that step — meaning this step can be executed in multiple threads. But what if you want to enforce single-threaded execution for a step?

With the addition in version 3 of file access and HTTP listening (you should read those blog posts first), the combination of these two features allows for serving static content, i.e., images, HTML, JavaScript, etc., from opscotch. As security is always a top priority, HTTP requests for static content are strictly controlled in several ways.

Opscotch has been designed to make HTTP calls to HTTP-enabled services like APIs and websites. As security is always a top priority, HTTP calls are strictly controlled in several ways.

A new feature in version 3 of opscotch is the capability to access files. As security is always a top priority, file access is strictly controlled in several ways.

An exciting new feature of version 3 of opscotch is the capability of listening for and responding to HTTP requests using workflows - essentially turning opscotch into an application server. As security is always a top priority, HTTP serving is strictly controlled in several ways.