dc
64383571b2
The macro decided an aborted call by scanning the child's response text for a sasjsAbort object and then recovering the message from that text - anchors for the separator, gating on whether the payload was escaped, cuts for the log extract, and a capture width that had to be widened more than once. Every one of those steps existed to undo the escaping in the response. Core now publishes the abort reason in outstatus.errmsg for both the SASJS and Viya branches, with the whole message and no truncation, so the macro reads the row instead: STATE says whether the child was canceled, ERRMSG is the reason. The cut at the appended log extract is the only thing left, because that text is part of the message the child raised; it is stripped as characters, as an escaped pair or as a doubled pair, whichever the producer wrote. The macro therefore takes outstatus= rather than outref=, and the call sites in the service tests now pass the status dataset they already asked %mpe_execute for. stagedata.test.4's two aborting calls had no status row at all and now have one. A platform that reports the state but no message - SAS Viya until core fills errmsg from the job result - is judged on the state alone, so the same tests run on both platforms. @mpe_assert_abort.test covers the twelve cases directly against status rows instead of building response files, including the doubled separator the estate actually writes, a message past the old 256 character width, quotes and backslashes. Requires @sasjs/core 7.0.2, which carries the SASJS half of this.
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).