SAS Apps - Blog & Feed

Constraints to Consider as a SAS App Developer

Fri, 28 Aug 2026 11:00:00 GMT

21 Constraints to Consider as a SAS App Developer

SAS is a powerful platform - but if you’re building apps on it, the real world has a habit of introducing constraints you didn’t plan for. Here’s a short list, earned the hard way across many project deliveries, to consider before you write a single line of code:

SAS runs on both Windows and Linux - so always use ”/” in filepaths
The SAS 9 url may not be /SASStoredProcess/do (it could be do3)
Encoding in SAS 9 in Europe is frequently WLATIN(X) not UTF-8
PROC JSON doesn’t handle invalid chars or special missings
There are three primary flavours of SAS - Viya, EBI, Base
Editing .html in Studio can affect the headers - use JES
The OS library in LUA is disabled in Viya 4 but not 3.5
Avoid in-line and external JS/CSS to meet strict CSP
Accessibility considerations / Lighthouse scores
endsas can kill the entire STP server in 9.4m3
Invisible characters embedded in .sas programs
The SAS 9 home directory might be read-only
RunAsTask fixes Job performance in Viya
Most large environments run -NOXCMD
Lack of multibridge connections
Options missing=” fun & games
Many sites implement LOCKDOWN
Breaking changes in Viya APIs
Support for very old browsers
How to prevent code injection
Handling SASLogon with MFA

We can help

If you are embarking on a SAS App Development project, as a customer or SAS Partner, our team is available for support.

Not only do we have the bitter-sweet experience of many successful (and some not so successful) project deliveries, we can equip you with some serious dev tooling. All of which is MIT open source and free for commercial use:

SASjs Skills - Agent skills for SAS & SASjs
SASjs Lint - Quality check your SAS code
SASjs Core - Macros for all flavours of SAS
SASjs CLI - DevOps, Documentation & Testing
SASjs Adapter - JS connectivity library
SASjs Server - Build Apps on Base SAS

Plus multiple Seed Apps to quick start your development journey.

#sasviya #sashackathon #sasprogramming #sassoftware

Macro Dash - a SAS Powered Platformer

Wed, 19 Aug 2026 09:00:00 GMT

Macro Dash is a free, open-source platformer built with the SASjs framework. You are the DATA stepper: bounce through the WORK library, stomp ERRORs and WARNINGs, collect ampersands, grab the FORMAT 10.2 mushroom for super jumps, and get your report to the portal before the job runs out of steam. One run, all levels - amps, health and the speedrun clock carry over. Finish with 0 ERRORs and 0 WARNINGs for the clean-log stamp, then put your SYSUSERID on the dashboard.

Play it right now: dash.sasjs.io. It runs on desktop (arrows/WASD, Space to jump, hold Shift to RUN) and mobile (on-screen controls) - the repo is at github.com/sasjs/macro-dash.

But it is not really a game

Behind the pixels, Macro Dash is a working demonstration of how to craft and deploy data-powered web apps on SAS - the same architecture behind production applications like Data Controller:

A frontend (plain HTML/JS canvas, strict CSP, no framework) streamed directly from SAS - no separate web tier to build, secure or maintain.
Backend services written in SAS (sasjs/services/) that receive tables from the browser, run SAS code, and return JSON. The game uses three: configure, getscores, savescore - a complete, persistent, server-side leaderboard.
One codebase, every flavour of SAS: deploy to SAS Viya, SAS 9 EBI or SASjs Server with a single command (sasjs cbd), using @sasjs/cli and the @sasjs/core macro library.
Graceful degradation: with no backend reachable, the game falls back to localStorage mode (personal best, no leaderboard) - the same pattern you want in resilient production apps.

If you can build this, you can build a data capture form, an approvals workflow, a parameter manager or a reporting portal on your own SAS platform. The design decisions are documented in PLAN.md and AGENTS.md; the services are deliberately small and readable.

Deploy to SAS Viya in one line - no install

Every release ships a single self-contained deploy script - macro-dash-viya.sas - that streams the frontend and installs the backend services straight onto the SAS Files Service. No Node, no @sasjs/cli, no build step: run it from SAS Studio, SAS Enterprise Guide, or any batch SAS session.

%let apploc=/your/viya/folder;
filename md url "https://github.com/sasjs/macro-dash/releases/latest/download/macro-dash-viya.sas";
%inc md;

That is the whole deployment. Set apploc to wherever you want the app to live on the Files Service (it is created if it does not exist), and the script does the rest: uploads the streamed MacroDash.html + assets, registers the configure / getscores / savescore services, and prints the app URL when done:

<SAS Viya base>/SASJobExecution?_FILE=/your/viya/folder/services/MacroDash.html

Open that URL and the game loads. On first visit you get an in-game configuration screen - pick a results folder for the leaderboard (a physical folder SAS can write scores.sas7bdat to), optionally choose the compute context and a runAsTask / useComputeApi execution mode, and submit. The configure service writes settings.sas into your apploc and flips configured="true" in the streamed MacroDash.html, so every subsequent load skips setup and the leaderboard is live for everyone.

Deploy from source / to other platforms

The release artefact is built by CI from sasjs/ on every push to main. To build and deploy directly from a checkout (e.g. for SAS 9 or SASjs Server, or to push to Viya without the release script), the targets live in sasjs/sasjsconfig.json:

sasjs cbd -t viya      # or: sas9 | server

sasjs cbd compiles the macros + services, builds the streaming web bundle, and deploys a service pack to the target’s appLoc in one shot. The serverUrl is left blank in the shipped config - set it to your own SAS Viya / SASjs Server instance (and adjust appLoc, contextName, etc.) before deploying. The public game on dash.sasjs.io is the backend-free GitHub Pages build.

Local development (no SAS required)

npm install
npm run devsetup

devsetup downloads the @sasjs/server binary for your platform, writes a .env (desktop mode, JS runtime - no SAS installation needed), starts the server on port 5000, deploys the app (sasjs cbd -t local) and the JS mocks, then prints the URL:

