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

chore(docs): updated info about hook scripts
Some checks failed
Publish to docs.datacontroller.io / Deploy docs (push) Failing after 41s
Details

Browse Source
This commit is contained in:
Allan 2023-07-24 10:00:08 +01:00
parent 617ff1dffb
commit c6cf00a0c3
1 changed files with 10 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/dcc-tables.md
View File

@ -45,7 +45,7 @@ The loadtype determines the nature of the update to be applied. Valid values are
This is a required field.
!!! Note
The support for BITEMPORAL loads is restricted, in the sense it is only possible to load data at a single point in time (no support for loading _multiple_ business date ranges for a _specific_ BUSKEY). The workaround is simply to load each date range separately. As a result of this restriction, the EDIT page will only show the latest business date range for each key. To modify earlier values, a filter should be applied.
The support for BITEMPORAL loads is restricted, in the sense it is only possible to load data at a single point in time (no support for loading _multiple_ business date ranges for a _specific_ BUSKEY). The workaround is simply to load each date range separately. As a result of this restriction, the EDIT page will only show the latest business date range for each key. To modify earlier values, a filter should be applied.
### BUSKEY
@ -108,7 +108,11 @@ If your DQ check means that the program should not be submitted, then simply exi
### PRE_APPROVE_HOOK
[Hook script](#hook-scripts) to execute before the approval diff is generated. It can be used to modify the values presented to an approver on the approve screen. This can be helpful in order to present the data in way that can be easily consumed by approvers.
This [hook script](#hook-scripts) will execute twice during a typical workflow - firstly, before the approval diff is generated, and again after the approval (not rejection) and _before_ the change is applied.
This makes it a helpful place to prevent changes being made, eg in situations where the target table needs to be locked by alternative systems.
It can also be used to apply display formats.
Leave blank if not required.
@ -119,13 +123,13 @@ SAS Developer Notes:
### POST_APPROVE_HOOK
This [hook script](#hook-scripts) is `%inc`'d _after_ an approval is made. This is the most common type of hook script, and is useful for, say, running a SAS job after a mapping table is updated, or running a model after changing a parameter.
This [hook script](#hook-scripts) is `%inc`'d _after_ an approval is made. This is the most common type of hook script, and is useful for, say, running a SAS job after a mapping table is updated, or running a model after changing a parameter.
Leave blank if not required.
SAS Developer Notes:
At the point of running this script, the data has already been loaded (successfully) to the target table. Therefore the target is typically the base libref.table (or format catalog) itself and can be referenced directly (YOURLIB.YOURDATASET), or using either of the following macro variable:
At the point of running this script, the data has already been loaded (successfully) to the target table. Therefore the target is typically the base libref.table (or format catalog) itself and can be referenced directly (YOURLIB.YOURDATASET), or using either of the following macro variable:
* `&orig_libds`
* `&libref..&ds`
@ -142,11 +146,11 @@ If you are making changes to the target table as part of the hook, then in order
ref=Locking table to peform a post approve hook action
ctl_ds=&mpelib..mpe_lockanytable
)
/* do stuff */
proc sort data=somelib.sometable;
run;
/* unlock */
%mp_lockanytable(UNLOCK,
lib=SOMELIB,