BookmarkSubscribeRSS Feed
bheinsius
Lapis Lazuli | Level 10

Hi,

EG71 provides an Upload to LASR task.

Prerequisite for this is that the LASR server is configured in the same metadata environment as EG.

However, Dutch SAS TLM consultants advice against integrating VA in a SAS BI metadata environment, they advice to install VA with its own metadata environment.

I validated this with developers at SASGF15 and they say the same.

Does this render the Upload to LASR task useless?

Bart Heinsius

10 REPLIES 10
LinusH
Tourmaline | Level 20

Given this advice - yes!

SAS in Sweden does from what I understand advice against a shared metadata. They were however skeptical in previous releases.

For me to promote VA as a BI application, it really have to be on a shared metadata environment. Without it, it's not integrated. And not integrated, you loss the benefits of end-to-end SAS product line.

Data never sleeps
CaseySmith
SAS Employee

The "Upload to LASR" task in EG and AMO is a very useful task for getting data prep/output from EG and AMO processing into LASR Analytic Server and registered for use in Visual Analytics.  However, as Linus pointed out, if you choose to maintain separate metadata environments, you are defeating the integration that task provides.

You might be able to define a LASR library in the BI metadata environment, then use the Upload to LASR task to upload to that library.  The data would get loaded into LASR, but the table would not be registered in the VA metadata environment, thus couldn't be automatically used in VA.


Register today and join us virtually on June 16!
sasglobalforum.com | #SASGF

View now: on-demand content for SAS users

bheinsius
Lapis Lazuli | Level 10
if you choose to maintain separate metadata environments, you are defeating the integration that task provides.

it looks like i don't really have a choice, since SAS Institute advises against it.

You might be able to define a LASR library in the BI metadata environment, then use the Upload to LASR task to upload to that library.  The data would get loaded into LASR, but the table would not be registered in the VA metadata environment, thus couldn't be automatically used in VA.

i don't completely understand your idea, can you elaborate on this?

CaseySmith
SAS Employee

You might be able to define a LASR library in the BI metadata environment, then use the Upload to LASR task to upload to that library.  The data would get loaded into LASR, but the table would not be registered in the VA metadata environment, thus couldn't be automatically used in VA.

i don't completely understand your idea, can you elaborate on this?

I haven't tried it, but given separate BI and VA metadata servers, I would think you could define a LASR library in your BI metadata server, so you have an output destination for the Upload to LASR task (when EG or AMO connected to the BI metadata server).  When you run the Upload to LASR task and "upload" to that LASR library, the data should get written (loaded into memory) to the LASR server (so you could use IMSTAT for example).  However, the uploaded table would not get registered in the VA metadata server, thus not automatically available for use in VA, losing a large benefit of the Upload to LASR task.

If your goal is to use the data in VA and you have separate metadata environments, probably easier writing the data to a location that can be accessed by both environments, then using the VA tools to load the data.


Register today and join us virtually on June 16!
sasglobalforum.com | #SASGF

View now: on-demand content for SAS users

bheinsius
Lapis Lazuli | Level 10
If your goal is to use the data in VA and you have separate metadata environments, probably easier writing the data to a location that can be accessed by both environments, then using the VA tools to load the data.

that is indeed my goal, so that renders the EG task "Upload to LASR" useless. Smiley Wink

JuanS_OCS
Amethyst | Level 16

Hi Bart,

 

not always: SAS is supplying more and more SAS VA (SAS VAAR, actually) with most of the SAS Solutions, of not all.

 

This means that:

- if you have the full SAS VA as independent solution, indeed, it is better (just a suggestion, based on good architecture sinergies, which I understand you are aware of at this moment). And it makes sense, as principal solution for the Front End/Reporting. 

- if you have a different SAS Solution, then you get the license for SAS VAAR, then you will have a restricted version of SAS VA, but you get a Shared Metadata, then the functionality on EG makes also full sense.

SASKiwi
PROC Star

I understand the main reason why SAS recommend a separate VA environment (separate metadata server) is that SAS VA is on a different upgrade cycle to SAS BI. VA version/maintenance upgrades tend to be 6-monthly and SAS BI maintenance upgrades are usually yearly.

 

We are just starting a SAS VA install project and this issue of shared or separate metadata servers was one of the first decisions to make. I would have preferred a shared metadata server setup for the very reasons discussed here, but that required a maintenance upgrade for our existing SAS BI setup from SAS 9.4 M2 to M3. You wouldn't think a maintenance upgrade is a big deal but SAS quoted 11 days work to do this to both our Production and DR environments (5.5 days each)! So another reason to keep your SAS VA environment separate is it is too much work, too disruptive, and too expensive to apply maintenance to SAS BI 9.4 to keep it in synch with VA.

 

I have heard that this maintenance issue will be addressed in the next major SAS release to be publicised soon at 2016 SAS Global Forum - I await the details with interest.

JuanS_OCS
Amethyst | Level 16

Indeed, dependencies and impact on maintenances is an issue.

I am looking forward to hearing the incoming improvements on this matter by developers at the SGF!

LinusH
Tourmaline | Level 20
Until SAS recommends a shared environment I consider VA an immature product.
Let's hope for the next version...
Data never sleeps
SASKiwi
PROC Star

I am told that the goal in the next release is to reduce the time to do maintenance upgrades from days to hours. The reason for the long time is the SAS mid-tier needs to be completely redeployed and retested.

 

If this does indeed happen then I can't think of any major technical reason to keep SAS VA separate. 

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

SAS Enterprise Guide vs. SAS Studio

What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 10 replies
  • 3506 views
  • 2 likes
  • 5 in conversation