http://localhost:5000/AppStream/MacroDash/

The four backend services are executable JS mocks that shadow the .sas services, so the leaderboard works end-to-end against a local SASjs Drive - no SAS licence required to develop.

Summary

Macro Dash is a fun way to see what SASjs makes possible. Play it at dash.sasjs.io, and if you would like to build data-powered apps on your own SAS estate - or partner with us on a project - get in touch.

SASjs CLI Auth Login - Connect to Viya Without a Client/Secret

Tue, 18 Aug 2026 09:00:00 GMT

The SASjs CLI has always required a registered OAuth client and secret to authenticate against SAS Viya. If you are a developer who just wants to run a SAS program from the command line, getting an administrator to register an OAuth client for you is friction you do not need. The new sasjs auth login command removes that barrier - you log in with your regular SAS username and password, and the CLI handles the rest.

What it does

sasjs auth login -t myviyatarget

That is it. You are prompted for your SAS username and password (the password input is masked), the CLI exchanges them for an access/refresh token pair, verifies the token, and persists it. From that point on, the stored token can be used by any command that accepts an access token - sasjs run, sasjs deploy, sasjs job execute, sasjs flow, sasjs fs, sasjs request, sasjs context, sasjs folder, sasjs test. No client or secret is needed for the initial login or for silent token refreshes (the built-in sas.cli public client handles those).

Why it matters

Before this feature, authenticating to Viya from the SASjs CLI meant:

Asking a SAS administrator to register an OAuth client in SAS Viya
Obtaining the CLIENT ID and CLIENT SECRET
Running sasjs auth (or sasjs add cred), which uses the authorisation code flow - you visit a URL in your browser, sign in, grant access, and paste back an authorisation code

That is fine for production CI pipelines, but painful for a developer who just wants to test something quickly on a demo Viya instance. The new sasjs auth login command uses the OAuth2 resource owner password grant against the built-in, secret-less sas.cli public client - the same client the official SAS Viya CLI uses. No client registration, no secret, no browser redirect.

How it works

Under the hood, sasjs auth login does the following:

Password grant request - sends a POST to /SASLogon/oauth/token with grant_type=password, your username, and your password, authenticated with a Basic auth header for the sas.cli client (which has no secret).
Token verification - calls GET /identities/users/@currentUser with the access token to confirm it is valid and to identify the logged-in user.
Token persistence - saves the access token and refresh token to the same locations as the existing sasjs auth flow: .env.[target name] for local targets, ~/.sasjsrc for global targets.
Automatic refresh - when the access token is close to expiry, the CLI silently refreshes it using the stored refresh token (again via the sas.cli client). No client/secret is needed for the refresh either.

Viya refresh tokens are single-use and rotate on every refresh. The CLI persists the rotated pair automatically after every refresh - so the next CLI invocation always reads the latest valid pair, and you never end up with a stale refresh token.

Quick start

First, make sure you have a target configured for your Viya server. If you do not have one yet, create one with the interactive wizard:

sasjs add

The command prompts you for the target name, server type (pick SAS Viya), server URL, and app location. You can skip the authentication step at the end - sasjs auth login will handle that separately.

Then log in:

sasjs auth login -t myviyatarget
# Please enter your SAS username: viyademo01
# Please enter your SAS password: ********
# Logged in as viyademo01 (Viya Demo User) on https://your-viya-server.com.

Now run any command:

sasjs run myprogram.sas -t myviyatarget

When the access token expires (12 hours by default, though some estates configure shorter TTLs for the sas.cli client), the CLI will silently refresh it. If the refresh token itself expires, just run sasjs auth login -t myviyatarget again.

Security notes

The password is never persisted. It is used only to mint the token pair and is not written to any file. The password stays in memory for the lifetime of the short-lived CLI process, which exits within seconds.
No --password command-line flag exists. Passing a password as a command-line argument would leak it via shell history and process listings (ps). The CLI deliberately does not offer this option.
Refresh tokens are rotated and stored. Because Viya refresh tokens are single-use, the CLI persists the new pair after every refresh. This is handled automatically.
--insecure flag for self-signed certs. If your Viya server uses self-signed certificates, pass --insecure (or -i) to bypass TLS validation: sasjs auth login -t myviyatarget --insecure. This is not recommended for production.

Non-interactive usage (CI pipelines and agents)

sasjs auth login supports both interactive and non-interactive credential input. For CI pipelines and automated environments, there are three non-interactive patterns:

Environment variables:

SAS_USERNAME=viyademo01 SAS_PASSWORD=secret sasjs auth login -t myviyatarget

When both SAS_USERNAME and SAS_PASSWORD are set, the CLI skips the prompts entirely.

Password via stdin (avoids shell history leakage):

echo "$SAS_PASSWORD" | sasjs auth login --password-stdin -t myviyatarget

When --password-stdin is set, the password is read from stdin and the username must come from the SAS_USERNAME environment variable (stdin is reserved for the password, so interactive prompting is not possible).

Credential precedence:

Username: SAS_USERNAME env var > interactive prompt (TTY only)
Password: --password-stdin > SAS_PASSWORD env var > interactive prompt (TTY only)

If no TTY is available and no env var or stdin flag supplies the credential, the command throws with a clear message pointing at the env vars or --password-stdin. This makes it safe to call from CI pipelines and non-interactive agents.

Requirements and limitations

The password grant must be enabled for the sas.cli client. This is the default on most Viya deployments, but administrators can disable it.
The account must be a local or LDAP account. sasjs auth login cannot work on SSO/SAML/MFA-only estates - those require the browser-based authorisation code flow.
On a cold Viya estate, the first compute session creation can take several minutes while pods spin up. The first sasjs run may appear to hang. Subsequent runs are fast.
If sasjs run fails with a 403 when creating a compute session, your account may not be authorised for the configured compute context. Check the available contexts and update the contextName on your target accordingly.
The password grant is deprecated in OAuth 2.1. This flow is intended for dev/demo estates where obtaining a registered client/secret is impractical. For CI pipelines and production use, a properly registered client/secret (via sasjs auth) remains the recommended approach.

