chore: automated commit
This commit is contained in:
parent
0a02f44892
commit
01dac2ffef
2
.gitignore
vendored
2
.gitignore
vendored
@ -1,4 +1,4 @@
|
|||||||
site/
|
site/
|
||||||
*.swp
|
*.swp
|
||||||
node_modules/
|
node_modules/
|
||||||
.DS_Store
|
*.DS_Store
|
||||||
|
@ -7,35 +7,63 @@ og_image: https://docs.datacontroller.io/img/dci_deploymentdiagram.png
|
|||||||
|
|
||||||
# SAS 9 Deployment
|
# SAS 9 Deployment
|
||||||
|
|
||||||
## Overview
|
## Artefacts
|
||||||
Data Controller for SAS 9 consists of a frontend, a set of Stored Processes, a staging area, 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.
|
|
||||||
|
Data Controller for SAS 9 consists of:
|
||||||
|
|
||||||
|
* Frontend on the web server
|
||||||
|
* Stored Processes in metadata
|
||||||
|
* Staging Area on the filesystem
|
||||||
|
* Database / SAS library
|
||||||
|
|
||||||
|
### Frontend
|
||||||
|
A full deployment involves copying a directory with static web content onto the web server. The demo deployment allows that content to be served from Stored Processes, in which case no web server access is needed. This approach is not recommended for enterprise use however, as it places unnecessary load on the STP server (the web server is much faster for serving static content).
|
||||||
|
|
||||||
|
### Stored Processes
|
||||||
|
In SAS 9, all backend logic is performed with SAS code in Stored Processes. The code is embedded within the Stored Processes (no need to deploy programs to the file system). There is no use of X commands, and no requirement for internet access.
|
||||||
|
|
||||||
|
### Staging Area
|
||||||
|
This is a backend directory, on the Application Server, in which the staged data, logs, and copies of any uploaded Excel files, are securely stored.
|
||||||
|
|
||||||
|
### Database
|
||||||
|
The library can be a SAS Base engine if desired (using datasets), 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.
|
A database that supports concurrent access is recommended.
|
||||||
|
|
||||||
## Backend
|
## Deployment Process
|
||||||
|
### 1 - Import SPK
|
||||||
|
|
||||||
1 - Import `/sas/import.spk` using SAS Management Console. Make a note of the root location in which this was deployed - as this will be added to the `appLoc` value in the `index.html` file in the [frontend](#frontend) deployment.
|
Import `/sas/import.spk` using SAS Management Console or DI Studio. Make a note of the root metadata folder location in which this was imported - as this will be added to the `appLoc` value in the `index.html` file in the [frontend](#frontend) deployment later.
|
||||||
|
|
||||||
2 - Create a physical staging directory. This folder will contain the logs and CSV files generated by Users. The SAS Spawned Server account (eg `sassrv`) will need write access to this location.
|
When importing the library, provide the physical path in which the Staging Area should be created. The next step will use this path to create the directory. Make sure that the SAS Spawned Server account (eg `sassrv`) has WRITE access to this location
|
||||||
|
|
||||||
3 - Update the library to point to a schema in your preferred database
|
### 2 - Run the Configurator
|
||||||
|
|
||||||
4 - Deploy the physical tables and register them in metadata. For this, simply compile and run the `mpe_build()` macro using an account with appropriate privileges.
|
Open the browser and navigate to YOURSASSERVER/SASStoredProcess. From here, find the Data Controller folder, and open services/admin/configurator.
|
||||||
|
|
||||||
|
You will be provided with a list of groups. Choose the group that you would like to be the admin group.
|
||||||
|
|
||||||
!!! note
|
!!! note
|
||||||
Make sure the SAS Spawned Server account (eg `sassrv`) can access these tables!
|
Anyone in this admin group will have unrestricted access to Data Controller!
|
||||||
|
|
||||||
## Frontend
|
After you click submit, the stored process will run, configure the staging area and create the library tables (as datasets).
|
||||||
|
|
||||||
|
At this point you can already open the app (demo version).
|
||||||
|
|
||||||
|
### 3 - Deploy the Frontend
|
||||||
The Data Controller frontend comes pre-built, and ready to deploy to the root of the SAS Web Server (mid-tier), typically `!SASCONFIG/LevX/Web/WebServer/htdocs` in SAS 9.
|
The Data Controller frontend comes pre-built, and ready to deploy to the root of the SAS Web Server (mid-tier), typically `!SASCONFIG/LevX/Web/WebServer/htdocs` in SAS 9.
|
||||||
|
|
||||||
Deploy as follows:
|
Deploy as follows:
|
||||||
|
|
||||||
1 - Unzip dcfrontend.zip and upload the entire `datacontroller` directory to the static content server.
|
1 - Unzip dcfrontend.zip and upload the entire `datacontroller` directory to the static content server (htdocs folder).
|
||||||
|
|
||||||
2 - Open the `index.html` file and update the `appLoc` value to the location where the Stored Processes were deployed earlier.
|
2 - Open the `index.html` file and update the `appLoc` value to the location where the Stored Processes were deployed earlier.
|
||||||
|
|
||||||
It should now be possible to use the application - simply navigate to `YOURSASWEBLOC:port/yourRoot/datacontroller` and sign in!
|
It should now be possible to use the application - simply navigate to `YOURSASWEBLOC:port/yourRoot/datacontroller` and sign in!
|
||||||
|
|
||||||
The next step is to [configure](dcc-tables.md) the tables.
|
### 4 - Configure the Database
|
||||||
|
If you have a database available, then we recommend you use it for storing the data controller configuration tables. This part involves migrating the data from the BASE library to your database schema, and updating the library definition in metadata.
|
||||||
|
|
||||||
|
Contact us for support with DDL and migration steps for your chosen vendor.
|
||||||
|
|
||||||
## Deployment Diagram
|
## Deployment Diagram
|
||||||
|
|
||||||
@ -67,7 +95,7 @@ The items deployed to metadata include:
|
|||||||
* Stored Processes
|
* Stored Processes
|
||||||
* Library Object & tables
|
* Library Object & tables
|
||||||
|
|
||||||
After the installation process (which updates `settings` and removes the `makedata` STP), there are no write actions performed against metadata.
|
After the installation process (which updates `public/settings` and removes the `admin/makedata` STP), there are no write actions performed against metadata.
|
||||||
|
|
||||||
### Databases
|
### Databases
|
||||||
|
|
||||||
@ -75,5 +103,6 @@ We strongly recommend that the Data Controller configuration tables are stored i
|
|||||||
|
|
||||||
We provide the DDL for creating the tables, we have customers in production using Oracle, Postgres, Netezza, SQL Server to name a few.
|
We provide the DDL for creating the tables, we have customers in production using Oracle, Postgres, Netezza, SQL Server to name a few.
|
||||||
|
|
||||||
|
!!! note
|
||||||
Data Controller does NOT modify schemas! It will not create or drop tables, or add/modify columns or attributes. Only rows can be modified using the tool.
|
Data Controller does NOT modify schemas! It will not create or drop tables, or add/modify columns or attributes. Only rows can be modified using the tool.
|
||||||
|
|
||||||
|
BIN
docs/marketing/linkedin_campaign/.DS_Store
vendored
BIN
docs/marketing/linkedin_campaign/.DS_Store
vendored
Binary file not shown.
Loading…
Reference in New Issue
Block a user