SAS Visual Analytics Administrator

4月 172017
 

In this post, I will explain how LASR Servers (both Distributed and Non-distributed) are started from the SAS Visual Analytics Administrator application. We will also look at one particular issue and I will provide you with more details to understand the situation and two strategies to address this issue.

When you start a LASR Server from the Visual Analytics Administrator application, the system processes your request in slightly different ways depending on whether you are starting a distributed or non-distributed LASR Server.

What happens in the background for a distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the distributed LASR Server startup code generated in step 2, and the SAS Workspace Server session executes it.

6.     As soon as the distributed LASR Server startup code is executed, a distributed LASR Server instance is created. This instance is independent from the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection drop down. But the LASR Server instance is up and persistent until the administrator stops it.

What happens for a non-distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the non-distributed LASR Server startup code generated on step 2, and the SAS Workspace Server session executes it.

6.     As soon as the non-distributed LASR Server startup code is executed, a non-distributed LASR Server instance is created. This instance is dependent on the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection become persistent until the administrator stops the non-distributed LASR Server.
The SAS Workspace Server session and the client connection are required for the non-distributed LASR Server to be up and persistent.

Potential non-distributed LASR Server issue

The client connection between the JES and the SAS Workspace Server session in non-distributed deployment is crucial. This connection has to be persistent during the non-distributed LASR Server lifetime. As soon as the JES or SAS Workspace Server session goes down, the client connection is broken and the non-distributed LASR Server will go down as well. And, its data become unavailable.

If administrators manage their SAS non-distributed LASR Servers from the SAS Visual Analytics Administrator web application, this will create a dependency between the non-distributed LASR Servers and the middle tier - more specifically with the SASServer1_1 instance (the sas.wip.soapservices application). This dependency does not exist for distributed LASR Servers.

When the dependency exists, each time the middle tier or the SASServer1_1 instance is down, all non-distributed LASR Servers that were managed using the SAS Visual Analytics Administrator will go down automatically because the client connection to the non-distributed LASR Server is broken and its associated SAS Workspace Server session will go down.

This issue will also appear if the network connection between the Middle Tier and the SAS Visual Analytics Root Node is broken. This will break the client connection and terminate the SAS Workspace Server session(s) and their associated non-distributed LASR Server(s).

How can we prevent the issue?

I can think of at least two techniques you can use to prevent the dependency of your non-distributed LASR Servers upon your middle-tier:

  • Start your non-distributed LASR Servers from a SAS program.
  • Configure your LASR Server to start using the AutoLoad facility.

Start your non-distributed LASR Server from a SAS program

Here is a sample program that you might use to start a non-distributed LASR Server:

/* Start the LASR Analytic Server by defining the LASR library*/
libname LASRLIB SASIOLA 
        startserver  host="sasserver01.race.sas.com" port=10013
        signer="sasserver05.race.sas.com:7980/SASLASRAuthorization";
 
/* Keep the SAS session up until SERVERTERM received */
proc vasmp;
   serverwait  port=10013;
quit;

 

This program could be scheduled or set as a service under UNIX or Windows to be executed as soon as SAS Visual Analytics is started/restarted. Whichever strategy you use, you will want to have the code run after these services are up and available:

The SAS Metadata Server.
The Object Spawner on the SAS Visual Analytics Root Node.
The SASLASRAuthaurization service on the Middle Tier:

Start the non-distributed LASR Server Using the AutoLoad capability

AutoLoad runs as a periodic scheduled task. In the standard configuration, a new run of AutoLoad is started every 15 minutes.
AutoLoad periodically scans the contents of a designated host directory, which is referred to as the AutoLoad data directory or drop zone.
AutoLoad will automatically start the associated SAS LASR Server, if it is not yet started.

If you do not already have a LASR library configured with AutoLoad, you will need to use the SAS Deployment Manager application to configure an AutoLoad directory.

In Administration Tasks, choose Configure an AutoLoad Directory for SAS Visual Analytics. And follow the instructions.