Backward compatibility

The bare sasjs auth command (without the login subcommand) still works exactly as before - it is an alias for sasjs add cred and uses the client/secret authorisation code flow. Nothing changes for existing setups. The login subcommand is purely additive.

The sasjs auth login command is available in the latest SASjs CLI release. If you have been putting off trying the SASjs CLI because you did not want to deal with OAuth client registration, this is your excuse to give it a go.

SASjs Web Apps on SAS Viya

Tue, 19 Aug 2025 09:00:00 GMT

What is a SASjs Web App and how does it integrate with a SAS Viya data platform? A reasonable question from a SAS Administration team. This article delves into the specifics of a typical SASjs Web App, deployed to a standard SAS Viya 2025 instance.

Introduction

4GL is a boutique software company with a singular focus on building browser-based applications for SAS platforms. Alongside greenfield development we specialise in the migration of SAS 9 Web Apps to Viya, and modernisation of legacy SAS AF/SCL desktop applications.

When not working on customer projects, we are extending our own products - Data Controller (a data ingestion tool for SAS) and SASjs.

SASjs is both a set of open-source tools as well as an opinionated framework for the deployment and delivery of web applications on SAS platforms. The core components are:

SASjs Core - a SAS macro library
SASjs Adapter - a Javascript library
SASjs CLI - a command-line tool for testing, linting, and performing build compilations and deployments

Our apps capitalise upon the advantages of the SASjs framework to both accelerate and de-risk web app development projects.

Architecture

Our SAS Viya web apps typically comprise of a frontend (static web content) deployed to SAS Drive, that uses the SASjs adapter to invoke the backend (SAS code in Viya Jobs).

The deployed components consist of:

Web content (.html, .css, .js, .png files etc)
Jobs (SAS code)
Compute Context (under which the jobs run)
Filesystem content (.sas7bdat files, logs etc)

SASjs web apps on Viya do NOT require:

Administrator access (except for the Compute Context config)
A dedicated web server
Filesystem access
Terminal access

Frontend Development

The web app is built locally, on the developer’s machine, often using mocked responses to simulate a real SAS Viya server. Typically we build using the React framework, over this baseline repository.

Here are some of the steps taken to improve security at build time:

NPM Audit. We check dependencies for CVEs and other issues with every build. The automated build will fail if there are any critical errors or warnings.
Type Safety. Apps are built with TypeScript in Strict mode to prevent mis-allocated variables.
Adapter Input Sanitation. The content that is sent to SAS is normalised into “table format”, so that columns have specific types (char/numeric) and lengths. The adapter does not have the ability to enable “URL variables” so preventing their accidental and potentially dangerous resolution in SAS code.
Semantic Releases. Every release is numbered according to the conventional commit standard, making it easy to see what was changed on a release by release basis
Opinionated Framework. SASjs is designed to mitigate the risk of code injection by ensuring that all data communication happens through the adapter, which ensures a specific format of data interchange (see the project README).
Isolated Environment. The build happens locally, or in a pipeline, never on the SAS platform itself.

Backend Development

The backend for a SASjs Viya web app is a series of self-contained Viya Jobs, containing regular SAS code. These jobs perform the backend logic and data processing needs of the frontend app.

The SASjs framework ensures that all jobs are documented (as macros must be listed in the header in order to be compiled) and organised by reference to a central configuration file.

Points to note from a security perspective:

Input sanitation. Standard macros are used to parse the input files and create corresponding datasets in the WORK library for further processing.
Testing suite. Tests can be created for Jobs, Services and Macros, and test coverage is measured in every compile.
Linting. The lint feature scans code for non-printable characters, SAS001/2 encoded passwords, nested macros, and other nasties.
Strict Mode. Our mp_init() macro, which implements a defensive set of SAS options, is typically used in every callable job

Build Process

The build / development process may be performed on a laptop, or in a pipeline. The goal of the build is to prepare the app in such a way that makes it easy to deploy - especially given that this is often done by a completely different individual or team.

The flow typically looks like:

Build frontend
Compile the project (per SASjs Config)
Remove tests (eg if a production deploy)
Build the project (per SASjs Config) for deployment
Share the deployment assets with the administrator

Deploy Process

There are two ways to deploy a SASjs app on SAS Viya:

Using the SASjs CLI directly
Using a SAS Deployment Program (generated using the CLI)

To use the CLI approach, run the authenticate and the deploy commands. This will require a client/secret pair, and is performed from a laptop or an isolated pipeline. The deploy process makes exclusive use of standard Viya APIs, and will create the necessary folders / deploy the Jobs and frontend Files.

The SAS Program Deployment approach simply means, running the SAS code in SAS Studio. The program can be very big, as it will contain the entire frontend, as well as all the SAS Services and Jobs (and if no production, Tests). Each Job and frontend File are deployed one by one using the Viya APIs, invoked by SAS code. No client/secret is required, as the SAS session will make use of the oauth_bearer=sas_services setting in proc http. The deployment macros are listed here.

Production Environment

Once in Production, a SASjs app benefits from a number of protections:

Uses standard SASLogon (corporate auth)
Static Content. The frontend (html, css, js, png) is deployed entirely to SAS Drive (files service). There are zero “running services” to deploy outside of SAS.
The frontend is ONLY visible once authenticated and authorised.
Strict Content Security Policy. By default, Viya enforces a very tight ruleset on web content and this cannot be bypassed.
NOXCMD by default
No filesystem dependency for SAS code. The SASjs compilation process ensures that every job is fully self-contained - so is not vulnerable to code changes on the filesystem.
No internet dependency. Apps are always designed to work without external dependencies such as fonts, images, JS libraries etc.
The SASjs Adapter makes exclusive use of SAS Viya APIs. These include:
- DELETE /compute/sessions/${id}
- GET /compute/contexts
- GET /compute/sessions/${id}/jobs/${id}
- GET /compute/sessions/${id}
- GET /folders/folders/@item
- GET /identities/users/@currentUser
- GET /jobExecution/jobs/${id}
- POST /compute/contexts/${id}/sessions
- POST /compute/sessions/${id}/jobs
- POST /jobExecution/jobs

