dc
bfadbf24fd
Two more scenarios, and both needed recorder support that did not exist.
editors/stagedata on a table that is registered nowhere (0 accepted
differences). An edit submission sends *two* table inputs - the control table
and the edited rows as jsdata - so the recorder now posts several parts and the
harness declares several inputs, as the runtime does. The mock answered a
completed body where the service aborts with "Target table not found"; it aborts
that way now, and mpAbort no longer closes the body, because a SAS soft abort
does not reach the state that carries SYSENCODING.
public/getrawdata (0 accepted differences). A download answers CSV rather than
JSON, so scenarios can now declare format: csv and the body is parsed to
{header, rows} on both sides before the diff - SAS quotes and pads each cell to
the variable's width, so a text diff would fail on spacing that says nothing.
The mock was missing the header row, was exporting the registration's validity
columns (getrawdata.sas drops them: data staged(drop=&txfrom &txto)), and broke
any value containing a newline across two records because it did not quote it.
The harness now clears the response file before each run. Without that, a
service that only assigns _webout was handed the *previous* service's body -
which was hiding a stale-result bug in a DIRLIST test: the mock accepted
/tmp/%sysfunc(system(id)) as a parent, and the test passed because it was
reading the abort from the run before it. brCheckPath refuses '&' and '%' now,
which is the guard the test was written for.
check.js - seven scenarios, five of them at zero accepted differences:
ok public/startupservice/default (8 accepted difference(s))
ok editors/getdata/mpe_tables (1 accepted difference(s))
ok public/viewlibs/default (1 accepted difference(s))
ok public/getcols/mpe_tables (0 accepted difference(s))
ok editors/getdata/missing_table (0 accepted difference(s))
ok editors/stagedata/target_missing (0 accepted difference(s))
ok public/getrawdata/selectbox (0 accepted difference(s))
read-paths.test.js covers the two-input abort and the download's header/validity
columns/quoted newline. Suite: 99 pass, 0 fail.
Data Controller for SAS
Control your manual data modifications!
Alternatives to Data Controller include:
- 💾 Developing / testing / deploying / scheduling overnight batch jobs to load files from shared drives
- 🔒 Opening (and locking) datasets in Enterprise Guide or SAS® Table Viewer to perform direct updates
- ❓ Asking a #DBA to run validated code after a change management process
- 🌐 Building & maintaining your own custom web application
- 🏃 Running #SAS or #SQL updates in production
Problems with the above include:
- Legacy 'black box' solutions with little to no testing, documentation or support
- End users requiring direct write access to critical data sources in production
- Upload routines that must be manually modified when the data model changes
- Breaches due to unnecessary parties having access to the data
- Inability to trace who made a change, when, and why
- Reliance on key individuals to perform updates
- Building bespoke ETL for every new data source
- High risk of manual error / data corruption
Data Controller for SAS® solves all these issues in a simple-to-install, user-friendly, secure, documented, battle-tested web application. Available on Viya, SAS 9 EBI, and SASjs Server.
An individual Viya deploy can be done in just 2 lines of #SAS code!
filename dc url "https://git.datacontroller.io/dc/dc/releases/download/latest/viya.sas";
%inc dc;
For a multi-user deploy, using a shared system account, please see deploy docs.
For further information:
- Main site: https://datacontroller.io
- Docs: https://docs.datacontroller.io
- Code: https://code.datacontroller.io
For support, contact support@4gl.io or reach out on Matrix!
Development
Lighthouse CI
This project includes automated Lighthouse performance and accessibility checks that run on pull requests. The checks ensure:
- Accessibility Score: Minimum 1.0 (100%) median score across all tested pages
The Lighthouse CI workflow:
- Sets up the development environment with SASjs server and mocked services
- Builds and serves the Angular frontend
- Installs Chrome and runs
lhci autorun(Lighthouse CI) against key pages - Uploads results as artifacts for review
To run Lighthouse checks locally:
cd client
npm install
npm run lighthouse
Configuration is in client/lighthouserc.js (URL list, desktop preset, Chrome flags, assertions).