Once you have AutoLoad setup, you must make sure certain LASR Library Extended Attributes are set correctly to ensure that the AutoLoad process will automatically start your LASR Server. You will want to set/verify the following attributes for the LASR library:

  • To enable the LASR Server AutoStart only:

  • VA.AutoLoad.AutoStart: YES to indicate that you want the associated LASR Server to be started if it is not already running.
  • VA.AutoLoad.Enabled: YES to enable the AutoLoad process for the Library.
  • To enable the LASR table(s) AutoLoad (optional):

  • VA.Default.MetadataFolder: to relocate the table(s) metadata registration against a specific metadata folder.
  • VA.Default.Location: to specify the location of the table directory at OS level.
  • VA.Default.Sync.*: to manage the table(s) from the VA.Default.Location.

On your SAS Visual Analytics machine, you have to:

  • Set the appropriate security against the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef] to be sure that the appropriate LASR Server administrator will be allowed to manage it.
  • Set the AutoLoad process frequency (default is 15 minutes).
    “TIME_INTERVAL_MINUTES=[Your-Value]” in the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] file.
    Note: Reference the SAS Visual Analytics Administration Guide for more about  the timing of AutoLoad.
  • Schedule the AutoLoad process using the LASR Server administrator account responsible to manage this particular LASR Server by executing the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] script.