Summary

The SASjs web apps we produce are always:

Appropriately licenced - no copyleft components
Contained entirely in a standard Viya install
Version controlled
Easy to deploy
Documented
Accessible
Tested
Secure

Do reach out for further information, or clarifications on the build / deployment process.

SASjs Server on CentOS

Thu, 01 Sep 2022 09:00:00 GMT

SAS 9 on Centos may not be officially supported by SAS Institute, but it is supported by the SAS Apps team! At least, we can support the SASjs Server component.

This is a complete guide to setting up SASjs Server on CentOS 7. A SAS runtime is a prerequisite, and a guide to installing that is available here. A guide to installing SASjs Server on Debian / Ubuntu type images is available here

Pre-Requisites

Before you get started, be sure you can obtain the following:

The IP address of your VPS, with root SSH access, eg: 167.44.44.44
A working installation of SAS (or WPS)
A domain (and access to the DNS panel), eg mysas.mycompany.com
A MongoDB connection string (you can provision one locally or use a free cloud instance)

Server Setup

Let’s get this machine configured! First we log in as root, eg:

# Enter as sudo-enabled user using YOUR new server IP address
ssh user@167.44.44.44

Next, we create a unix group (sas) and create the system user account / home directory:

# Create a sas group
sudo addgroup sas
# Make the user account (eg sasjssrv) and add to sas group
sudo adduser sasjssrv -G sas

TLS / SSL

We can generate https certificates using certbot. Since certbot is packaged as a snap, we’ll also install snapd.

# Add EPEL repository
sudo yum install epel-release
sudo yum upgrade
# Install snapd
sudo yum install snapd
# Enable snap communication socket
sudo systemctl enable --now snapd.socket
# Create symbolic link
sudo ln -s /var/lib/snapd/snap /snap
# Now, log out of the session and log back in

Now we are back in the session we can install certbot:

# Remove any previous installation
sudo yum remove certbot
# Install Certbot.
sudo snap install --classic certbot
# Make symlink
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Before proceeding further, it is necessary to first update your DNS and add an “A record” pointing to your server IP.

Once this is done, we can launch certbot.

# provide domain to prompt WITHOUT https prefix, eg mysas.mycompany.com
sudo certbot certonly --standalone

# ensure members of the sas group can access the certs
# update the paths below according to the actual domain!
mkdir /opt/certificates
cd /etc/letsencrypt/live/YOURDOMAIN.com
cp fullchain.pem /opt/certificates/fullchain.pem
cp privkey.pem /opt/certificates/privkey.pem
chgrp -R sas /opt/certificates
chmod -R 755 /opt/certificates

SASjs Installation & Configuration

The rest of the installation is exactly as described in this article (from “SASjs Installation & Configuration” onwards).

Load Balancing with SASjs Server

Thu, 28 Jul 2022 09:00:00 GMT

SASjs Server does not ship with a load balancer. However it does “play nicely” with existing load balancers - such as nginx. This enables deployment in a similar topology to that of legacy SAS/IntrNet servers or Stored Process Web Apps.

In this guide we will demonstrate how to configure nginx against three backend instances of SASjs Server.

The guidance below should considered just that - a guide. In reality, your implementation may cross managerial boundaries - eg infrastructure for firewall and load balancer activities, and the BI team for SASjs Server setup and configuration.

Also, you may have formal approval processes to install software such as nginx (or existing software that does the same job), hoops to jump through to open up ports, and so on.

Finally, your configuration may differ according to the nature of your application(s), load profile, server specs etc.

With that out of the way - let’s proceed!

The assumptions are:

You are a sysadmin and you have all necessary access rights
You do not have a load balancer already configured
You have the experience and authority to do all this stuff.

The prerequisites are:

3 functional and identical instances of SASjs Server (setup steps here).
A linux VPS for the load balancer, with root access
A domain with corresponding TLS certificates

NGINX Basic Setup

SSH onto the load balancing server. If nginx is not installed, install as follows:

sudo apt-get install nginx

Next, open the configuration ( eg /etc/nginx/sites-available/default) and using your preferred editor (nano, vim) and adjust the contents usuing the sample config below.

# List of backend SASjs server instances
#  (internal/private IP + port)
upstream mysasgrid {
  server 10.110.0.8:5000;
  server 10.110.0.11:5000;
  server 10.110.0.10:5000;
}

server {
  listen 80;
  location / {
    proxy_pass http://mysasgrid;
  }
}

Finally, restart nginx:

sudo service nginx restart

That’s it! 🚀🚀🚀

You should now be able to access the SASjs Server instances from the domain of the load balancer. Simply run %put &=syshostname; in Studio to see the domain of each node:

If you are having troubles be sure to check the log file at /var/log/nginx/error.log.

NGINX Setup with TLS

To enable TLS (https) on the load balancer, you need to create a certificate and key. The easiest way to do this is to use the Let’s Encrypt service - an example is provided in this article.

Once you have your fullchain.pem and privkey.pem, update the text below and use to replace the contents of /etc/nginx/sites-available/default as follows:

upstream mysasgrid {
  server 10.110.0.8:5000;
  server 10.110.0.11:5000;
  server 10.110.0.10:5000;
}

server {
  listen              443 ssl;
  # domain of your load balancer
  server_name          demo.4gl.io;
  # location of your certificates
  ssl_certificate     /opt/certificates/fullchain.pem;
  ssl_certificate_key /opt/certificates/privkey.pem;

  location / {
    proxy_pass http://mysasgrid;
  }
}

Save, re-run sudo service nginx restart and voila - your load balancer is configured to use TLS 🔒🔒🔒

