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.
Workflow automation → How workflows are built and run → What a worker pool is →
More terms
Other ideas worth knowing.
Change data capture (CDC)
Passing on only what changed in a database, shortly after it changed, instead of copying whole tables on a schedule.
Read the definition →Canonical data model
One agreed definition of shared records such as customer and order, which every connected system is mapped to once.
Read the definition →Two-way data synchronisation
Keeping the same record current in several systems, so an edit made in any one of them reaches the rest.
Read the definition →See it on your own systems.
A demo takes about an hour and shows these ideas working on systems like yours.