Validate the AutoLoad setup by stopping the SAS LASR Server from SAS Visual Analytics Administrator application, or using SAS code. Wait for the “TIME_INTERVAL_MINUTES=[Your-Value]“, and look at the LASR Server status in SAS Visual Analytics Administrator application, and the AutoLoad logs in [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/Logs (one log file each time the AutoLoad process is executed).

Whichever technique is used, the non-distributed LASR server will no longer be dependent on the middle-tier.

I hope this article has been helpful to you.

How LASR servers are started from SAS Visual Analytics Administrator was published on SAS Users.

4月 172017
 

In this post, I will explain how LASR Servers (both Distributed and Non-distributed) are started from the SAS Visual Analytics Administrator application. We will also look at one particular issue and I will provide you with more details to understand the situation and two strategies to address this issue.

When you start a LASR Server from the Visual Analytics Administrator application, the system processes your request in slightly different ways depending on whether you are starting a distributed or non-distributed LASR Server.

What happens in the background for a distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the distributed LASR Server startup code generated in step 2, and the SAS Workspace Server session executes it.

6.     As soon as the distributed LASR Server startup code is executed, a distributed LASR Server instance is created. This instance is independent from the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection drop down. But the LASR Server instance is up and persistent until the administrator stops it.

What happens for a non-distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the non-distributed LASR Server startup code generated on step 2, and the SAS Workspace Server session executes it.

6.     As soon as the non-distributed LASR Server startup code is executed, a non-distributed LASR Server instance is created. This instance is dependent on the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection become persistent until the administrator stops the non-distributed LASR Server.
The SAS Workspace Server session and the client connection are required for the non-distributed LASR Server to be up and persistent.

Potential non-distributed LASR Server issue

The client connection between the JES and the SAS Workspace Server session in non-distributed deployment is crucial. This connection has to be persistent during the non-distributed LASR Server lifetime. As soon as the JES or SAS Workspace Server session goes down, the client connection is broken and the non-distributed LASR Server will go down as well. And, its data become unavailable.

If administrators manage their SAS non-distributed LASR Servers from the SAS Visual Analytics Administrator web application, this will create a dependency between the non-distributed LASR Servers and the middle tier - more specifically with the SASServer1_1 instance (the sas.wip.soapservices application). This dependency does not exist for distributed LASR Servers.

When the dependency exists, each time the middle tier or the SASServer1_1 instance is down, all non-distributed LASR Servers that were managed using the SAS Visual Analytics Administrator will go down automatically because the client connection to the non-distributed LASR Server is broken and its associated SAS Workspace Server session will go down.

This issue will also appear if the network connection between the Middle Tier and the SAS Visual Analytics Root Node is broken. This will break the client connection and terminate the SAS Workspace Server session(s) and their associated non-distributed LASR Server(s).

How can we prevent the issue?

I can think of at least two techniques you can use to prevent the dependency of your non-distributed LASR Servers upon your middle-tier:

  • Start your non-distributed LASR Servers from a SAS program.
  • Configure your LASR Server to start using the AutoLoad facility.

Start your non-distributed LASR Server from a SAS program

Here is a sample program that you might use to start a non-distributed LASR Server:

/* Start the LASR Analytic Server by defining the LASR library*/
libname LASRLIB SASIOLA 
        startserver  host="sasserver01.race.sas.com" port=10013
        signer="sasserver05.race.sas.com:7980/SASLASRAuthorization";
 
/* Keep the SAS session up until SERVERTERM received */
proc vasmp;
   serverwait  port=10013;
quit;

 

This program could be scheduled or set as a service under UNIX or Windows to be executed as soon as SAS Visual Analytics is started/restarted. Whichever strategy you use, you will want to have the code run after these services are up and available:

The SAS Metadata Server.
The Object Spawner on the SAS Visual Analytics Root Node.
The SASLASRAuthaurization service on the Middle Tier:

Start the non-distributed LASR Server Using the AutoLoad capability

AutoLoad runs as a periodic scheduled task. In the standard configuration, a new run of AutoLoad is started every 15 minutes.
AutoLoad periodically scans the contents of a designated host directory, which is referred to as the AutoLoad data directory or drop zone.
AutoLoad will automatically start the associated SAS LASR Server, if it is not yet started.

If you do not already have a LASR library configured with AutoLoad, you will need to use the SAS Deployment Manager application to configure an AutoLoad directory.

In Administration Tasks, choose Configure an AutoLoad Directory for SAS Visual Analytics. And follow the instructions.

Once you have AutoLoad setup, you must make sure certain LASR Library Extended Attributes are set correctly to ensure that the AutoLoad process will automatically start your LASR Server. You will want to set/verify the following attributes for the LASR library:

  • To enable the LASR Server AutoStart only:

  • VA.AutoLoad.AutoStart: YES to indicate that you want the associated LASR Server to be started if it is not already running.
  • VA.AutoLoad.Enabled: YES to enable the AutoLoad process for the Library.
  • To enable the LASR table(s) AutoLoad (optional):

  • VA.Default.MetadataFolder: to relocate the table(s) metadata registration against a specific metadata folder.
  • VA.Default.Location: to specify the location of the table directory at OS level.
  • VA.Default.Sync.*: to manage the table(s) from the VA.Default.Location.

On your SAS Visual Analytics machine, you have to:

  • Set the appropriate security against the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef] to be sure that the appropriate LASR Server administrator will be allowed to manage it.
  • Set the AutoLoad process frequency (default is 15 minutes).
    “TIME_INTERVAL_MINUTES=[Your-Value]” in the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] file.
    Note: Reference the SAS Visual Analytics Administration Guide for more about  the timing of AutoLoad.
  • Schedule the AutoLoad process using the LASR Server administrator account responsible to manage this particular LASR Server by executing the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] script.