Note that the SSL encryption terminates here at the load balancer - the node traffic runs over http. If you do not trust your internal network, or you are using external nodes, you may wish to configure SSL Passthrough - an article on that is here.

NGINX Load Balancing Algorithms

By default, nginx will send traffic to each server sequentially (Round Robin). However there may be reasons to use a different algorithm - for example, if you have servers with varying capacity, or reliability.

Below are some examples of load balancing algorithms on nginx.

Weight

You can assign specific weights to each node, to allow more traffic to be sent to the servers with higher capacity.

For instance:

upstream mysasgrid {
  server 10.110.0.8:5000 weight=1;
  server 10.110.0.11:5000 weight=2;
  server 10.110.0.10:5000 weight=6;
}

In this case, the second server will receive twice as much traffic as the first. The third will receive six times more traffic than the first.

Hash

By taking a hash of the IP of the request, you can route the requests for each visitor to the same SAS instance. This is useful when your SAS app makes use of node-specific features, eg for session management.

Note that if a server is down, it may be marked as such in order to redirect the requests.

Example config:

upstream mysasgrid {
  ip_hash;
  server 10.110.0.8:5000;
  server 10.110.0.11:5000 down;
  server 10.110.0.10:5000;
}

In this example the second server is marked as down.

Max Fails

By default (Round Robin) requests are blindly forwarded to servers that are down / unresponsive. The Max Fails algorithm deals with this using two parameters:

max_fails - the number of consecutive failures before the server is marked as down.
fail_timeout - how long to wait before the server is assumed to be back up.

You can mix and match “Max Fails” with “Weight” and “Hash” algorithms. Example:

upstream mysasgrid {
  ip_hash;
  server 10.110.0.8:5000 weight=1 max_fails=1 fail_timeout=10s;
  server 10.110.0.11:5000 max_fails=1 fail_timeout=1s;
  server 10.110.0.10:5000 weight=6 max_fails=2 fail_timeout=1h;
}

In this config:

We are using IP hashing (each visitor will continue to use the same machine)
The third server will get six times as much traffic as the other two (default weight is 1)
If the third server fails twice, it will be out of action for 1 hour
If the first server fails once, it is out of action for 10 seconds

As you can see, NGINX is highly configurable. Further options / algorithms (such as least_time or least_conn) are available if you take out a commercial subscription with nginx.

Deploying SAS Apps on Load Balanced Platforms

The key thing to remember is that the load balancer config above does not differentiate between web requests and SAS requests. Therefore your app must be deployed to ALL the nodes in the cluster.

If you would like to take security one step further, you could consider deploying the load balancer BEHIND the frontend application. In this way, you can prevent end users from calling SAS services directly - by whitelisting the IP of the web server. A topology for this is shown below:

This approach will only work if you are running an actual web server (eg NodeJS application) and frontend. It won’t work for single page applications.

If you’re interested to deploy such a solution, or you would like to partner with our team to deliver SAS Apps in other configurations, do get in touch!

SASjs Server on Cloud VPS

Mon, 18 Jul 2022 09:00:00 GMT

SASjs Server is the latest addition to the SASjs product family, and closes an important gap - namely, the ability to perform DevOps and launch applications on regular Foundation (desktop or server, windows or linux) SAS.

This guide will show you how to install and configure SASjs on a VPS (Virtual Private Server), such as a Digital Ocean droplet.

Introduction

Like all SASjs tools, SASjs Server is MIT open source and hence completely free for commercial use. The latest release is always available on the github releases page. The major features are:

Portal for 3rd Party Apps (AppStream)
Permissions by User or Group
Multiple runtimes (SAS, JS)
Online IDE (Studio)
Stored Programs
REST API
TLS

One of the (many) nice things about SASjs Server is that it is extremely lightweight! You can even run it on a $6 VPS, as shown here::

In this guide we show you exactly how to create a server image like the one above. If you are planning multiple users, you might want to consider a slightly higher spec! We have a dozen or so users on our $28 per month image, plus all our test suites, and the performance has been great.

Pre-Requisites

Before you get started, be sure you can obtain the following:

The IP address of your VPS, with root SSH access, eg: 167.44.44.44
A copy of SAS (or WPS) and the corresponding licence key
A domain (and access to the DNS panel), eg mysas.mycompany.com
A MongoDB connection string (you can provision one locally or use a free cloud instance)

Server Setup

Let’s get this machine configured! First we log in as root, eg:

# Enter as root using YOUR new server IP address
ssh root@167.44.44.44

Next, we create a unix group (sas) and create the system user account / home directory:

# Create a sas group
addgroup sas
# Make the user account (eg sasjssrv)
adduser --disabled-password --gecos "" sasjssrv
# Add to `sas` group
adduser sasjssrv sas

SAS Installation

This part will vary depending on your service provider. Follow the necessary instructions to install the basic software suite. You do NOT need any products beyond the basic SAS executable (sas.exe / sas.sh).

TLS

Before proceeding with TLS (SSL) it is necessary to first update your DNS and add an “A record” pointing to your server IP.

Once this is done, we can generate https certificates using certbot as follows:

snap install core; snap refresh core
snap install --classic certbot
ln -s /snap/bin/certbot /usr/bin/certbot
# provide domain to terminal prompt WITHOUT https prefix, eg mysas.mycompany.com
sudo certbot certonly --standalone

# ensure members of the sas group can access the certs
# update the paths below according to the actual domain!
mkdir /opt/certificates
cd /etc/letsencrypt/live/YOURDOMAIN.com
cp fullchain.pem /opt/certificates/fullchain.pem
cp privkey.pem /opt/certificates/privkey.pem
chgrp -R sas /opt/certificates
chmod -R g+r /opt/certificates

SASjs Installation & Configuration

Here’s the exciting part - the SASjs config! The instructions below provide a FULL deployment, including TLS / server mode / JS runtime option. If any part of this is not relevant for your use case, you can simply omit it.

