About BrunoMueller

BrunoMueller · ‎07-31-2025

Yes, I forgot about that when input and outout are both from CAS it runs in CAS, thanks for the correction. I will make a change to my post.

BrunoMueller · ‎07-31-2025

I was wrong about this "The previous example with the DATA step runs on the compute server, all data will be read from CAS and written back to CAS. Depending on the size this may take some time." thanks for the correction @yabwon . The CAS server supports executing FedSQL, not all statements are supported see https://go.documentation.sas.com/doc/en/pgmsascdc/v_065/casfedsql/p0ipyarz6fe3mvn1hc8ega07irv6.htm for more details. We can make use of the casting functionality within FedSQL to change the length of char or varchar column. Below is an example program that does this. It is executing on the CAS server so no data transfer between CAS and compute. /* * change length of a char/varchar column * one needs to make a copy of an existing table * * the create table does support the {options replace=true} table option * however FedSQL will always create a session scope table */ cas sugus sessopts=(caslib="casuser"); /* * load some sample data, has session scope */ proc casutil; load data=sashelp.cars casout="mycars" replace; run; quit; title "columns before"; proc cas; action table.columninfo / table="mycars"; run; quit; title; proc cas; /* * build column expressions * we use the CAST()/:: function to change the length */ action table.columninfo result=cols / table={caslib="casuser" name="mycars"}; sqlCols=" "; do colInfo over cols.columnInfo; colName=colInfo.column; colExpression=colName; /* change as needed */ if colName="Model" then do; colExpression=catx(" ", quote(colName), "::varchar(64) as", quote(colName)); end; /* change as needed */ if colName="DriveTrain" then do; colExpression=catx(" ", quote(colName), ":: varchar(32) as", quote(colName)); end; sqlCols=catx(", ", sqlCols, colExpression); end; print(note) sqlCols; run; action table.droptable / caslib="casuser" name="mycars2" quiet=true; run; /* * create complete SQL statement * be aware that fedsql will always create a session scope table */ sqlStmt=catx(" " , "create table casuser.mycars2 as select" , sqlCols , "from casuser.mycars;" ); print(note) sqlStmt; action fedsql.execdirect / query=sqlStmt; run; quit; title "columns after"; proc cas; action table.columninfo / table="mycars2"; run; quit; title;

BrunoMueller · ‎07-21-2025

In SAS Viya 3.5 the activity entries are not available. See this article https://communities.sas.com/t5/SAS-Communities-Library/Auditing-Report-Actions-in-SAS-Viya-3-x/ta-p/959712 by for more details on auditing report operations. Or go the way as outline by @gwootton .

BrunoMueller · ‎07-16-2025

Please provide the version information on SAS Viya you are interessted in. As of SAS Viya 20nn.nn there are no longer traditional log files. The information on which reports have been accessed, can be returned using the sas-viya audit list-activities command (tested with Stable 2025.06). Here is an example: sas-viya --output json audit list-activities --application-contains Visual --sort-by timeStamp --limit 100 --action read --user-interaction-contains Open The command will return JSON output. A activity entry will look like below. { "action": "read", "administrativeAction": false, "application": "SAS® Visual Analytics", "correlator": "dfd7180f-c19f-4dd8-847a-2b35f1dbebc3", "httpContext": { "method": "GET", "statusCode": 200 }, "id": "7fca62e6-ccc1-4aba-8897-2d10efdffb1a", "links": [ { "href": "/audit/activities/7fca62e6-ccc1-4aba-8897-2d10efdffb1a", "method": "GET", "rel": "self", "type": "application/vnd.sas.audit.activity", "uri": "/audit/activities/7fca62e6-ccc1-4aba-8897-2d10efdffb1a" } ], "objectName": "cars-simple", "objectType": "report", "properties": { "referringApplication": "SASVisualAnalytics" }, "references": [], "secure": true, "serviceName": "reports", "sessionId": "a8bbbb4b-d8f0-4e38-ab06-df83840d430b", "state": "success", "timeStamp": "2025-07-16T13:43:50.037Z", "type": "resource", "uri": "/reports/reports/130a9b58-d93b-4f24-8478-ff02d416ff3b/content", "user": "sean", "userInteraction": "Open report cars-simple", "version": 8 } A non admin user will only see his entries. A SAS admin will see all entries There are many more options to the mentioned command. For instance to select a specifc time window using --after and|or --before. Note the --limit option, by default only 50 entries are returned.