Validate the AutoLoad setup by stopping the SAS LASR Server from SAS Visual Analytics Administrator application, or using SAS code. Wait for the “TIME_INTERVAL_MINUTES=[Your-Value]“, and look at the LASR Server status in SAS Visual Analytics Administrator application, and the AutoLoad logs in [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/Logs (one log file each time the AutoLoad process is executed).

Whichever technique is used, the non-distributed LASR server will no longer be dependent on the middle-tier.

I hope this article has been helpful to you.

How LASR servers are started from SAS Visual Analytics Administrator was published on SAS Users.

8月 232016
 

Managing Server Access for SAS Mobile BI UsersTablets, phablets, smartphones.

These mobile devices not only travel to different corners of the earth with their owners; they participate in certain adventures that can result in an unexpected turn of events.

Thanks to their mobility, these devices can be misplaced. And they could be found later. In rare cases, they can get lost. In the event that a user is separated from his or her mobile device, there are security mechanisms in place for protecting access to your organization’s server where data and reports reside.

Whether mobile devices accompany their SAS Mobile BI 7.33 users to the Himalayas or to the Sahara Desert, they certainly need to be tracked and managed by administrators. In my last blog, I talked about how an app-specific passcode protects access to the SAS Mobile BI app by preventing anyone other than the SAS Mobile BI user from accessing the app on the mobile device. Now, let’s take a look at how your administrators manage and protect access from the SAS Mobile BI app on your devices to connect to servers in your organization.

The SAS Visual Analytics 7.3 suite of applications includes the Administrator application with the Mobile Devices tab. The Mobile Devices tab is somewhat like an air traffic control system for an airport. Just as airplanes that land and take off are monitored and managed at the air traffic control tower by personnel, mobile devices that connect to your organization’s server with the SAS Mobile BI app are monitored and managed in the Administrator application’s Mobile Devices tab.

SAS Visual Analytics Administrator runs on the same server where your SAS Visual Analytics reports are stored and accessed. It maintains a logon history that informs your administrator details regarding mobile devices that logged on or attempted to log on to the server from the SAS Mobile BI app. For example, a timestamp indicates when a device connected to the server. A management history equips administrators with data on mobile devices that were whitelisted, blacklisted, or removed from either the whitelist or the blacklist.

Managing Mobile Devices

Regardless of how many mobile devices are installed with the SAS Mobile BI app, security administration is required for every device that accesses data and reports on the server. Every mobile device has a unique identifier, and this unique identifier is used by SAS Visual Analytics Administrator to determine if the device is allowed to access the server.

To control mobile devices’ access to your organization’s server, your administrator manages server access by implementing either a whitelist or a blacklist from the server. By default, blacklisting is enforced on servers that are accessed by the SAS Mobile BI app.

Inclusion Approach to Managing Devices

The whitelist scenario follows the inclusion approach. By default, you cannot connect to the server via SAS Mobile BI until your device ID is added to the whitelist by your administrator. If the unique device ID is added to the whitelist by your administrator, you can use the device to subscribe, view, and interact with SAS Visual Analytics reports (via the SAS Mobile BI app).

Exclusion Approach to Managing Devices

In the blacklist scenario, it is the exclusion approach. By default, everyone can connect to the server from SAS Mobile BI on their mobile devices unless their device IDs are added to the blacklist by the administrator. Any device whose unique device ID is not added to the blacklist can connect to the server from the SAS Mobile BI app. For instance, if you lost your mobile device, your administrator can go to the Logon History, select the device (listed by device ID, user name etc), and add it to the blacklist. Then, you cannot use the device to log on to the server from the app.

The Easy Way to Switch from Blacklisting to Whitelisting

By default, blacklisting is enforced on the server that is accessed by the SAS Mobile BI app, and the viewerservices.enable.whitelist.support configuration property in SAS Management Console (SAS Configuration Manager for SAS Visual Analytics Transport Service) is set to false. If you are an administrator, and wish to switch from blacklisting to whitelisting, the easiest way to do it is to select whitelisting in the Administrator’s Mobile Devices tab and add the device IDs to the whitelist. Then, the viewerservices.enable.whitelist.support configuration property in SAS Management Console is automatically updated and set to true. This is an easier method for switching from blacklisting to whitelisting because it does not require a restarting of the server. If you were to go to SAS Management Console first and set the viewerservices.enable.whitelist.support configuration property to true, this action requires you to restart the server.

Request to Add Devices to a Whitelist

There are a couple of different ways that your administrator can obtain and add device IDs to a whitelist. If the unique device ID is already known to your administrator, he or she can easily add it to the whitelist in the Administrator application’s Mobile Devices tab. Alternatively, if you happen to install SAS Mobile BI app on a new mobile device that is not being managed from the server, the app can take you to your email with template text that includes your mobile device ID – just send that email to your administrator requesting server access from your mobile device.

Suspending or Allowing Server Access from the App

Now here is my most favorite part of device management. Access from SAS Mobile BI to the server, as we have just noted, is determined by either whitelist or blacklist management of devices, not by user accounts. This approach extends flexibility for SAS Mobile BI users. For example, I have an iPhone and a Galaxy Tab Pro tablet – I have SAS Mobile BI app on both devices, and I use both of them to access the server, subscribe to SAS Visual Analytics reports, view, and interact with them. If I happen to misplace my Galaxy Tab Pro tablet and can’t seem to find it, I notify my administrator so that server access from the app on this device can be removed.

My administrator, who follows the whitelist approach, removes my Galaxy Tab Pro’s unique device ID from the whitelist. Then, I can no longer use the SAS Mobile BI app on this device to log on to our server and subscribe to SAS Visual Analytics reports. However, I can continue to use my iPhone (which has remained in the whitelist) to log on to the server, subscribe, view and interact with reports on the server.

Few days later, I find my misplaced Galaxy Tab Pro tablet. I email my administrator indicating that the device is back in my possession. My administrator adds the unique device ID for my Galaxy Tab Pro back to the server’s whitelist. Voila – I am back in business, using SAS Mobile BI to connect to the server from my Android tablet.

In a Nutshell

There are several mechanisms available for securing the SAS Mobile BI app and access to your organization’s servers is one of them. In my next blog, we will take a look at how tethering works to protect data access for SAS Visual Analytics reports from the SAS Mobile BI app.

tags: SAS Mobile BI, SAS Visual Analytics Administrator, security

Managing Server Access for SAS Mobile BI Users was published on SAS Users.

7月 222015
 

VisualAnalyticsThe SAS Visual Analytics 7.2 release introduces a new look and feel to the Hub with the modern (HTML5) version. It also introduces a new feature, Shared Collections, which allows an administrator to push a Shared Collection to all users’ Hub view, including Guest access. And bonus - it will also get pushed down to any SAS Mobile BI users!

The idea of a Collection is not new and was available with the previous versions of Visual Analytics. You can include a variety of content in a Collection such as: tables, reports, explorations and stored processes, and the Collection groups it all together under a Collection name. In VA 7.2 we can now publish a Collection which will make it a Shared Collection.

Let’s look at some screenshots to walk us through how to configure Shared Collections.

Permissions

In order to be able to create Shared Collections, you must have the capability to Create Collections; by default this capability is part of the Home: Administration Role.
Shared_Collections_1

Create Shared Collections

With the proper Role and capability assigned you will see a + Collection button to the left of your Application Shortcut buttons.

Shared_Collections_2

Next, select the Create a New Collection radio button and at the bottom you will see the checkbox option to Publish this collection for all users, check this box to create a Shared Collection. Finally, provide a name for the new collection and a metadata folder location for which to save the collection. Caution: Be sure to use a metadata folder location that is accessible by all the users you wish to view the Shared Collection. For example, if you create a Shared Collection in the My Folder location, no other users will be able to see this Shared Collection.

Shared_Collections_3

The newly created, but empty, Shared Collection will now appear on the Hub. A Shared Collection will display an icon of a lock to the left of the name while a standard Collection will not.
Shared_Collections_4

Add content to a Shared Collection

Now you will need to add content to your Shared Collection. Use the Shared Collection tile’s menu to select Edit, then use the + to add content. Caution: Just like the metadata folder location of the Shared Collection needs to be accessible to your users, so does your content. Collections will store a pointer to that actual piece of content, so you don’t have to worry about your content getting duplicated and potentially getting out of sync. Be sure to click the Save button once you have added all your desired content.
Shared_Collections_5

Manage a Shared Collection

Administrators

Any user with the proper Role and capability who has access to the Shared Collection will be able edit the Shared Collection.

Standard Users

For your standard users, if they have ReadMetadata permission to the Shared Collection metadata folder location then the Shared Collection will automatically appear on their Hub view. If they wish, they can Hide the Shared Collection tile; they always have the ability to go back and turn the tile back on from the Hub’s Settings menu. Keep in mind that in order to view the content in the Shared Collection the users will need Read access to the content itself.

Shared_Collections_6

For standard users who also use the SAS Mobile BI Application, the Shared Collection will automatically appear in the Portfolio menu. The user will still have to subscribe to the reports, but the Shared Collection and its report contents will be visible. This also includes those users who sign on as Guest. If the standard user hides the collection at any time, the Shared Collection grouping will be removed from the SAS Mobile BI Application, but any reports that were subscribed to will remain under the Subscribed grouping.

Shared_Collections_7

tags: SAS Administrators, SAS Visual Analytics, SAS Visual Analytics Administrator, Shared Collections

Use Hub Shared Collections to automatically push VA reports to your users was published on SAS Users.

5月 212014
 

I’ve recently had the opportunity to learn a little more about administering SAS Visual Analytics.  The sessions introduced me to two new GUI interfaces that simplify the work for SAS administrators.  In my last post, I shared how to load data into memory using the SAS Visual Data Builder.

After building the table, loading into memory and scheduling the query, you will want to work on the user or group permissions for the dataset.  You can use the SAS Visual Analytics Administrator for this task.

Accessing the table

To access the SAS Visual Analytics Administrator, return to the SAS Visual Analytics home page by selecting the HOME icon and select Manage Environment from the right hand pane. Your userid must have the appropriate permissions to be able to utilize all of the features I am going to show below:VApermissions1

To view the current permissions on the table, expand the LASR directory tree in the left hand side pane.  Double-click on the SampleClaims table that we’ve been using for this discussion. You’ll see the permissions listed by type of access permitted for each user role.

VApermissions2

Setting permissions 

Defining user groups can be done within SAS Management Console. Once I have my user groups, I can then set permissions within SAS Visual Analytics. In this particular situation, SASUSERS is the collection of all users who have access to SAS. SAS Administrators and SAS System Services are a subset of the SASUSERS group by definition. You may have other groups defined, such as Finance or Marketing. The following tasks can be done on any of your user groups as needed.

I want to give my SASUSERS read permissions, but I don’t want them to delete or overwrite the existing table. When I click on “grant” or “deny”, it becomes an explicit permission. An explicit permission is one that the administrator has expressly set. Implicit or inherited permissions will then be set for the subset of users within SASUSERS (my SAS Administrators and SAS System Services groups).

To change the permission explicitly, I select the icon I wish to change for the user or user group I wish to change.

VApermissions3

When I make SASUSERS an explicit Deny for WriteMetadata access, the SAS System Services and SAS Administrators inherit a Deny as shown below. Explicit permissions are denoted by a yellow star.

VApermissions4

Since SAS Administrators and SAS System Services should have WriteMetadata access, I will need to go in and give the SAS System Services and SAS Administrators groups an explicit grant.

The same process will need to be repeated for other permissions columns such as Write, Administer, and Delete.  All the permissions should look like the table below, with explicit permissions denoted by a yellow star.

VApermissions5

Testing the result

Once your query has been scheduled and you’ve set all your user permissions, it’s good practice to create an exploration to determine the table has loaded correctly and to see what end-users will see.

Returning to the Home page, select Create Exploration --> Select a Data Source.  Scroll down to your table (here we're testing the SampleClaims table) and select Open.

VApermissions6

Take advantage of the auto-charting feature  in the SAS Visual Analytics Data Explorer by simply dragging and dropping whatever categories or measures you’d like to view onto the workspace.  In this example, I’ve selected the variables Claim Amount and Type of Car, and the auto-charting facility automatically selects a bar chart for me.

VApermissions7

I hope this has helped you get up and running with some common administrator tasks within SAS Visual Analytics!

tags: data access, permissions, SAS Administrators, SAS Visual Analytics, SAS Visual Analytics Administrator