# change into the folder.  Remain as root to keep files protected.
cd /home/sasjssrv

# grab latest api server
curl -L https://github.com/sasjs/server/releases/latest/download/linux.zip > linux.zip
# unzip can be installed with `apt install unzip`
unzip linux.zip

# Tell SASjs the location of your SAS executable
echo "SAS_PATH=/path/to/your/sas.sh" > .env
# At this point you can already stop, and you
# will have SASjs Server in desktop mode!


# If you would also like the option of a JS runtime, follow these steps:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion
nvm install --lts
echo "NODE_PATH=$(which node)" >> .env
echo "PYTHON_PATH=$(which python3)" >> .env
echo "RUN_TIMES=sas,js,py" >> .env

# Server Mode enables Users, Groups & Permissions
# But requires a Mongo DB connx string
echo "MODE=server" >> .env
# DB connection string
echo "DB_CONNECT=mongodb+srv://admin:admin@cluster0.YOURINSTANCE.mongodb.net/sasjs?retryWrites=true&w=majority" >> .env

# For https, point at the certs generated previously
echo "PORT=443" >> .env
echo "PROTOCOL=https" >> .env
echo "CERT_CHAIN=/opt/certificates/fullchain.pem" >> .env
echo "PRIVATE_KEY=/opt/certificates/privkey.pem" >> .env

# enable api-linux to run on port 443
# re-run whenever SASjs Server is re-installed
setcap 'cap_net_bind_service=+ep' /home/sasjssrv/api-linux

# Create a handy refresh script to update SASjs Server
cat > refreshSASjs.sh <<EOL
#bin/bash
curl -L https://github.com/sasjs/server/releases/latest/download/linux.zip > linux.zip
unzip -o linux.zip
setcap 'cap_net_bind_service=+ep' /home/sasjssrv/api-linux
EOL
chmod 774 refreshSASjs.sh

That’s the setup. Now, the launch - using the designated system account. Be aware that anyone running code or Stored Programs will be executing under this OS identity.

# switch to system user
sudo su - sasjssrv
# launch SASjs Server
nohup ./api-linux > server.log 2>&1 &

You should now be able to access SASjs Server at your domain, eg mysas.mycompany.com using the default credentials (secretuser/secretpassword). If there are problems connecting, check out the logs in the /home/sasjssrv/sasjs_root/logs directory.

Create the SASjs Users

Users can be added manually using the rest api, or in bulk using SASjs Studio - here is some sample code!

data work.users;
  infile cards dsd;
  input username:$12. displayname:$32.;
  putlog _all_;
  call execute(
    '%nrstr(%ms_createuser('!!username!!',demo123,displayname='!!displayname!!'))'
  );
cards4;
sylvester,Sylvester Stallone
rocky,Rocky Balboa
john,John Johnston
;;;;
run;

%ms_getusers(outds=work.users)

%mp_ds2md(work.users)

Finally - don’t forget to change the password for the secretuser, and request that other users do the same for theirs.

If you’d like to perform additional configuration, just update the name / value pairs in the /home/sasjssrv/.env file and restart the server.

SAS Streamed Apps

Fri, 19 Feb 2021 09:00:00 GMT

SAS Streamed Apps are served directly from the SAS logical folder tree - ie SAS Drive in Viya or the Metadata BIP folder in SAS 9. This is highly convenient - there’s no need for web server access, nor even a filesystem, and they can be deployed easily in a few lines of code.

This article will demonstrate the concept of a SAS-Streamed app using a Nintendo classic - Super Mario. The app will work on both SAS 9 or Viya.

Before we begin - lets take a look at some of the disadvantages of SAS-Streamed apps:

Performance. Because every asset is served from the SAS folder tree (App Server), response times are slow. However, assets are also cached so subsequent requests are fast.
Complexity. In order to ‘convert’ a regular app into a streamed app, there is a compilation process. It works well but it’s not 100% perfect (yet).

The main reasons for using this approach would be:

You don’t have web server access
You would like to create apps that can be very easily deployed

Right - lets get started!

## Prerequisites

Our demo will make use of the tools below - these need to be installed locally (on your desktop / laptop).

GIT
The SASjs CLI
VS Code (optional - but recommended)

Setup

The first thing to do is clone the example project from github, as follows:

git clone git@github.com:sasjs/mario.git
cd mario

The next step is configuration. This is always found in the sasjs/sasjsconfig.json file. The following items should be changed:

defaultTarget - either “sas9” or “viya” depending on your SAS server type
appLoc - for your chosen target (sas9 or viya), this represents the root folder to which the app is deployed.

Compilation

Compilation is the process of taking all the source files (ie your web frontend, and any SAS-powered web services) and preparing them for deployment. For SAS 9, all content is served through self-contained Stored Processes - so any binary content must be base-64 encoded. Also, prior to the build for both Viya and SAS 9, all file references (eg to images, css, js etc) must be converted from relative paths, to fully qualified paths - ie to the relevant location in the SAS logical folder tree.

Fortunately you don’t have to do any of this! It can be achieved with a single command:

sasjs compile

The exact settings for this process (source / target folder path, index.html rename, etc) can all be adjusted. More information here.

For the Mario game you can see all the files under the src folder. If you are building your own streamed app, you’d place your own content in this folder instead. Ensure all file paths are relative, all web content is in the same folder, and that your app starts from a file called index.html.

Build

The build part involves taking all the compiled assets and preparing a single file for deployment. Two file types are always prepared:

JSON - used in Viya for deployment with REST APIs (client/secret required)
SAS - can be executed in both SAS 9 and Viya

The great thing about the generated SAS program is that it can be executed by ANY user of SAS to create the app. To adjust the target location, simply configure the appLoc macro variable at the start of the program, eg:

%let apploc=/folder-location/app/my_amazing_app;

This does require that you have the “write” permissions on the target folder.

Deploy

For manual deployment, you can just execute the aforementioned SAS program from sasjs build by copy pasting into SAS Studio or Enterprise Guide. For automated deployment, authentication is required. For this, simply run the below and follow the prompts:

sasjs auth

If you are deploying to Viya, you will need a Client and Secret. If you are deploying to SAS 9, you will need a runner in your home folder. If you’d like to use SAS encoded passwords, there is also a server change required. For more information, see docs for sasjs auth.

Once you’re authenticated, you’re ready to auto-deploy!

sasjs deploy

When the deployServicePack attribute in the sasjsconfig.json file is true, the above command will deploy all the services using either the JSON file (if Viya) or the SAS program (if SAS 9).

The URL for the app will also be printed to the console window.

Video Walkthrough

If you’d like to see this app deployed to both SAS 9 and Viya in just 5 minutes, check out the video below!

Summary

In this walkthrough we installed some prerequisites, cloned an open source GIT repo, and deployed to our SAS server. The compile/build/deploy process will work for almost any SAS app, and is optimised for macro-driven SAS web services also.

If you’d like to support building web apps on SAS, and especially if you’d like to partner with us on a project to deliver apps on SAS, do get in touch!

GIT + SAS

Fri, 19 Feb 2021 09:00:00 GMT

Since 9.4m6 there are GIT functions in SAS, with further integration in DI Studio and SAS StudioV.

These all solve particular use cases, but perhaps not the most compelling one - how do I, as a SAS developer, collaborate with my team mates so that I can build my feature branch, test it, make a pull request, have it reviewed, run it automatically on merge to development, and onwards to the production branch?

The answer is - the same way as every other language.

Develop LOCALLY and execute (test) in the appropriate runtime (eg, the SAS server).

“That’s great Allan,” I hear you say, “but - how am I supposed to do all that? I don’t want to import or copy paste all my files up to SAS each time I add back a missing semicolon”

We know - we built Data Controller for SAS® with 51 macros, 39 backend services, and deploy once to SAS 9 and 3 times to SAS Viya with every merge.

How?

Using SASjs.

With this framework you can enjoy all the flexibility of a modern IDE such as VS Code, and the raw execution grunt of a high powered SAS server with a few simple commands:

sasjs create yourProject -t jobs # create a project
sasjs add # add deployment target
sasjs cbd -t yourTarget # compile, build & deploy to Viya or SAS 9

If you don’t want to wait for your entire project to build & deploy each time, you can compile and sasjs run individual jobs, or use the SASjs VS Code Plugin to execute code.

Once your code is tested and ready you can commit (ideally using the conventional commit standard), push, and have your pull request reviewed following standard GIT workflow practices.

Docs: https://cli.sasjs.io

SASjs Workshops

Mon, 14 Sep 2020 09:00:00 GMT

Overview

SAS is a fantastic platform for enterprise app development, due to a number of features that SAS delivers “out of the box”:

Web Server (Apache on Viya)
App Server (STP or Compute)
Integrated Authentication (eg LDAP)
Enterprise grade security

In summary - to build an app on a default SAS installation, you can just start coding. There is nothing more to provision!

The caveat - there are a few things to consider if you’d like to build something that’s automated, maintainable, and scalable. For instance:

How will you deploy your services?
How can you avoid a file system dependency?
Is there a code injection risk?
Avoiding “spaghetti code” and put statements
Numerical Precision and Special Characters
What if you don’t have access to the web server?

To address these points, and many more, we built SASjs.

Background

Launched in early 2020, the SASjs framework provides a set of tools that can be used either individually (for particular use cases) or together - for maximum scale and performance when it comes to building & deploying SAS-Powered Web Applications.

All the code is MIT open-source (free for commercial use), and is actively maintained by the SAS Apps Team. It powers commercial apps such as Data Controller for SAS and hence - heavily tested in real-world, production environments.

Framework

There are three major parts to the framework:

@sasjs/core - a SAS Macro library for backend SAS Application Developers
@sasjs/adapter - a JavaScript library aimed at frontend web developers
@sasjs/cli - a command line interface providing build and deployment tooling as well as consistent project setup

Another great thing about the SASjs approach is that anything you build with it on SAS 9 can be easily ported to SAS Viya. It’s also very FAST. Here’s a demo of building and deploying an app on SAS Viya in just one minute!

Workshop

We would like to support the SAS community and help more SAS Users build awesome web applications on SAS 9 and Viya. For this reason we are running regular workshops during the rest of 2020.

The duration is 1 hour, and will cover:

5 mins - get to know attendee objectives
15 mins - slides with generic advice for building apps on SAS
15 mins - Demo of building / deploying web apps using the framework
15 mins - Deep dive into SASjs CLI functionality
10 mins - Questions and discussion

To reserve your spot, visit the SASjs page on linkedin, and select an event from the bottom right hand side of the page.

https://www.linkedin.com/company/sasjs

Workshops are open to SAS Partners and Consultants as well as Customers and End Users. Contact Allan Bowe directly if you would like a dedicated internal session (4 or more people).

Data Controller for SAS® Now Available in the Microsoft Azure Marketplace

Mon, 27 Jul 2020 09:00:00 GMT

Microsoft Azure customers worldwide now gain access to Data Controller for SAS® to take advantage of the scalability, reliability, and agility of Azure to drive self-serve data management and data governance for regulated business environments.

London, UK - July 27, 2020

Analytium Group today announced the availability of Data Controller for SAS® in the Microsoft Azure Marketplace, an online store providing applications and services for use on Azure. Data Controller for SAS is an enterprise data governance and data workflow solution, maintained by Analytium Group, specialists in analytics and data-driven app development. Analytium Group customers can now take advantage of the productive and trusted Azure cloud platform, with streamlined deployment and management.

Why Data Controller?

With data arriving from all directions in a fast-moving business environment, it’s not always practical (or possible) to build automated, real-time processes for loading data into secure SAS environments. Data Controller for SAS enables business users in regulated cloud environments to self-serve their data uploads, and make safe and controlled updates to target tables with full data quality, approval step, and audit trail along the way.