BrunoMueller · ‎07-10-2025

As the documentation states, this action can not be run using Proc CAS; action table.upload ...; See the CASL UPLOAD statement for details. As for the question you mentioned: Which action loads the cars.csv file from the casuser caslib into memory? This is the table.loadTable action.

BrunoMueller · ‎07-10-2025

In the documentation for this action it states: Note: The upload action cannot be run from CASL, Python, and other clients in the same way that other actions like loadTable are run. Each client provides a client-specific function or method for transferring data to the server that runs the upload action. So which client application are you using? Is it a SAS program?

BrunoMueller · ‎07-02-2025

@ronan Yes this will impact the use of Group-Managed Service Account For instance in the Monitoring tab you can not longer select the service account to see the executed jobs. If you try the "Run as" action in the Scheduling tab you will receive this error: As mentioned because of unwanted side effects, these properties are not enabled by default. There might be a way using rules. This will be additional maintenance and possibly have a performance impact. I have not investigated this any further but it is worth a try.

BrunoMueller · ‎06-30-2025

In a recent question on communities.sas.com, someone asked whether it is possible to limit the users or groups a user can see. The API for the identities service, that provides this information is not public. However any user could make use of the sas-viya CLI to list this information. Depending on the setup, phone numbers or addresses etc. might be shown. This might not be something you want. In this post we will look at configuration settings that allow an administrator to control what non-administrative users can see when they make use of the sas-viya CLI identities plugin to list users and groups or show details about a user. Topics we will look into Overview of properties Example for each configuration property Are there any side effects How to set the properties using the sas-viya CLI Overview of properties The following table, from the documentation, shows the configuration properties of the Identities service that will change what the non-administrative users can see. These options are available since LTS 2023.10. Note that by default none of the properties are enabled. Property Default Value Definition endpoints.secured.groups: not enabled by default When enabled, limits non-administrative users’ Read access for groups. endpoints.secured.members: not enabled by default When enabled, limits non-administrative users’ Read access for group members. endpoints.secured.memberships: not enabled by default When enabled, limits non-administrative users’ Read access for group and user memberships. endpoints.secured.users: not enabled by default When enabled, limits non-administrative users’ Read access for other users. You can find these settings in the SAS Environment Manager -> Configuration page Please note, there is a new checkmark icon beside the pencil icon that indicates whether the default is used or it has been modified (no checkmark icon). Example for each configuration property We will look at the effect each property has. Please note: there is a delay from enabling the property to it being applied, allow for 10-20 seconds before checking the result. Impact of endpoints.secured.users When this configuration property is enabled a non-administrative user will only see itself when asking for a list of users. See here a screenshot with disabled / enabled results. The sas-viya command shown in the screenshots uses the profile eric (-p eric), this means all the commands run as user eric. When enabled you can no longer show detailed information for another user. Example: By enabling the endpoints.secured.users property, you prevent non-administrative users from seeing details of other users, or even that other users exist. In the above example we can see that eric can view the user eric (himself), but he can not view the information for another user (christine). This might already be all you need. Impact of endpoints.secured.groups When this property is disabled (default) a non-administrative user will see all the groups when using a command like this: sas-viya -p eric identities list-groups When this property is enabled only the groups the user is a member of, either directly or through group membership, are displayed: In the example above the user eric has the following group memberships: Impact of endpoints.secured.members So far we have seen the impact of the endpoints.secured.users and endpoints.secured.groups properties. The user can still list all members of a group he belongs to. Example: When endpoints.secured.members is enabled, the same command will only list the user that makes the request: Impact of endpoints.secured.memberships The sas-viya CLI identities plugin has a command list-memberships that allows to either provide a user (--user-id) or a group (--group-id) to list their memberships. When this property is enabled (all others are disabled) a non-administrative user can only see groups: of which the current user and the given user (--user-id) are both members of which the current user and the given group (--group-id) are both members Example: The first command is run as eric requesting to see memberships of user delilah. Only the group NestedGroup01 is displayed since delilah is a direct member of NestedGroup01 and eric is a member of NestedGroup02 which is a member of NestedGroup01. The second command is run as SAS administator so all groups where delilah is a member of are displayed. In other words, when the endpoints.secured.memberships property is enabled, the current user can only see groups which a named user or group is in, where the current user is also a member of those groups. So if the named user or group is a member of one or more groups that the current user is not a member of, the current user cannot see that the named user or group is a member of those other groups. Are there any side effects Will the above settings have any side effects. Yes they will! Below are some examples of functionality impacted. Can I still share SAS Content objects like a Visual Analytics report? Yes this is possible. Can I still distribute a Visual Analytics report to other users? No! Since you no longer can read specific user information for other users, it is not possible to read for instance the email address from another user, so you will get an error as shown below. This is not a complete list of side effects. This is the reason, why these configuration properties are not enabled by default. You have to decide what will work for you and which side effects you can live with, when enabling these configuration properties. How to set the properties using the sas-viya CLI Configuration properties can be set using the Configuration page in SAS Environment Manager. But often it is desirable to do this using a scipt. See here for the steps necessary to do this. Read the mediatype for what we want to change and store it in an environment variable MEDIATYPE=$(sas-viya configuration configurations download -d sas.identities | jq -r '.items[]["metadata"]["mediaType"] ') Next create a JSON file with the properties we want to change tee /tmp/update_identities_settings.json > /dev/null << EOF { "name": "identities configurations", "items": [ { "metadata": { "isDefault": false, "mediaType": "${MEDIATYPE}" }, "endpoints.secured.users": true, "endpoints.secured.groups": true, "endpoints.secured.members": true, "endpoints.secured.memberships": true } ] } EOF Update the configuration instance sas-viya configuration configurations update --file /tmp/update_identities_settings.json Verify the settings CFG_ID=$(sas-viya configuration configurations download -d sas.identities | jq -r '.items[]["id"] ') sas-viya configuration configurations show --id $CFG_ID The output looks like this: sas-viya configuration configurations show --id $CFG_ID id : 0da33450-35e0-4b23-bbe1-3fa78a042ab1 metadata.isDefault : false metadata.mediaType : application/vnd.sas.configuration.config.sas.identities+json;version=5 metadata.services : [identities] cache.cacheRefreshInterval : 12h cache.enabled : true cache.providerPageLimit : 1000 defaultProvider : local endpoints.secured.groups : true endpoints.secured.members : true endpoints.secured.memberships : true endpoints.secured.users : true identifier.disableGids : false identifier.disallowedUids : 1001 identifier.generateGids : false identifier.generateUids : false identifier.homeDirectoryPrefix : /home Summary By default any user can get a list of all users and groups. Any user can display the details about another user, or list the members of a specific group. By enabling the named properties the administrator can restrict the access for a non-administrative user to only himself and the groups he is a member of (direct or indirect). Some functionality within SAS applications might be affected. Find more articles from SAS Global Enablement and Learning here.

