SyncJS on the Connector Preview

SyncJS is Syncplify's JavaScript dialect. The Storage Connector embeds the same engine that Syncplify Server and AFT use, so a large part of what you know from those products carries straight over, and so does most of the code.

A SyncJS script on the Connector runs when a file event fires: someone uploads a file, deletes a folder, renames something. An event handler is what binds the two together.

Where it runs, and what that means

Scripts run inside the Connector process, on your hardware, next to your files. Nothing about them travels to SFTP.cloud: not the source, not the output, not the data they touch. Syncplify cannot read your scripts and cannot run them.

That cuts both ways, and it is worth being blunt about it:

A script is code you are choosing to run on your own machine

It runs with the privileges of the Connector service account. It can read and write the local disk, start programs, open outbound network connections, and reach any database or API it has credentials for. It is not sandboxed away from the host. Treat the script editor with the same care you would treat shell access to that machine, and see Administrators for who is allowed near it.

The shape of a script

There is no wrapper, no entry point and no exported function. The source is the program, and it runs top to bottom.

// Refuse uploads of Windows executables, and say so in the log.
var name = CtxRelPath().toLowerCase();
if (name.endsWith(".exe") || name.endsWith(".dll")) {
    Log.Warn("refused executable upload: " + CtxRelPath() + " by " + CtxUsername());
    Exit(1);
}

Three things in five lines, and they are the three things nearly every script does:

• CtxRelPath() and CtxUsername() read the event context: what happened, to which file, on behalf of whom.
• Log.Warn() writes to the Connector's own log.
• Exit(1) stops the script with a non zero code, which on a before event means refuse the operation.

What a script can reach

Area	What you get
The event context	Which file, which user, which virtual file system, which event
The current virtual file system	Read and write through the same layer the user does, encryption at rest included
The local file system	The Connector host's own disk, listing, copying, hashing, zipping, splitting
HTTP and SQL	A fluent HTTP client and a client for eight database engines
Remote transfer clients	SFTP, FTP, FTPS, S3, Azure Blob, Google Cloud Storage
Message queues	AMQP 0.9.1 and AMQP 1.0
Notifications	Email, Slack, Microsoft Teams, Telegram, Twilio SMS
The secret store	API keys and passwords your scripts read by name, instead of carrying them
PGP	Key generation, encrypt, decrypt, detached sign and verify
Images	JPEG and PNG resampling, EXIF extraction
Running programs	Launch anything on the host, optionally capturing its output

The complete list of names the engine defines is on Every global, A to Z.

If you already know Syncplify Server

Most of it is identical. The differences are real, though, and a script copied verbatim from a Syncplify Server installation will usually need a small edit before it works here.

The short version: the Connector has its own set of events, has no user object and no virtual sites, and cannot terminate a session or challenge anyone for a password. Its secret store and its SMTP and Telegram settings belong to the Connector rather than to a virtual site, so GetSecret, SendMail and NotifyViaTelegramBot work once you configure them here. Everything else, the whole standard library, is the same.

The long version, with a line for every difference: If you know Syncplify Server. Read it before porting anything.

Where to start

1. Writing and testing a script
2. Events and when they fire
3. The event context
4. Worked examples