Data Controller for SAS® has a web-based interface that allows nominated data owners to review all manual changes to data before they are applied, to maintain their data dictionary, and to set up data alerts and workflows. Other features include:

Data Catalog
Data Lineage
Data Alerts
DDL Export
Data Quality Rules
Excel / CSV Uploads

Data Controller leverages the access engines of SAS to provide native engine support, such as MS SQL Server, as well as regular SAS datasets and SAS Viya in-memory CAS Tables.

Data Controller on Azure

By running Data Controller for SAS® on Azure, it is easier for users to get started and deploy due to the power of the combined technologies providing even greater flexibility and scalability.

“We are excited to be both a SAS and a Microsoft partner and to help business users self-manage their cloud-based reference data” stated Allan Bowe, Head of SAS Apps at Analytium Group.

“Through Microsoft Azure Marketplace, customers around the world can easily find, buy, and deploy partner solutions they can trust, all certified and optimized to run on Azure,” said Sajan Parihar, Senior Director, Microsoft Azure Platform at Microsoft Corp. “We’re happy to welcome Analytium Group’s solution to the growing Azure Marketplace ecosystem.”

The Azure Marketplace is an online market for buying and selling cloud solutions certified to run on Azure. The Azure Marketplace helps connect companies seeking innovative, cloud-based solutions with partners who have developed solutions that are ready to use.

Learn more about Data Controller for SAS at its page in the Azure Marketplace.

About Analytium Group

Analytium Group works with leaders in the analytics industry, offering customer service that combines industry-leading technologies, proprietary products and open source technologies to create unique solutions on the SAS platform. Analytium Group’s expertise and agility helps clients to grow and be successful with their analytical goals and aspirations.

For more information, press only:

contact@analytium.co.uk
+44 (0) 203 9949 849
📮 86-90 4th Floor, Paul Street, London, EC2A 4NE

Modernising Legacy SAS SCL / AF Applications

Fri, 17 Jul 2020 17:29:47 GMT

Before SAS Studio, and even EG (but after display manager), there was a desktop application used exclusively for accessing SAS. It was known as Base SAS, and within it there was an application development facility known as SAS/AF.

This enabled point and click development of user interfaces, in a similar way to User Forms in VBA Excel. The application logic was driven by an object-orientated language known as SCL. SCL code was compiled, saved in catalogs, and the resulting application was often stored on a network drive and launched by end users.

Legacy SAS/AF SCL Apps

It’s fair to say these applications were a massive success, as many of them are still alive today - surviving decades of technological evolution! Still, as organisations have matured, the following challenges transpired:

Security. Especially of source files, and password management.
Scalability. Deploying SCL apps to each client machine is non-trivial.
Support. The original developers are usually long gone, and SCL resources are few and far between.
User Experience. This was an 80s product and.. it shows.

So, what to do about it? These applications are often complex, business critical, and heavily embedded in the SAS infrastructure. Well, as it happens, there is a tidy solution, quick to implement, and keeps everything within SAS. So what is it?

HTML5 SAS Web Apps

Web apps are a natural migration for legacy AF. Secured by your existing enterprise authorisation mechanism (SASLogon), they are highly scalable, easy to support, quick to build, and very user friendly.

When building web apps on SAS, it’s super important to separate the frontend logic (the domain of a web developer) from the backend (idempotent, stateless SAS programs). A typical modernisation project will begin by creating UX diagrams, wireframes, and screenshots to mockup the visuals and diagramming the application logic. This means that the gory details of the AF part, ie all the call display() and call next() routines (and associated catalog entries) are effectively disregarded, and completely rebuilt using modern design methods and javascript frameworks.

But what about the data logic? All the SLISTS, SCL programs, subroutines and methods? The good news is that much of this can be re-used. The fact is that SCL is based on, and works very similarly to, good old base SAS. This led to the development of the SCL Transcoding Kit, a framework / approach that lets you migrate SCL entries directly over to SAS (eg to run in a SAS 9 Stored Process or Job Execution Service on Viya), without the need for an AF License.

Running SCL in SAS Studio

The full list of supported functions includes:

clearlist() Empty a list
copylist() Copy a list
delitem() Deletes an item from an SCL list
dellist() Deletes a list
delnitem() Deletes a named item from an SCL list
format() Verifies that the specified format is valid
getitemc() Returns a value identified by its position in an SCL list
getiteml() Returns a value identified by its position in an SCL list
getitemn() Returns a value identified by its position in an SCL list
getnitemc() Return a value identified by name in an SCL list
getniteml() Return a value identified by name in an SCL list
getnitemn() Return a value identified by name in an SCL list
insertc() Insert a value into an SCL list
insertl() Insert a value into an SCL list
insertn() Insert a value into an SCL list
itemtype() Returns the type of an item in an SCL list
listlen() Returns the length of an SCL list
lvarlevel() Fills a list with unique values from a table column
makelist() Creates an SCL list
nameditem() Returns the index of a named item in a list
nameitem() Returns the name of an item in an SCL list
putlist() Displays the contents of an SCL list in the LOG window
savelist() Stores SCL list items in a dataset
searchc() Search for a value in an SCL list and return its position
searchn() Search for a value in an SCL list and return its position
setitemc() Store a value at an indexed position in an SCL list
setitemn() Store a value at an indexed position in an SCL list
setnitemc() Assign a value to a named item in an SCL list
setniteml() Assign a value to a named item in an SCL list
setnitemn() Assign a value to a named item in an SCL list
sortlist() Sorts the items in an SCL list by value or by name

Other than the fcmp library (referenced in the video above), this kit also lays out the process for exporting all the lists into a database, handling methods (with overloadable signatures), and migrating SCL entries into SAS code (hence, eradicating the use of catalogs).

Do you have legacy AF / SCL you’d like modernised? We’d love to help. Do get in touch for a no-obligation chat.

Additional resources

LinkedIn Article
SAS AF/SCL Slides
SAS UK Forum presentation
Info on SLISTS