BrunoMueller · ‎06-23-2025

Give this code a try, you might need to adapt it to your needs. It uses a format to display F as Female and M as Male. It makes use of Proc SQL to count the number F and M and write tem into a macro variable. These macro variables are then used for the legenditems. proc format; value $gender "F" = "Female" "M" = "Male" ; run; proc sql ; select sum(sex="F") as fCount , sum(sex = "M") as mCount into :fCount , :mCount from sashelp.class ; quit; proc sgplot data=sashelp.class noautolegend; format sex $gender.; styleattrs datacolors=(lightgreen lightblue) datacontrastcolors=(blue green) datasymbols=(Trianglefilled squarefilled ); vbox height / category=sex groupdisplay=cluster name='vbox' boxwidth=0.2; xaxis label="sex" offsetmax=0.12 labelattrs=(size=9pt weight=bold family='Arial') valueattrs=(weight=bold size=9pt family='Arial'); yaxis label="height" min=-10 max=100 values=(-10 to 100 by 10) labelattrs=(size=10pt weight=bold) valueattrs=(weight=bold size=9pt family='Arial') fitpolicy=none; refline 0 / axis=y lineattrs=(color=grey pattern=3); legenditem TYPE=text name="fCount" / text="&fCount Females" ; legenditem TYPE=text name="mCount" / text="&mCount Males" ; keylegend "fCount" / location=outside position=bottom noborder ; keylegend "mCount" / location=outside position=bottom noborder ; run;

