feat: updated viya flow
All checks were successful
Publish to docs.datacontroller.io / Deploy docs (push) Successful in 1m2s

This commit is contained in:
_
2026-02-27 14:01:01 +00:00
parent ca8499de90
commit 5dfbc2526e
2 changed files with 39 additions and 59 deletions

View File

@@ -8,8 +8,7 @@ og_image: https://docs.datacontroller.io/img/dci_deploymentdiagramviya.png
# SAS Viya Deployment
## Overview
Data Controller for SAS Viya consists of a frontend, a set of Job Execution Services, a staging area, a Compute Context, and a database library. The library can be a SAS Base engine if desired, however this can cause contention (eg table locks) if end users are able to connect to the datasets directly, eg via Enterprise Guide or Base SAS.
A database that supports concurrent access is recommended.
Data Controller for SAS Viya consists of a static web frontend, a set of Viya Jobs, a staging area (physical directory), a Compute Context, and a Library.
## Prerequisites
@@ -17,10 +16,8 @@ A database that supports concurrent access is recommended.
Data Controller makes use of a system account for performing backend data updates and writing to the staging area. This needs to be provisioned in advance using the Viya admin-cli. The process is well described here: [https://communities.sas.com/t5/SAS-Communities-Library/SAS-Viya-3-5-Compute-Server-Service-Accounts/ta-p/620992](https://communities.sas.com/t5/SAS-Communities-Library/SAS-Viya-3-5-Compute-Server-Service-Accounts/ta-p/620992)
### Database
Whilst we do recommend that Data Controller configuration tables are stored in a database for concurrency reasons, it is also possible to use a BASE engine library, which is adequate if you only have a few users.
To migrate the control library to a database, first perform a regular deployment, and afterwards you can generate the DDL and update the settings file..
### Library
Currently, all of our customers are using the standard BASE engine library for the control tables. However it is possible to use a database instead. To migrate the control library to a database, first perform a regular deployment, and afterwards you can generate the DDL. For this, use the DDL exporter as described [here](/admin-services/#export-database). If you need a flavour of DDL that is not yet supported, [contact us](https://datacontroller.io/contact/).
Make sure the system account (see above) has full read / write access.
@@ -45,17 +42,18 @@ The below areas of the SAS Viya platform are modified when deploying Data Contro
Data Controller deployment is split between 2 deployment types:
* Streaming (web content served from SAS Drive)
* Full (web content served from dedicated web server)
* Seperated (web content served from dedicated web server)
For most customers, the streaming approach is preferred, as it makes the deployment much simpler.
There are several parts to this proces:
1. Create the Compute Context
2. Deploy Frontend (Full deploy only)
3. Deploy Services
4. First Run Configuration
5. Prepare the database and update settings (optional)
6. Update the Compute Context autoexec
2. Deploy Services
3. Configure Frontend
4. First Launch
5. Optmisation
### 1. Create Shared Compute Context
@@ -74,19 +72,7 @@ We strongly recommend a dedicated compute context for running Data Controller.
!!! note
XCMD is NOT required to use Data Controller.
### 2. Deploy Frontend (Full Deploy only)
Unzip the frontend into your chosen directory (eg `/var/www/html/DataController`) on the SAS Web Server. Open `index.html` and update the following inside `dcAdapterSettings`:
- `appLoc` - this should point to the root folder on SAS Drive where you would like the Job Execution services to be created. This folder should initially, NOT exist (if it is found, the backend will not be deployed)
- `contextName` - here you should put the name of the compute context you created in the previous step.
- `servertype` - should be SASVIYA
- `debug` - can stay as `false` for performance, but could be switched to `true` for debugging startup issues
- `useComputeApi` - use `true` for best performance.
![Updating index.html](img/viyadeployindexhtml.png)
### 3. Deploy Services
### 2. Deploy Services
Services are deployed by running a SAS program.
@@ -100,53 +86,47 @@ filename dc url "https://git.datacontroller.io/dc/dc/releases/download/latest/vi
%inc dc;
```
#### Deploy Services: Full Deploy
#### Deploy Services: Seperated Deploy
Run the following in SAS Studio:
```sas
%let apploc=/Public/DataController; /* Per configuration in Step 2 above */
%let apploc=/Public/DataController; /* desired SAS Drive location */
filename dc url "https://git.datacontroller.io/dc/dc/releases/download/latest/viya_noweb.sas";
%inc dc;
```
### 4. First Run Configuration
### 3. Configure Frontend
#### Configure Frontend: Streaming Deploy
At the end of the SAS log from Step 2, there will be a link (`YOURSAS.SERVER/SASJobExecution?_file=/YOUR/APPLOC/services/DC.html`). Open this in **SASJobExecution** (not SAS Studio) to perform the configuration (below).
#### Configure Frontend: Seperated Deploy
Unzip the frontend into your chosen directory (eg `/var/www/html/DataController`) on the SAS Web Server. Edit `index.html` to perform the configuration (below).
#### Configuration:
- `appLoc` - the root folder where the Jobs were deployed in step 2
- `contextName` - here you should put the name of the compute context you created in step 1
- `servertype` - should be SASVIYA
- `debug` - can stay as `false` for performance, but could be switched to `true` for debugging startup issues
- `useComputeApi` - use `true` for best performance.
### 4. First Launch
Now the services are deployed (including the service which creates the staging area) we can open the Data Controller web interface and make the necessary configurations:
#### First Run Configuration: Streaming Deploy
At the end of the SAS log from Step 3, there will be a link (`YOURSAS.SERVER/SASJobExecution?_file=/YOUR/APPLOC/services/DC.html`). Open this to perform the configuration - such as:
* dcpath - physical path for depleyment
* Admin Group - will have full access to DC
* Compute Context - should be a shared compute for a multi-user deployment
* dcpath - physical path for deployment (will contain SAS datasets and a subfolder for staged content)
* Admin Group - the members of this group will have full access to Data Controller
* Compute Context - the context configured in Step 1
### 5. Optmisation
#### First Run Configuration: Full Deploy
Open https://YOURSERVER/DataController (using whichever subfolder you deployed to above) using an account that has the SAS privileges to write to the `appLoc` location.
You will be presented with a deployment screen like the one below. Be sure to check the "Recreate Database" option and then click the "Deploy" button.
![viya deploy](img/viyadeployauto.png)
Your services are deployed! And the app is operational, albeit still a little sluggish, as every single request is using the APIs to fetch the content of the `$(appLoc)/services/settings.sas` file.
### 5. Deploy Database
If you have a lot of users, such that concurrency (locked datasets) becomes an issue, you might consider migrating the control library to a database.
The first part to this is generating the DDL (and inserts). For this, use the DDL exporter as described [here](/admin-services/#export-database). If you need a flavour of DDL that is not yet supported, [contact us](https://datacontroller.io/contact/).
Step 2 is simply to run this DDL in your preferred database.
Step 3 is to update the library definition in the `$(appLoc)/services/settings.sas` file using SAS Studio.
### 6.Update Compute Context Autoexec
To improve responsiveness by another 700ms we recommend you follow these steps:
At this point, every DC request will read the `services/public/settings.sas` file to get the DC library (and other) settings. To avoid these API calls (which will speed up the app) we can simply move this code to the autoexec. Steps as follows:
First, open the `$(appLoc)/services/settings.sas` file in SAS Studio, and copy the code.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 98 KiB