A boilerplate setup for testing SCR images
Looking for an easy way to test and validate decision flows with SAS Container Runtime (SCR)? Then have a look at SAS Container Runtime Testbench.
SCR Testbench provides boilerplate setups for running your decision flows in SCR on your own laptop. Once set up, it only takes a few moments to deploy a decision from your Viya environment; you don’t even need a SAS Container Runtime publishing destination. Do your decisions use advanced lists or data queries? SCR Testbench comes preconfigured with Redis or Oracle.
Three deployment variants are configured with Docker compose:
- Standalone SCR container
- SCR and Redis supporting ID advanced lists
- SCR bundled with Oracle
About SAS Container Runtime
SAS Container Runtime (SCR) is a lightweight OCI (Open Container Initiative) compliant container that scores SAS models and decisions. This enables you to run models and decisions on any OCI compliant compute system, including clusters that are based on Docker and Kubernetes. Deployments to cloud or on-premises systems are both supported.
You create a SAS Container Runtime image by publishing models from SAS Model Manager and decisions from SAS Intelligent Decisioning.
About SAS Container Runtime Testbench
SCR Testbench was originally created for a SAS client that works with SAS Intelligent Decisioning (ID) and SAS Container Runtime. The ID users requested a quick way to test and debug decisions in SCR. Doing regular deployments required sending tickets to the operations team and could be quite time consuming. Also, things like log access and debugging were not always straightforward.
SAS consultants provided “SAS Container Runtime Testbench” to address this. Introducing SCR Workbench shortened the feedback loop significantly – from hours/days to minutes. By running both DBMS and SCR on the developer’s own desktop (via docker compose), they have unrestricted access to:
- Logs
- Command line
- File system
- Create, delete, and alter tables
- Package installation
which makes testing new ideas and debugging significantly easier.
Demonstration
Note: To follow along, you’ll need a docker install, for example Docker desktop on WSL2. Also, Docker must be signed in to the SAS container registry at cr.sas.com. More details in README.md.
We have this basic decision flow “sample-oracle” with an Oracle query. This decision flow has already been deployed to the sample Docker compose application scr-oracle.
The decision applies a SQL code file to look up HEIGHT in the Oracle table CLASS. Now, we want to test it out in a container. First, we clone the repo from GitHub. In a Linux command prompt type:
git clone https://github.com/sas-institute-shared/tmp-scr-testbench.git
Let’s check out the contents of scr-oracle/:
Now, we’ll build and run the container. To do this, we issue the command:
docker compose up -d
The very first time, we’ll need to wait a little while containers are being downloaded and configured. Eventually, the console looks like:
Notice that both containers have started. Let’s call the decision from postman. We POST {"data": {"name": "Mary"}} to http://localhost:8083/scr-oracle:
Or we can do the same thing from command line with curl:
Let’s try with a different example. Again, we do a basic decision flow with a database select, but this time we run a different query: SELECT origin FROM cars WHERE name=name. In Intelligent Decisioning it looks like this:
First, we deploy the new decision flow using the script ../deploy.py.
Notice how simple that was. We just apply the decision URL from the browser (red box in above screenshots). Now, let’s rebuild and redeploy the container application. We run the command docker compose up -d --build:
That only took 11 seconds. Now let’s test using Postman. The endpoint is still http://localhost:8083/scr-oracle.
Oops – that failed. HTTP 500 INTERNAL_SERVER_ERROR is not what we want to see. Let’s examine why.. We check the SCR log using docker container logs scr-oracle:
A little down, we notice an issue:
Aha – the table CARS does not exist. That looks like the root cause. Let’s add that table to Oracle. We modify 02_create_sample_data.sql, add these lines to create the table:
CREATE TABLE cars (
name VARCHAR2(32),
origin VARCHAR2(32));
INSERT INTO cars(name, origin) VALUES('Ford', 'US'); INSERT INTO cars(name, origin) VALUES('Audi', 'Germany'); INSERT INTO cars(name, origin) VALUES('Toyota', 'Japan');
After rebuilding + redeploying with the addition of the necessary table, which may take a little longer as it must rebuild the database container, we test again in postman:
Conclusion
I hope this little demo illustrated the power of running/debugging decisions locally on you own desktop, where you have full control. Testing/debugging becomes very easy and accessible.