BrunoMueller · ‎06-19-2025

You can install it using this command sas-viya plugins install --repo SAS identities

BrunoMueller · ‎06-04-2025

This sounds like this question here https://communities.sas.com/t5/Administration-and-Deployment/How-to-give-an-usergroup-edit-permission-of-VA-reports-in-their/m-p/967088#M29974 As long as the user only has the Read and Read(Convey) permission on the folder they will not be able to save a report in this given folder. Granted they can still go into edit mode, but they can not save the report.

BrunoMueller · ‎06-03-2025

Question: once the new report is saved, is this considered an existing report and can no longer be edited?

BrunoMueller · ‎05-22-2025

Yes this is correct. The ability to edit or view a report is controlled by the functional URI "/SASVisualAnalytics_capabilities/edit". This is independent of the location of the report.

BrunoMueller · ‎05-21-2025

Individual users have the permission to read/write to their "My Folder" no special settings are needed. For the folder where the production reports are, the users need the Read and the Read (convey) permission. this allows them to open a report, but not save it to this folder. Whether a user can actually edit a report, independent of its location, this is controlled by the functional URI "/SASVisualAnalytics_capabilities/edit". By default all users are allowed to create/edit reports. See Manage Access to Features: URI Reference for more details;

BrunoMueller · ‎05-21-2025

Glad you found a solution. It seems that the LOC function uses char values and if the length does not match it will not be found. Another way of doing this, would be to get the values into an array and then use this expression: newArray = columnNamesArray & lookupArray; This will return only common values in both arrays, see CASL Array Operrators for more details. the length of the values does not seem to matter. Here is the code I used for testing: %let namer=ts; %let namer2=a123456789b123456789c123456789; %let namer3=a123456789b123456789c123456789d1; %let casy=cars; %let liby=casuser; cas mySession sessopts=(caslib="&liby"); libname casuser cas caslib="casuser"; data casuser.cars; set sashelp.cars; format &namer &namer2 datetime20. ; &namer=intnx('dtminutes', datetime(), rand('integer', -1000, 0)); &namer2=&namer; &namer3=put(rand('uniform', 0, 1), best12.); run; proc cas; table.columninfo result=r / table="&casy"; columns = ''; search_cols=''; /* array with names to search for */ search_cols_array = {}; do i = 1 to r.columninfo.nrows; if index(UPCASE(r['columninfo'][i,7]), 'DATETIME') THEN do; symput('col', ifc(prxmatch('m/\s/i',r[1,i].column), '''||r[1,i].column||''n', r[1,i].column)); /* fill array with search values */ search_cols_array = search_cols_array + r[1,i].column; columns = columns||' '||symget('col'); search_cols = strip(search_cols||'|'||symget('col')); end; end; print(note) "search_cols_array=" search_cols_array; symput('ok_list', substrn(search_cols,2,length(search_cols)-1)); symput('varlist', substrn(columns,2,length(columns)-1)); run; %put &=ok_list; %put &=varlist; run; simple.summary result=sumres / subset={'min', 'max'}, table="&casy"; /* describe sumres.summary; */ sumlist=findtable(sumres); colNames = GETCOLUMN(sumlist, "Column"); print(note) "colNames=" colNames; commonArray = colNames & search_cols_array; print(note) "commonArray summary=" commonArray; run; simple.distinct result=dist / table="&casy"; describe dist.distinct; colNames = GETCOLUMN(dist.distinct, 1); print(note) "colNames=" colNames; commonArray = colNames & search_cols_array; print(note) "commonArray distinct=" commonArray; run; quit;

Online Status	Offline
Date Last Visited	Thursday