Integration glossary

Script library

A script library is a shared, versioned piece of code, such as a .NET class library or a package from NuGet, that the code steps of a workflow can call.

Why workflows need one

Most steps in a workflow are set up from options on a form. A few need real code: a pricing rule the finance team relies on, a check-digit calculation, or reading a document format that has its own rules.

When that code is pasted into each step, the copies drift apart and a fix has to be made in every one. A library keeps the code in one place, and each workflow that needs it refers to it.

What to control when code comes from outside

Open-source packages save a lot of work, and each one brings its own dependencies, licences and history. Bringing one into business processes deserves the same care as any other change.

  • See every package and dependency, with its licence, before anything is stored.

  • Warn about versions that are deprecated, unlisted or known to be vulnerable.

  • Let only a small group of people add or change libraries, and record who did it.

  • Pin the version a process was tested with, so an update never changes a running process by surprise.

  • Keep the machines that run the work away from public package feeds.

Script libraries in STRAX

STRAX keeps script libraries for workflow Code steps. Your team uploads its own .NET library or imports a package from NuGet or a private feed, and an administrator sees a preview of every package with its licence and any warnings before it is stored. Deploying a workflow pins the exact library version, workers fetch libraries from your own STRAX installation and never contact a package feed, and every import is written to the audit trail.

See it on your own systems.

A demo takes about an hour and shows these ideas working on systems like yours.