dc/docs.datacontroller.io
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: automated commit

Browse Source
This commit is contained in:
Allan Bowe 2021-09-09 13:34:59 +03:00
parent cf4d117286
commit 9f8474695e
2 changed files with 28 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
docs/admin-services.md
View File

@ -8,14 +8,14 @@ description: Data Controller contains a number of admin-only web services, such
Several web services have been defined to provide additional functionality outside of the user interface. These somewhat-hidden services must be called directly, using a web browser. The URL is made up of several components:
* SERVERURL -> the domain (and port) on which your SAS server resides
* EXECUTOR -> Either `SASStoredProcess` for SAS 9, else `SASJobExecution` for Viya
* APPLOC -> The root folder location in which the Data Controller backend services were deployed
* SERVICE -> The actual Data Controller service being described. May include additional parameters.
* `SERVERURL` -> the domain (and port) on which your SAS server resides
* `EXECUTOR` -> Either `SASStoredProcess` for SAS 9, else `SASJobExecution` for Viya
* `APPLOC` -> The root folder location in which the Data Controller backend services were deployed
* `SERVICE` -> The actual Data Controller service being described. May include additional parameters.
To illustrate the above, consider the following URL:
[https://sas.analytium.co.uk/SASJobExecution/?_program=/Public/app/viya/services/admin/exportdb&flavour=PGSQLg](https://sas.analytium.co.uk/SASJobExecution/?_program=/Public/app/viya/services/admin/exportdb&flavour=PGSQL
[https://sas.analytium.co.uk/SASJobExecution/?_program=/Public/app/viya/services/admin/exportdb&flavour=PGSQL](https://sas.analytium.co.uk/SASJobExecution/?_program=/Public/app/viya/services/admin/exportdb&flavour=PGSQL
)
This is broken down into:
@ -34,15 +34,17 @@ The below sections will only describe the `$SERVICE` component - you may constru
This service will provide a zip file containing the current database configuration. This is useful for migrating to a different data controller database instance.
EXAMPLE:
* `services/admin/exportconfig`
## Export Database
Exports the data controller control library in DB specific DDL. The following URL parameters may be added:
* &flavour= (only PGSQL supported at this time)
* &schema= (optional, if target schema is needed)
* `&flavour=` (only PGSQL supported at this time)
* `&schema=` (optional, if target schema is needed)
EXAMPLES:
* `services/admin/exportdb&flavour=PGSQL&schema=DC`
* `services/admin/exportdb&flavour=PGSQL`
@ -51,8 +53,9 @@ Refreshes the Data Controller data catalog. The model is stored in SCD2 so it's
The following params can be added:
* &libref (optional) to run the process for just one library.
* `&libref` (optional) to run the process for just one library.
EXAMPLES:
* `services/admin/refreshcatalog`
* `services/admin/refreshcatalog&libref=MYLIB`

23
docs/dci-deploysasviya.md
View File

@ -20,9 +20,9 @@ Data Controller makes use of a system account for performing backend data update
### 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.
Let us know which database you are using and we will provide the DDL. We have customers in production using Oracle, Postgres, Netezza, SQL Server to name a few.
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..
Simply run the provided DDL script to create the tables and initial configuration data in your chosen database. Make sure the system account (see prerequisites) has full read / write access.
Make sure the system account (see above) has full read / write access.
!!! note
"Modify schema" privileges are not required.
@ -49,12 +49,13 @@ Data Controller deployment is split between 3 deployment types:
## Full Version - Manual Deploy
-->
There are three main parts to this proces:
There are several parts to this proces:
1. Create the Compute Context
2. Deploy Frontend
2. Deploy Backend
3. Update the Compute Context autoexec
4. Prepare the database and update settings (optional)
5. Update the Compute Context autoexec
### Create Compute Context
@ -95,7 +96,17 @@ You will be presented with a deployment screen like the one below. Be sure to c
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.
To improve responsiveness by another 700ms we recommend you take the subsequent step below.
To improve responsiveness by another 700ms we recommend you follow the steps in [Update Compute Context Autoexec](/dci-deploysasviya/#update-compute-context-autoexec) below.
### 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.
### Update Compute Context Autoexec
First, open the `$(appLoc)/services/settings.sas` file in SAS Studio, and copy the code.