Work with functions

Best practices and considerations when working with functions using the Skedulo CLI.

Overview

Connected functions are server extensions in Skedulo that make it possible to integrate with third-party systems and use custom code to implement organization-specific functionality. For example, connected functions can be used to update records based on triggers, send SMSs, or connect with other software systems to get or send data.

Connected functions are used in any scenario where additional backend functionality is required within the Skedulo product to achieve the rapid development of new features on the platform and in the mobile application.

Skedulo CLI commands for connected functions

The CLI commands are grouped into logical groups, or topics, for ease of use. The commands relevant to connected functions are listed in the table that follows.

CLI command Description
$ sked function dev Set up a local development connected function.
$ sked function generate Generate a connected function template.
$ sked artifacts function upsert Create or update a function from a state file and bundle folder. This command replaces the deprecated create and update commands.
$ sked artifacts function delete Delete a connected function.
$ sked artifacts function list Get a list of all existing functions.
$ sked logs function Fetch a function’s execution logs. Skedulo CLI Studio’s log viewer opens the same view interactively.
$ sked http Send a request to a function that runs under sked function dev, or to the Skedulo API, with your saved access token.

Test a function locally

Use sked function dev and sked http together to test a function on your machine before you deploy it. sked function dev runs the function as a local server. sked http sends a request to that server and attaches your saved access token, so the function can call the Skedulo API as you. You do not copy a token into an .env file or a -H flag. When your saved token expires, log in again with sked tenant login web, and the next request uses the new token. Both commands need a saved tenant, so log in first with sked tenant login web if you have not. This requires CLI version 5.1.4 or later.

  1. Build the function. The dev server runs the compiled handler in the dist folder of the function directory. In that directory, run yarn bootstrap once to install the dependencies. Then run yarn compile, or run yarn dev to rebuild each time you save a file.

  2. Start the dev server on a fixed port. Without -p, the server picks a random port and prints it.

    $ sked function dev ./my-function -p 3000

  3. In a second terminal, send a request to the server. The template that sked function generate creates has a GET /ping route and a POST /action route.

    $ sked http http://127.0.0.1:3000/ping

$ sked http http://127.0.0.1:3000/action -H "Content-Type: application/json" -d '{"hello":"world"}'

    The response from /action includes the user name from your token. That confirms that the function received it.

The dev server loads the handler again on each request. After you rebuild the function, send the request again. You do not need to restart the server.

To test how the function behaves without a token, add --no-tenant-token to the sked http command. If your .env file sets AUTH_TOKEN, remove it and restart the dev server for this test, because the function can still receive that token. For why to avoid AUTH_TOKEN and how to keep tokens out of Git, see sked function dev. To test with a different token, pass your own -H "Authorization: Bearer <token>". sked http sends that header as you typed it. Start the value with Bearer and a space, with a capital B. The function rejects any other value, and its error response and log repeat the value that you sent. The token that sked http sends decides which tenant the function acts on. The --alias flag on the dev server only picks the API host. If you start the dev server with --alias, pass the same alias to sked http, so that both commands use the same tenant.

sked http sends your token only to a loopback address (127.0.0.1, [::1] or localhost) and to your tenant’s API. Any process that listens on the port receives the token, so use --no-tenant-token if a forwarded port could reach a remote service. For the full rules, see Token attachment.

You can also send the same request from the HTTP client in Skedulo CLI Studio. Run sked http with no URL to open it.

View function logs

A connected function runs on Skedulo’s servers, not on your machine, so you cannot attach a local debugger to it. sked logs function fetches that function’s execution log for a time range, so you can inspect requests, errors, and console output instead of waiting on a separate dashboard. Use sked logs tail --artifact function instead to watch new entries as they arrive.

You can deploy a change, trigger it, and see the result in the same window, instead of switching to a separate dashboard to check what happened. Use it to confirm a fix during local development, or to diagnose a failure a customer reports in production.

Run sked logs function with a function name to fetch its logs, or launch Skedulo CLI Studio and open the log viewer for a scrollable session with full detail on each entry.

See also

See the function documentation for background, the sked function dev and sked function generate references for local development, the sked artifacts function reference for deploying, listing and deleting functions, the sked http reference for calling a local function with your token, and the sked logs function reference for fetching its execution logs.